Re: keyboard-interactive auth

[der Mouse <mouse%Rodents.Montreal.QC.CA@localhost>]

>> (OK, the real issue is that OpenSSH should adjust its behaviour, but
>> given the huge installed base that won't happen in a hurry).
> Well, no.  AFAIK OpenSSH's behaviour in this regard is compliant with
> the kbd-int draft.

The latter does not necessarily imply the former; it's entirely
possible that certain behaviour should be adjusted even though it's
entirely conformant.

In this case, I think it should.  See below.

> The server cannot know a priori whether a delegated authentication
> mechanism (probably PAM or BSD-auth in the case of OpenSSH) is going
> to return an instant failure when queried.  The draft explicitly
> caters for this circumstance, allowing the server to return
> SSH_MSG_USERAUTH_FAILURE immediately.

Sure - but when that failure message lists keyboard-interactive as a
productive method to continue authenticating with it is, at the very
least, confusing.

And that's why I think it should be "adjusted" - and the aspect of it
which I think should be changed.

The situation is a bit messy; as a comment in my source (in the
USERAUTH_FAILURE handling) says:

 /* Four cases:
        (1) partial success, current algorithm listed in methods
                current alg running
                -> continue current alg
        (2) partial success, current algorithm not listed in methods
                current alg succeeded, more auth needed
                -> end current alg
                -> pick next alg
                -> start it
        (3) no partial success, current algorithm listed in methods
                not sure what this can mean - maybe, eg, public key
                failed, but another public key might succeed?
                -> retry current alg
        (4) no partial success, current algorithm not listed in methods
                current alg failed, try another
                -> end current alg
                -> pick next alg
                -> start it
 */

The semantics of these cases (the indented text with no arrow after the
numbered lines) are not clearly laid out in the drafts, as far as I can
tell; what I wrote in that comment was guesses.  (My guess about
publickey seems to have matched current practice; about
keyboard-interactive, not.)

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse%rodents.montreal.qc.ca@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B