Subject: [Isms] SSH USERNAME

From: "David Harrington" <[email-masked]>
Date: Fri, 14 Sep 2007 10:00:58 -0400

Hi Joe,

I'm not sure what to do with this.
If I get my terminology correct, we are looking for a cryptographic
binding between the user identity authenticated by SSH and the user
identity used for database access control in SNMP.

Are you saying that SSH will authenticate an empty username? 
Could we solve the problem by saying that SNMP should not accept an
empty username field?
If we don't use SSH_MSG_USERAUTH_REQUEST, where do we get an
identifier for the SSH-authenticated entity?
I think we already recognize that toolkits may not make the
SSH_MSG_USERAUTH_REQUEST available to users, and users need to work
through whatever APIs are provided to set the username. I'm not very
commfortable that this qualifies as cryptographic binding, but it
seems the be the best we can get from the SSH community.

The second problem is an SSH problem that we cannot do anything about,
right?
So in practical terms, Can I (dbh) specify "root" in the SSH username
and have SSH establish an authenticated connection for root, even if I
do not have the credentials for root? Is that what you are saying?
Is there any way for SNMP to even know when this is happening?
Is the security area planning to fix this loophole?

dbh

> -----Original Message-----
> From: Joseph Salowey (jsalowey) [mailto:[email-masked]] 
> Sent: Wednesday, August 22, 2007 8:08 PM
> To: Jeffrey Hutzelman; Wijnen, Bert (Bert); David Harrington
> Cc: [email-masked]
> Subject: RE: [Isms] my review of: draft-ietf-isms-secshell-08.txt
> 
> In particular I think we need to be careful of 
> SSH_MSG_USERAUTH_REQUEST.
> First an empty username may appear in this message and second 
> there is a
> loophole in the base SSH spec that could allow an authentication
> mechanism in which the name in the username field is not an
authorized
> name of the authenticated party.  
> 
>  
> 
> > -----Original Message-----
> > From: Jeffrey Hutzelman [mailto:[email-masked]] 
> > Sent: Wednesday, August 22, 2007 3:22 PM
> > To: Wijnen, Bert (Bert); David Harrington; Joseph Salowey
(jsalowey)
> > Cc: [email-masked]; Jeffrey Hutzelman
> > Subject: Re: [Isms] my review of: draft-ietf-isms-secshell-08.txt
> > 
> > 
> > 
> > On Thursday, August 09, 2007 12:17:13 PM +0200 "Wijnen, 
> Bert (Bert)" 
> > <[email-masked]> wrote:
> > 
> > > - sect 5.1 and 5.1
> > >   I assume that SSH_MSG_USERAUTH_REQUEST and
SSH_MSG_CHANNEL_DATA
> > >   are specified somewhere in the SSH RFC(s)? Maybe a citation to
> > >   such RFC(s) is useful at these points.
> > 
> > Yes; those are SSH protocol messages.  It's actually not 
> > clear that SSH messages should be referenced explicitly here; 
> > instead, we should be talking about SSH at a rather higher 
> > layer.  For example, SSH user authentication can be a fairly 
> > complex negotiation; it doesn't involve sending just one 
> > message.  Similarly, outside the SSH protocol channels are 
> > presented as streams, not sequences of SSH_MSG_CHANNEL_DATA 
> > messages, and in particular you can't assume that your 
> > messages will be sent in a single channel data message or 
> > infer the size of an incoming message from the underlying SSH 
> > protocol messages.
> > 
> > Similarly, if you are establishing a separate SSH connection 
> > for every session, you don't need data from the SSH channel 
> > open/confirmation messages, and in fact generally such data 
> > will not be available to you as it is buried in the details 
> > of the SSH protocol.  If you are establishing multiple 
> > channels over the same SSH session, then you may need to know 
> > which channel is which, but this is almost certainly done 
> > using identifiers provided to you by your SSH implementation 
> > (perhaps even file descriptors) and not necessarily using SSH 
> > protocol data.
> > 
> > 
> > 
> > > - For SnmpSSHAddress ::= TEXTUAL-CONVENTION I read:
> > >
> > >         "Represents either a hostname encoded in ASCII
> > >         using the IDNA protocol, as specified in RFC3490, 
> > followed by
> > >         a colon ':' (ASCII character 0x3A) and a decimal 
> port number
> > >         in ASCII, or an IP address followed by a colon ':'
> > >         (ASCII character 0x3A) and a decimal port number in
ASCII.
> > >          The name SHOULD be fully qualified whenever possible.
> > >
> > >   I am not well versed/experienced in IDNA. But is IDNA a 
> protocol?
> > 
> > That is a semantic question, which I'd just as soon not argue
here.
> > Perhaps we could say "as specified by IDNA [RFC3490]" ?
> > 
> > 
> > >   The title of 3490 reads
> > >       Internationalizing Domain Names in Applications (IDNA)
> > >   And are we indeed speaking of a hostname, or of a 
> domain name, or
> > >   of both? I can't quickly determine that. So I wonder 
> if/hope that
> > >   we can be clearer here.
> > 
> > We are talking about a hostname, but hostnames are domain 
> > names (however, not all domain names are valid hostnames).
> > 
> > 
> > 
> > >   I also assume (although this is not explicitly stated) 
> that if we
> > >   speak about an IP address, that it is a dotted decimal for
> > >   IPv4 and and a colon separated IPv6 address in ASCII? Yes/no?
> > 
> > In fact, I think we are in trouble if, for an IPv6 address, 
> > we don't mean a 
> > colon-separated address with brackets around it.  Otherwise 
> > it may become 
> > rather difficult to determine where the port starts, or if it 
> > is present!
> > 
> > -- Jeff
> > 
> 

_______________________________________________
Isms mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/isms

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 14 Sep 2007 11:19:31 -0400 (EDT)

> identity used for database access control in SNMP.

No.  The ssh layer will provide you with an authenticated username, and
that authentication is cryptographically bound to the communication
channel (to what extent depends on the mechanism you are using, but it's
generally at least reasonable, provided the client has verified the
server's identity before proceeding).

The relation between the ssh username and the identity used for access
control in SNMP is entirely up to SNMP.  SSH never sees the latter, except
to the extent that the two names are the same (which will probably be the
case most of the time, or possibly even all of the time; I don't remember
what we ended up doing with that).

> identifier for the SSH-authenticated entity?

You misunderstand.  The issue is very simple -- by mentioning specific
SSH protocol messages at all, you are violating the abstraction.  The SSH
protocol is considerably more complex than the interface available to the
upper-layer application, and Joe is pointing out a case where this is
getting you into trouble.

In a noremal SSH authentication exchange, there will typically be multiple
SSH_MSG_USERAUTH_REQUEST messages.  The first one will almost always have
method "none", possibly an empty username, and will fail.  Its main
purpose is to discover what authentication methods the server supports,
though it also services to discover whether the server will allow an
anonymous or unauthenticated login.  This complexity is not described in
SSHSM, nor should it be.

> do not have the credentials for root? Is that what you are saying?

There may be multiple sets of credentials that allow you to authenticate
as root, even using the same mechanism.  For example, on a typical machine
in our computing environment, there are (currently) three DSA keys, one
RSA key, and 32 Kerberos principals which can be used to log in as root.

But what Joe is really saying is that it is possible to have an SSH user
authentication mechanism which ignores the username entirely.  In fact,
the "hostbased" method permits such a mode, where only the identity of the
client host is considered.  This is not as useless as it might sound; such
a method could be used in multi-step authentication, or in a scenario
where there is a proxy trusted by the end server -- (the real user makes
an SSH connection to a proxy, authenticates to it, the proxy decides
whether the connection is legit, and if so, turns around and establishes a
connection to the real server, which trusts whatever the proxy tells it
about usernames).

> Is there any way for SNMP to even know when this is happening?

No.

> Is the security area planning to fix this loophole?

No.  It's not a security bug; it's a loophole in the spec that allows
someone to specify an authentication method that does something you might
not have thought of.  There are probably others.

The point is, SSHSM doesn't have to say what SSH protocol messages to send
when, any more than it has to talk about TCP connection setup, windowing,
etc.  Those things are all below the abstraction.

---

From: "David B. Nelson" <[email-masked]>
Date: Fri, 14 Sep 2007 11:31:39 -0400

Jeffrey Hutzelman writes...

> No.  It's not a security bug; it's a loophole in the spec that 
> allows someone to specify an authentication method that does 
> something you might not have thought of.  There are probably 
> others.
> 
> The point is, SSHSM doesn't have to say what SSH protocol messages
> to send when, any more than it has to talk about TCP connection 
> setup, windowing, etc.  Those things are all below the abstraction.

Sure.

Does SNMP have a way to know that SSH has performed a "meaningful"
authentication?

If not, is there a way for the system administrator to configure the
combination of SSH and SNMP such that insufficiently "meaningful" levels of
authentication are not employed with Transport Security Models?