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

From: [email-masked] (Niels Möller)
Date: 01 Oct 2004 12:33:09 +0200

Damien Miller <[email-masked]> 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

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 04 Oct 2004 16:25:01 -0400

>    that implementations support.

Good.

>    the server, the server should respect the client preferences).

Hrm.  I guess I'd prefer to do this only when the client sends an empty 
list, indicating "any method is OK".  This is particularly useful if the 
client wants to mix other methods in with the kbd-interactive ones in its 
list of things to try.  For example, the client might want to try 
mechanisms in this order:

external-gssapi
gssapi-with-mic/kerberos
kbd-interactive/challenge-response-token
public-key(*)
kbd-interactive/one-time-password
kbd-interactive/pam
password

(*) The key pair actually resides on a smart card, and we want to try the 
token they can look at before the one they have to insert into the machine.

>    preferences, and can abort the keyboard-interactive if it so

Good.

I agree the approach you describe would improve the situation.  It is 
entirely possible that a PAM-based implementation will not in reality be 
able to tell what the backend is really doing or assign different method 
names to different backend modules.  This is particularly complex as it may 
be the case that multiple modules will be used in the same conversation, 
and it is sometimes fuzzy where the line is (for example, a module may use 
a password answer collected by a previous module).

IMHO the solution to this would be for PAM-based implementations to use a 
single submethod name to refer to the whole PAM mess.  That way, the server 
can say to the client "I'm using PAM, but I can't tell you more than that".

In addition to the changes you propose, I think further improvement can be 
had by providing a mechanism by which the client can request from the 
server a list of supported submethods.  This is necessary if the client 
wants the user to select which methods should be tried and in which order.

-- Jeff