Re: keyboard-interactive

[Markus Friedl <markus%openbsd.org@localhost>]

On Thu, Jan 10, 2002 at 12:10:26AM -0800, Frank Cusack wrote:
> But KEXINIT (or any other non-auth message) /need not/ be handled
> "synchronously".

as i understand the transport draft, the KEXINIT
is handled by a lower layer, and if the client
send a KEXINIT message after the USERAUTH_REQUEST message,
then the lower layer must finish the key exchange
before continuing with the user authentication.

>  Well, at best it's not clear that it /must be/ handled
> synchronously.  Before I get to that, let me start with a problem in
> draft-ietf-secsh-userauth-13.txt, sec 2.1.  As someone else mentioned,
> it says
> 
>    An authentication request MAY result in a further exchange of
>    messages.  All such messages depend on the authentication method
>    used, and the client MAY at any time continue with a new
>    SSH_MSG_USERAUTH_REQUEST message, in which case the server MUST
>    abandon the previous authentication attempt and continue with the new
>    one.
> 
> However, this conflicts with the text of sec 2.2, which says
> 
>    The client MAY send several authentication requests without waiting
>    for responses from previous requests.  The server MUST acknowledge
>    any failed requests with a SSH_MSG_USERAUTH_FAILURE message.
>    However, SSH_MSG_USERAUTH_SUCCESS MUST be sent only once, and once
>    SSH_MSG_USERAUTH_SUCCESS has been sent, any further authentication
>    requests received after that SHOULD be silently ignored.
> 
> The conflict is that the server must acknowledge failed requests.
> Sec 2.1 says the server must ABANDON previous authentications if it
> receives another request.  So we're off to a bad start.
> 
> Sec. 2.2 goes on,
> 
>    Any non-authentication messages sent by the client after the request
>    that resulted in SSH_MSG_USERAUTH_SUCCESS being sent MUST be passed
>    to the service being run on top of this protocol.

i don't think this includes KEXINIT, because it's a lower layer.

> IMvHO, I would say the best course of action is to make no changes in
> the current implementation (other than perhaps handling an abortive (new)
> auth request), and instead spend energy getting the draft corrected/clarified.

yes, the only thing that needs to be handled is:

	(1) C->S:	USERAUTH_REQUEST(kbdint)
	(2) S->C:	INFO_REQUEST
	(3) C->S:	USERAUTH_REQUEST(pubkey)
	(4) S->C:	USERAUTH_SUCCESS/FAILURE

the draft reads:

>	The server MUST acknowledge
>	any failed requests with a SSH_MSG_USERAUTH_FAILURE message.

I guess this does _not_ mean that after message (3) the
server has to send a USERAUTH_FAILURE for message (1),
since this message has been handled by (2).
However, on receiving (3) the state associated with "kbdint"
must be abandonned.

> Again, I'd do nothing until the draft is clarified.  Especially given the
> expectation that current clients don't/won't actually show this behaviour.

-m