Subject: Comment on draft-ietf-secsh-gsskeyex-06

From: Simon Josefsson <[email-masked]>
Date: Sun, 06 Jul 2003 13:09:22 +0200

The document says:

   The client SHOULD NOT send more then one gssapi mechanism OID unless
   there are no non-GSSAPI authentication methods between the GSSAPI
   mechanisms in the order of preference, otherwise, authentication
   methods may be executed out of order.

Besides having four (!) negations, I think some hints on how different
GSSAPI mechanisms should be handled instead would be useful.  E.g.:

   The client SHOULD send more than one mechanism OIDs only when all
   of the mechanisms are of the same priority, compared to non-GSSAPI
   authentication methods.  Otherwise, authentication methods may be
   executed out of order.  Thus, the client could first send a
   SSH_MSG_USERAUTH_REQUEST for one GSSAPI mechanism, then try public
   key authentication, and then try another GSSAPI mechanism.

FWIW, another implementation of the GSSAPI user authentication part of
the specification is available.  Patches (experimental!) for LSH using
GSSLib, Heimdal or MIT Kerberos 5, are available from
<http://josefsson.org/gss/gss-lsh.html>.

Thanks,
Simon

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 17 Jul 2003 16:30:35 +0200 (CEST)

>    key authentication, and then try another GSSAPI mechanism.

I think we can do something along these lines, but not specifically the
text you propose.  The problem is that SHOULD and SHOULD NOT are not
exactly inverses.

We say "you SHOULD NOT do X unless Y".  This makes a recommendation if Y
is false, but none if Y is true.

You say "you SHOULD do X if Y".  This makes a recommendation if Y is true,
but none if Y is false.

> <http://josefsson.org/gss/gss-lsh.html>.

Wonderful; thank you.

-- Jeff

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 31 Jul 2003 02:25:47 +0200

(Sorry for the delay, vacation time.)

> You say "you SHOULD do X if Y".  This makes a recommendation if Y is true,

You are right, my text isn't good.  Still, some improvement on that
paragraph probably wouldn't hurt.  The rather obvious intended
behaviour is currently easily lost in the complicated language.