Re: Ambiguities in section 3.1 of the keyboard-interactive draft

[pgut001%cs.auckland.ac.nz@localhost (Peter Gutmann)]

nisse%lysator.liu.se@localhost (=?iso-8859-1?q?Niels_M=F6ller?=) writes:

>The default openssh configuration for some linux distributions have disabled
>plain "password" authentication in favour of keyboard-interact, my guess is
>that they do this in order to work better with PAM.

That was where the example I used in my message came from: Standard "password"
is disabled, and if you send "password" as the submethod OpenSSH immediately
drops the connection with a userauth-failed response.  OTOH if you leave
submethods empty, the same "password" authentication succeeds without any
problems.  This behaviour is compliant with the spec, but only because
execl( "/usr/games/hack", ... ) would also be compliant with the spec.

>I think this is bad for interoperability, and think it would make sense to
>make a strong recommendation that if a particular system supports old
>fashioned authentication with a username and password, then it SHOULD also
>support the USERAUTH_REQUEST "password" method when speaking the ssh
>protocol.

It does actually support standard passwords, you just have to be very careful
not to tell it that that's what you're doing.

(That's pretty weird behaviour: You can't send it a standard password, but you
 can send it the password dressed up as keyboard-interactive auth provided you
 don't tell it that it's a password).

>The "name" field doesn't make much sense for me. First I assumed it was a
>user name, which makes no sense (what is a client supposed to do if it
>differs from the user name given in the USERAUTH_REQUEST message?).

Yeah, I've got problems with those fields as well:

/* Exactly whose name is supplied or what the instruction field is for is left
   unspecified by the RFC (and they may indeed be left empty), so we just skip
   it.  Many implementations feel similarly about this and leave the fields
   empty */

I really wasn't sure what to do with these fields.  Maybe they should be
marked as deprecated or extremely optional if no-one else can figure out what
to put in them either.

>I also want to note that this and SSH_MSG_USERAUTH_INFO_RESPONSE are the only
>request so far that uses a variable number of entries in this way, which
>requires some additional complexity of the code for formatting and parsing
>these messages (at least in my implementation, which uses a general
>formatting function controlled by a format string; I'd prefer not having to
>introduce loop constructs in the format...).

It also makes it extremely difficult to implement in any app that doesn't have
a UI, i.e. where you can't just keep asking the user for input until the
server is satisfied.  Fortunately for standard password auth I've never found
anything that sends more than one prompt, but I'd like to see a bit more
consideration given to non-interactive apps.  Currently the draft seems to
assume that the client-side is tied to a live user in front of a terminal who
can read, interpret, and respond to each prompt, which isn't always the case.

>I think we should also say that after the server has tried all methods on the
>list that it recognizes and supports, it is free to try any other submethods
>of its choice. This is what happens in the common case that the client sends
>an empty submethods list.

Yup, good idea.

Peter.