Subject: [Isms] SSH always provides a username

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 05 Mar 2009 16:36:16 -0500

draft-ietf-isms-secshell-14.txt section 4.1.1 contains the following:

      The SSH protocol is not always clear on whether the user name
      field must be filled in, so for some implementations, such as
      those using GSSAPI authentication, it may be necessary to use a
      mapping algorithm to transform an SSH identity to a
      tmSecurityName, or to transform a tmSecurityName to an SSH
      identity.

      In other cases the user name may not be verified by the server, so
      for these implementations, it may be necessary to obtain the user
      name from other credentials exchanged during the SSH exchange.

This is not true; it is a misinterpretation of the details of operation of 
a particular SSH user authentication method which happen below the 
abstraction visible to SSHTM.  While the GSS-API user authentication method 
described in RFC4462 does allow the "username" field on the wire to be 
empty, this is permitted only in cases where the SSH server (NOT a 
subsystem such as SNMP) is able to infer a username from the client's 
GSS-API credentials.  SSH will always report an authenticated username.

Similarly, if the SSH server allows the connection, it has determined that 
the client is authorized for the requested username.  The claim that "the 
user name may not be verified by the server" would seem to be a reference 
to the "none" user authentication method, in which the server may choose to 
allow access with no further authentication.  This is functionally 
equivalent to using password authentication but allowing any password, or 
using a well-known SNMP community string like "public" -- weak, but 
operating as designed.

In no case should SSHTM "obtain the user name from other credentials 
exchanged during the SSH exchange"; this would be a serious violation of 
the abstraction boundary between SSHTM and SSH.

I propose to eliminate these two paragraphs, and make the following change:

OLD:

   On the SSH server side of a connection:

      The tmSecurityName SHOULD be the value of the user name field of
      the SSH_MSG_USERAUTH_REQUEST message for which a
      SSH_MSG_USERAUTH_SUCCESS has been sent.  How the SSH user name is
      extracted from the SSH layer is implementation-dependent.

NEW:

   On the SSH server side of a connection:

      The tmSecurityName SHOULD be the SSH user name.  How the SSH user
      name is extracted from the SSH later is implementation-dependent.

This eliminates the inappropriate reference to details of the SSH protocol, 
which is also an abstraction violation.  SSHTM has no business knowing that 
the username came from a particular field of a particular SSH protocol 
message, especially when that may not actually be the case.

-- Jeff

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 6 Mar 2009 09:23:12 +0100

On Thu, Mar 05, 2009 at 04:36:16PM -0500, Jeffrey Hutzelman wrote:
> This is not true; it is a misinterpretation of the details of operation 
> of a particular SSH user authentication method which happen below the  
> abstraction visible to SSHTM.  While the GSS-API user authentication 
> method described in RFC4462 does allow the "username" field on the wire 
> to be empty, this is permitted only in cases where the SSH server (NOT a  
> Similarly, if the SSH server allows the connection, it has determined 
> that the client is authorized for the requested username.  The claim that 
> "the user name may not be verified by the server" would seem to be a 
> reference to the "none" user authentication method, in which the server 
> may choose to allow access with no further authentication.  This is 
> functionally equivalent to using password authentication but allowing any 
> password, or using a well-known SNMP community string like "public" -- 
> weak, but operating as designed.
>
> This eliminates the inappropriate reference to details of the SSH 
> protocol, which is also an abstraction violation.  SSHTM has no business 
> knowing that the username came from a particular field of a particular 
> SSH protocol message, especially when that may not actually be the case.

Thanks Jeff for clarifying what we can expect to be provided by the
SSH layer. This is good news as it makes our documents simpler.
Editors, please take care of these changes.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: "tom.petch" <[email-masked]>
Date: Fri, 6 Mar 2009 10:21:46 +0100

---- Original Message -----
From: "Jeffrey Hutzelman" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, March 05, 2009 10:36 PM
Subject: [Isms] SSH always provides a username

> message, especially when that may not actually be the case.

Jeff

What you say seems fine but I find this horribly difficult, especially over
e-mail.  I do not know enough about ssh to know whether your words are more
accurate or not.

What I do know is that the current wording was supplied by Joe Salowey
(28nov2008) and when he did, I annotated my copy of sshtm with comment 'supplied
by Joe so must be right' ie I do not know enough to judge the accuracy of this.
This text was proposed in response to a difficulty so it is there for a reason.

You and Joe both know much more about ssh than I and when you say what I
perceive to be different things, I struggle to know which to support.  I look in
other places - you contributed more on the ssh list but I see more of Joe
contributing outside the IETF - and find myelf on the fence.

Perhaps the 'proper' resolution is for Joe to speak up and say, yes, this is
fine but I cannot rely on that happening.

The worst outcome is that, during a future review, Joe speaks up and says change
it back again because ....

So, I am on the fence, and not comfortable with it.

Tom Petch

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

---

From: "David Harrington" <[email-masked]>
Date: Fri, 6 Mar 2009 09:12:57 -0500

Hi,

I have asked Joe to be more active in this discussion.
I also asked Chris Lonvick (editor SSH docs) to look in on this thread
and see if he wants to contribute anything.
When the pure security guys reach consensus, maybe they can provide us
NM-oriented editors soem immutable text to put into the document.

dbh 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of tom.petch
> Sent: Friday, March 06, 2009 4:22 AM
> To: Jeffrey Hutzelman; [email-masked]
> Cc: [email-masked]
> Subject: Re: [Isms] SSH always provides a username
>

---

From: Wes Hardaker <[email-masked]>
Date: Fri, 06 Mar 2009 06:51:35 -0800

>>>>> On Thu, 05 Mar 2009 16:36:16 -0500, Jeffrey Hutzelman <[email-masked]> said:

JH> OLD:

JH> On the SSH server side of a connection:

JH> The tmSecurityName SHOULD be the value of the user name field of
JH> the SSH_MSG_USERAUTH_REQUEST message for which a
JH> SSH_MSG_USERAUTH_SUCCESS has been sent.  How the SSH user name is
JH> extracted from the SSH layer is implementation-dependent.

JH> NEW:

JH> On the SSH server side of a connection:

JH> The tmSecurityName SHOULD be the SSH user name.  How the SSH user
JH> name is extracted from the SSH later is implementation-dependent.

I never liked the previous wording and think the newer set is much
better.  I suspect that some of the original wording may have been
back when we were discussing host-based authentication and maybe the
wording was confused because of that (host-based authentication still
requires the user-name to be present but the server can ignore it if
desired).

My only question with the replacement text is that the rest of the
documentation frequently refers to the "SSH principal" instead of the
"SSH user name".  Should the text use that instead?
-- 
Wes Hardaker
Sparta, Inc.

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Fri, 6 Mar 2009 07:53:25 -0800

> Sent: Friday, March 06, 2009 1:22 AM
> > This is not true; it is a misinterpretation of the details of 
> > operation of a particular SSH user authentication method 
> which happen 
> > below the abstraction visible to SSHTM.  While the GSS-API user 
> > authentication method described in RFC4462 does allow the 
> "username" 
> > field on the wire to be empty, this is permitted only in 
> cases where 
> > the SSH server (NOT a subsystem such as SNMP) is able to infer a 
> > username from the client's GSS-API credentials.  SSH will 
> always report an authenticated username.
> >
> > that the client is authorized for the requested username.  
> The claim 
> > that "the user name may not be verified by the server" 
> would seem to 
> > be a reference to the "none" user authentication method, in 
> which the 
> > server may choose to allow access with no further authentication.  
> > This is functionally equivalent to using password 
> authentication but 
> > allowing any password, or using a well-known SNMP community string 
> > like "public" -- weak, but operating as designed.
> >
> > exchanged during the SSH exchange"; this would be a serious 
> violation 
> > of the abstraction boundary between SSHTM and SSH.
> >
> > protocol, which is also an abstraction violation.  SSHTM has no 
> > business knowing that the username came from a particular 
> field of a 
> > particular SSH protocol message, especially when that may 
> not actually be the case.
> >
> 
> Jeff
> 
> What you say seems fine but I find this horribly difficult, 
> especially over e-mail.  I do not know enough about ssh to 
> know whether your words are more accurate or not.
> 
> (28nov2008) and when he did, I annotated my copy of sshtm 
> with comment 'supplied by Joe so must be right' ie I do not 
> know enough to judge the accuracy of this.
> You and Joe both know much more about ssh than I and when you 
> say what I perceive to be different things, I struggle to 
> know which to support.  I look in other places - you 
> contributed more on the ssh list but I see more of Joe 
> Perhaps the 'proper' resolution is for Joe to speak up and 
> say, yes, this is fine but I cannot rely on that happening.
> 
[Joe] Yes this is fine, explanation below.  

> The worst outcome is that, during a future review, Joe speaks 
> up and says change it back again because ....
>

> So, I am on the fence, and not comfortable with it.
[Joe]  I agree with Jeffrey that the current text has too many SSH
specifics in it and I would like to see that changed (I think I
suggested it in the past, but I probably didn't express myself well).
My main concern is that the protocol field in the SSH message may not be
filled in.  It is true that SSH knows what the authenticated name is.
It is true for RFC 4462 that if the user name is present it should be
authorized, but the core SSH drafts don't require this, so it might not
be true for other mechanisms.  In any case, how the SSH username is
extracted from the SSH protocol is implementation specific.  

I think Jeffrey's text is good (s/later/layer).   I am tempted to
request that we say something like "It is the responsibility of the SSH
layer ensure that the user name is valid and authenticated", but I can
live without this because it really should be the case in a reasonable
implementation.  

Hopefully this helps clear things up.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 06 Mar 2009 10:58:53 -0500

> "SSH user name".  Should the text use that instead?

I don't know where the phrase "SSH principal" came from.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 06 Mar 2009 11:15:26 -0500

--On Friday, March 06, 2009 07:53:25 AM -0800 "Joseph Salowey (jsalowey)" 
<[email-masked]> wrote:

> filled in.

But that detail is not visible to the layer above...

> It is true that SSH knows what the authenticated name is.

While this one is.

> be true for other mechanisms.

I think that depends on what you mean by "authorized".  RFC4252 does 
require that the server reject an authentication request if the user does 
not exist; see the third full paragraph on page 5.  I think it is inherent 
in the nature of an authentication method that the method verify that 
whatever credentials the client presents are valid for the specified 
username, according to whatever the rules are for that method.  So, that 
much should go without saying.

Of course, the core drafts don't nail down what that means, because it 
varies from method to method.  'publickey' says "the server MUST check that 
the key is a valid authenticator for the user" (RFC 4252 sec 7, graf 2). 
'password' leaves the details of password validation up to the server. 
'none' succeeds "if no authentication is needed for the user" (RFC4252 sec 
5.2).

The description of 'hostbased' is a bit confusing.  The auth request for 
this method contains two usernames -- the SSH user name that is present in 
all auth requests, and the requesting user's name _on the client host_. 
This allows user "bob" on host A to use hostbased authentication to log in 
as user "joe" on host B, provided B is configured to allow bob@A to log in 
as joe.

To my reading, what the next-to-last graf on RFC4252 page 13 says is that 
in this scenario, the SSH server on host B can ignore the "bob" value and 
base its access decision solely on the credentials provided by host A.  It 
does _not_ allow host B to ignore the 'user name' that is a standard part 
of the SSH request, which in this example contains the name "joe".  That 
would be silly, because then it wouldn't know what username to use.

> live without this because it really should be the case in a reasonable

I think RFC4252 covers that sufficiently well, but I won't object to 
reiterating it here.

-- Jeff

---

From: "tom.petch" <[email-masked]>
Date: Sat, 7 Mar 2009 12:16:48 +0100

----- Original Message -----
From: "Jeffrey Hutzelman" <[email-masked]>
To: "Wes Hardaker" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Friday, March 06, 2009 4:58 PM
Subject: Re: [Isms] IsmsSSH always provides a username

> I don't know where the phrase "SSH principal" came from.

Nor me.  Oxymoron?  I do not think that it should appear.  Principal is a well
defined SNMPv3 term, SSH has users, hosts, .....  If we need to invent another
term, it should be anything but principal.

Tom Petch

---

From: Wes Hardaker <[email-masked]>
Date: Mon, 09 Mar 2009 08:34:50 -0700

>>>>> On Sat, 7 Mar 2009 12:16:48 +0100, "tom.petch" <[email-masked]> said:

tp> Nor me.  Oxymoron?  I do not think that it should appear.  Principal
tp> is a well defined SNMPv3 term, SSH has users, hosts, .....  If we
tp> need to invent another term, it should be anything but principal.

In the document I posted a link to on Friday I tried to change all
existences of "SSH principal" to "SSH user".  Note that the term
principal is defined in the beginning of the document and does still
exist through the rest of the document to refer to the human-user (badly
summarizing here).  If you look at the diff or the document and think I
missed one, please let me know ASAP.
-- 
Wes Hardaker
Sparta, Inc.

---

From: "David Harrington" <[email-masked]>
Date: Mon, 9 Mar 2009 12:20:02 -0400

Hi,

Just a point. If you refer to the "SSH user", that can be easily
confused with the value of the "SSH user name" field, and since we
have had long debates about whether user name is or is not filled in,
and so on, keeping a separation between "SSH user" and "SSH user name"
was something I considered a good thing. 

ymmv.

dbh

> Behalf Of Wes Hardaker
> Sent: Monday, March 09, 2009 11:35 AM
> To: tom.petch
> Cc: [email-masked]; Jeffrey Hutzelman

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 09 Mar 2009 15:36:08 -0400

> was something I considered a good thing.

Actually, what we've had long debates about was whether SSHTM should talk 
about the details of the SSH protocol at all, and I believe we came to the 
conclusion that it should not.  The distinction you are talking about is 
the distinction between "TCP port" and "TCP source port field"; just as 
that matters only to an implementation of TCP, the details of the 'user 
name' field in a particular SSH message, what it means, and when, matter 
only to an implementation of SSH.

Please, as long as we keep our focus above the SSH abstraction, any 
confusion caused by trying to talk about what goes on below that 
abstraction goes away!

-- Jeff

---

From: Chris Lonvick <[email-masked]>
Date: Mon, 9 Mar 2009 19:12:50 -0700 (PDT)

Hi,

I would add my support to the consensus that the conclusions reached on 
this thread are correct.  The following offers an explanation of why 
explicit authentication is not always required.

The initial intention for SSH was to secure the "r tools": rlogin, rsh, 
rcp, and rdist.  The trust mechanisms for those were host-level 
equivalence and device-level equivalence.  For the former, an 
administrator or user identified that an account on one machine was 
equivalent to an account on a different machine - that they had the same 
user.  For the latter, an administrator ensured equivalency of the user 
accounts and informed the machines that they could trust each other for 
this purpose.  In both cases, a username was always provided but in some 
cases authentication was implied since trust was already established.

>From those humble beginnings, ;-) SSH has evolved into many different 
things.  Most of those things, like isms, do not depend upon upon trust 
models like those and the isms documents should be explicit in its trust 
model and authentication scheme.

If the SSH documents are not clear about filling in a username field, then 
I believe that's on oversight due to the lengthy editing process and not 
the intent.

Best regards,
Chris

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 09 Mar 2009 22:24:38 -0400

--On Monday, March 09, 2009 07:12:50 PM -0700 Chris Lonvick 
<[email-masked]> wrote:

> If the SSH documents are not clear about filling in a username field,
> then I believe that's on oversight due to the lengthy editing process and
> not the intent.

Yeah, in retrospect, the language in the description of hostbased could 
have been more transparent on this point, but I don't see it as a major 
problem.  I very much doubt there is both a client out there that uses 
hostbased and leaves the "wrong" username field empty _and_ a server that 
actually accepts such a request, and even if there is, such a server would 
have to come up with a username somehow, unless it was running in an 
environment where nothing cared what the username was.  SSHTM is clearly 
_not_ such an environment.

Also in retrospect, rather than allowing the client username to be empty in 
hostbased user auth, we should have made it an optional field with a 
boolean indicating whether it is present, as was done in so many other 
cases.  Isn't hindsight wonderful?

-- Jeff

---

From: Wes Hardaker <[email-masked]>
Date: Mon, 09 Mar 2009 20:09:32 -0700

>>>>> On Mon, 09 Mar 2009 22:24:38 -0400, Jeffrey Hutzelman <[email-masked]> said:

>> then I believe that's on oversight due to the lengthy editing process and

JH> Yeah, in retrospect, the language in the description of hostbased
JH> could have been more transparent on this point, but I don't see it as
JH> a major problem.

I'd appreciate it if you'd check the diff on the just published draft
and let me know if you think the wording in this respect is incorrect
anywhere.  I think it matches your expectations but it would be
excellent if you could confirm that.
-- 
Wes Hardaker
Sparta, Inc.