keyboard-interactive

[Mark D. Roth]

On Wed Jan 09 23:21 2002 +0100, Markus Friedl wrote:
> currently openssh works like this:
> 
> there is a mainloop that dispatches the packets and calls different
> functions depending on the message type.
> 
> so when sshd receives a REQUEST message the mainloop calls
> 	input_userauth_request()
> 
> input_userauth_request() needs to parse the REQUEST message and
> (for kbd-interactive) contruct a INFO_REQUEST message by calling
> some PAM API and return the control to the mainloop.
> 
> now the client can send _any_ packet, e.g. a KEXINIT
> for rekeying or a new REQUEST message for a different 
> authentication method (e.g. pubkey).
> 
> if the client sends the INFO_RESPONSE then input_userauth_info_response()
> needs to verify the reponse.

OK, so how about this:

 * Call the main loop from the PAM conversation function with some
   state telling it where it was called from.

 * When the main loop gets the next message from the client, it can
   return control to the PAM conversation function.

 * If the client sent an INFO_RESPONSE message, the PAM conversation
   function returns the client's response, and the PAM transaction
   continues normally.

 * If the client sent some other type of message, the conversation
   function can return PAM_CONV_ERR to abort the PAM transaction.  It
   should also set some state to indicate that the PAM transaction was
   aborted.

 * When pam_authenticate() returns, if the transaction was aborted,
   return control to the main loop to handle the request that the
   client sent.

There are some obvious semantics to be worked out in terms of how the
state is maintained, but the PAM code itself would be fairly
straightforward.  Or is there something I'm missing here?

-- 
Mark D. Roth <roth at feep.net>
http://www.feep.net/~roth/