Re: AUTH48 [AH]: RFC 4462 <draft-ietf-secsh-gsskeyex-10.txt> NOW AVAILABLE (fwd)

[Nicolas Williams <Nicolas.Williams%Sun.COM@localhost>]

On Fri, Apr 07, 2006 at 03:09:38PM -0400, Jeffrey Hutzelman wrote:
> 
> 
> ---------- Forwarded Message ----------
> Date: Friday, April 07, 2006 01:26:40 PM -0400
> From: Jeffrey Hutzelman <jhutz+%cmu.edu@localhost>
> To: "Salowey, Joe" <jsalowey%cisco.com@localhost>, galb%vandyke.com@localhost, welch%mcs.anl.gov@localhost
> Subject: RE: AUTH48 [AH]: RFC 4462  <draft-ietf-secsh-gsskeyex-10.txt> NOW 
> AVAILABLE
> 
> [Removed rfc-editor; I doubt they care about the technical discussion.]
> 
> 
> On Friday, April 07, 2006 09:57:52 AM -0700 "Salowey, Joe"
> <jsalowey%cisco.com@localhost> wrote:
> 
> >I agree with Jeffrey's revisions, but I have one additional concern
> >related to the added text in section 3.2.
> >
> >The section says "It is up to the server how it interprets the user name
> >and determines whether the client is authorized based on his GSS-API
> >credentials."  I don't see anywhere in the document where it states
> >whether the SSH implementation is required to authorize the user name
> >against the authenticated credentials or not.  This may be better
> >covered in the SSH base documents, but it is not stated their either.
> >The reason why I think this is an issue is that applications that are
> >trying to use SSH as a secure transport such as ISMS are stating that
> >the SSH user name can be used for authorization purposes.  Based on the
> >current text I'm not sure if it is the responsibility of the SSH
> >implementation or the ISMS applications to make sure that the user name
> >is authorized based on the authentication.
> >
> >My preference would be to make it clear in the document that the SSH
> >implementation MUST make sure the user name is allowed based on the name
> >authenticated by the GSS-API mechanism.
> 
> Well, RFC4252 doesn't say anything about it because it doesn't really have
> any concept of an identity other than the username.  If you give the wrong
> password, authentication fails.  If you use the wrong public key,
> authentication fails.  And so on.
> 
> What we have here is a situation where GSS-API authentication can succeed,
> but you haven't actually authenticated as the requested username, and an
> authorization check is necessary.  I have no objection to text which makes
> this clear, and I do think it's appropriate for this document.

Note: don't be too specific about how this authorization check should be
implemented, specifically don't require that authenticated principal's
display name or exported MN or gss_compare_name() or anything like that
should be used.  To speak of the authenticated principal's name
generally, or "NAME" (to more clearly reference the object type in
RFC2743) is sufficient.

This is to keep from accidentally excluding the use of GSS-API naming
extensions currently being considered at the KITTEN WG from being used
here.

Nico
--