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

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 07 Apr 2006 15:09:38 -0400

---------- Forwarded Message ----------
Date: Friday, April 07, 2006 01:26:40 PM -0400
From: Jeffrey Hutzelman <[email-masked]>
To: "Salowey, Joe" <[email-masked]>, [email-masked], [email-masked]
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"
<[email-masked]> 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.

-- Jeff

---------- End Forwarded Message ----------

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 7 Apr 2006 16:32:07 -0500

> 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
--

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 07 Apr 2006 17:42:54 -0400

> generally, or "NAME" (to more clearly reference the object type in

We don't even do that.  Joe quoted the relevant text, which is already in 
the document:

> It is up to the server how it interprets the user name
> credentials.

All the new text does is require that the check be done in the first place.