Subject: Re: Kerberos (Re: minutes from the SECSH working group meeting at the 48th IETF)

From: [email-masked] (Niels M�ller)
Date: 04 Feb 2001 18:34:25 +0100

Joe Salowey <[email-masked]> writes:

> In http://www.ietf.org/internet-drafts/draft-salowey-secsh-kerbkeyex-00.txt
> I defined a User Auth type  "external-keyx"  for this purpose.  In this
> message the client only has to specify a user name.  The credentials from
> the key exchange are then used to see if this user name is valid.  It is
> also possible to provide additional credentials (such as an authorization
> certificate) in this message.

Let's look a little closer at the case where no "additional
credentials" are needed (I don't see any case where additional
credentials make much sense, but that's a different discussion):

   byte SSH_MSG_USERAUTH_REQUEST
   string authorization-ID 
   string service 
   string "external-keyx" 
   boolean FALSE

Compare this to a request using the "none" method:

  byte      SSH_MSG_USERAUTH_REQUEST
  string    user name
  string    service name
  string    "none"

The difference is so small that I believe the "external-keyx"
authentication method is redundant. If the client uses some
keyexchange method that provides mutual authentication as a side
effect, it can just send a "none" request to login. The server checks
that the user name matches the name that was given during keyexchange,
and if it does, it lets the user log in right away.

This is a cleaner approach than skipping userauth completely (like
lsh's current behaviour when srp key exchange is used). To make it fit
perfectly in the protocol, the description of the "none" method in the
userauth draft should be updated,

Old:

: 2.3.  The "none" Authentication Request
: 
: A client may request a list of authentication methods that may continue
: by using the "none" authentication method.
: 
: If no authentication at all is needed for the user, the server MUST
: return SSH_MSG_USERAUTH_SUCCESS.  Otherwise, the server MUST return
: SSH_MSG_USERAUTH_FAILURE and MAY return with it a list of authentication
: methods that can continue.
: 
: This method MUST NOT be listed as supported by the server.

New:

: 2.3.  The "none" Authentication Request
: 
: A client may request a list of authentication methods that may continue
: by using the "none" authentication method.
: 
: If no authentication at all is needed for the user (beyond any mutual
: authentication that was performed during the earlier key exchange),
: the server MUST return SSH_MSG_USERAUTH_SUCCESS. Otherwise, the server
: MUST return SSH_MSG_USERAUTH_FAILURE and MAY return with it a list of
: authentication methods that can continue.
: 
: This method SHOULD NOT be listed as supported by the server, unless
: the key exchange provided mutual authentication.

Even if we don't consider key exchange methods like kerberos and srp,
the MUST NOT in the last paragraph in the description doesn't make
much sense to me. If the server provides some anonymous service that
doesn't require user authentication, it makes sense to me to include
"none" in the list of authentications that can continue.

Regards,
/Niels

---

From: Joseph Salowey <[email-masked]>
Date: Mon, 05 Feb 2001 10:08:41 -0800

I agree that  the additional credentials don't really belong in this message.  I
think we removed them in the external-keys message in the latest draft.

I'm a little uneasy about using the "none" authentication method.  When I was
thinking about the problem I thought "none" means no authentication, but from
your point of view "none" means nothing to do in this phase of
user-authentication (except of course authorize that the user name can be
accepted).  While I think this does make some sense I'm not sure it is cleaner or
clearer.

I also don't  think you need to advertise none since if it is acceptable and
sufficient  you will not get a list of methods when you send a "none" message,
you will receive a success. "none" either succeeds or returns a list of
acceptable methods to continue with.

Joe