Pending OpenSSH release: contains Kerberos/GSSAPI changes

[Jeffrey Hutzelman]

On Friday, January 30, 2004 21:57:42 -0500 Jeffrey Hutzelman 
<jhutz at cmu.edu> wrote:

> The spec says clients SHOULD set mutual_req to "false", which means not
> requesting mutual authentication.  I know of no mechanisms which will do
> mutual auth (and produce a context with mutual_flag set) if the client
> sets mutual_req to "false".
>
> What this means is that a compliant client is _likely_ not to work with
> the openssh server as it stands.  It is possible to be compatible with
> openssh and still be compliant (SHOULD means approximately "do this
> unless you have a good reason not to"); however, not all compliant
> clients will be compatible with openssh.  Note that the openssh client is
> an example of a client that interoperates with the openssh server (AFAIK)
> and is compliant (at least, with respect to this issue).
>
> The spec does not specifically prohibit openssh's current behaviour, but
> it is likely to cause interop problems.  IMHO, the fact that this is not
> specified more clearly is an oversight -- the spec does not provide
> enough information to write interoperable clients and servers.  Thank you
> both for finding this; I'll be addressing the issue in the next version.

draft-ietf-secsh-gsskeyex-08.txt did not contain any changes related to 
fixing this issue.  However, I am proposing adding the follosing text
to the next version of the draft...

In key exchange:

The server MUST NOT fail the key exchange on the basis of the values of
any of conf_avail, replay_det_state, sequence_state, or anon_state.


In user authentication:

The server MUST NOT fail user authentication on the basis of the values
any of conf_avail, replay_det_state, sequence_state, or mutual_state.


-- Jeffrey T. Hutzelman (N3NHS) <jhutz+ at cmu.edu>
   Sr. Research Systems Programmer
   School of Computer Science - Research Computing Facility
   Carnegie Mellon University - Pittsburgh, PA