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

[nisse%lysator.liu.se@localhost (Niels Möller)]

Damien Miller <djm%mindrot.org@localhost> writes:

> This isn't entirely true: you can specify "method1,method2,method3" and
> sshd will allow authentication using method3 if the method1 and method2
> don't exist.
> 
> I'm not sure what you would have us do: kbdint doesn't seem to provide a
> way for a server to report supported methods to a client and I don't
> think it is correct to just ignore what a client has specified and
> continue with a random method that the server picks.

I think the following three steps would improve the situation:

1. Require the names listed in the submethods field to be proper ssh
   names. I.e. standardized names without @, local/vendor stuff with
   @domain attached. Encourage documentation of the @domain things
   that implementations support.

2. Allow the server to use methods not on the client's list, in case
   none of the listed methods is implemented or configured for use by
   the server. (For methods that are implemented and acceptable for
   the server, the server should respect the client preferences).

3. Use the name field in the SSH_MSG_USERAUTH_INFO_REQUEST (or
   introduce a new field, if the "name" field is intended for the UI)
   to tell the client which method the server has selected. This way,
   the client can know if the server is about to ignore its submethods
   preferences, and can abort the keyboard-interactive if it so
   wishes.

I'm not sure how well [1] fits with PAM, but I think the easiest way
out for a PAM backend is to always ignore the submethods list. That is
natural, since PAM, by design, refuses to expose any information
whatsoever about the selection of underlying mechanisms. In step [3],
the PAM backend could send the empty string as the method name, to
indicate that it has no clue about which mechanism is actually used.

(If it turns out that the above, which seems like a perfectly
 reasonable protocol design to me, is for some reason impossible to do
 with a PAM backend, and that is considered a show stopper, then I
 think I'd prefer to have two distinct methods, pam-over-ssh and
 keyboard-interactive, which each does its respective job well, than
 to have a compromise that sucks for all uses).

Regards,
/Niels