keyboard-interactive

[Mark D. Roth]

On Tue Jan 08 15:29 2002 +1100, Damien Miller wrote:
> I have been wanting to rewrite the PAM kbd-interactive support for a
> while now, but have hit a brick wall with the PAM api.
> 
> The PAM API wants to ask all the questions and gather all the responses
> in a single conversation function. This doesn't work well with the SSH
> protocol, where userauth messages can arrive in any order. 
> 
> The current kbd-int PAM support assumes that it can get a response
> immediately and somewhat abuses the dispatch API to get at it. It
> probably isn't robust in the face of clients who send requests in a
> funny order.
> 
> If any PAM experts can offer a solution to this, it would be greatly
> appreciated.

I'm sure you're much more well versed in the SSH protocol than I am,
but from a glance through draft-ietf-secsh-userauth-13.txt, I don't
understand the problem.  The last paragraph of section 2.1 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.

Based on this, it seems to me that there's no problem with assuming
that you can get back responses immediately from the PAM conversation
function.  The only catch is that if you receive another
SSH_MSG_USERAUTH_REQUEST message, you need to abort the PAM
transaction and begin processing the new request.

I see two possible ways to do this:

1. Call setjmp() before calling pam_authenticate().  If you get a
   SSH_MSG_USERAUTH_REQUEST message in the conversation function,
   simply call longjmp() to pop back out of the authentication
   request.

2. If you get a SSH_MSG_USERAUTH_REQUEST message in the conversation
   function, set some state to indicate that the PAM authentication
   should be aborted and return PAM_CONV_ERR.

Method (2) is obviously cleaner, but doesn't guaruntee immediate
return from pam_authenticate().  This is because the module which
called the conversation function doesn't necessarily have to fail if
the conversation function failed.  And even if the module does fail,
if it's control flag isn't "required", subsequent modules may still be
called.  However, this shouldn't have any bad effects other than a
short delay.


> What I would really like to see in PAM is the ability call to a function
> to collect the auth queries and another to send the responses at a time
> of my choosing.

There's no way to do this with PAM, and IMHO that's a good thing.
When you have multiple PAM modules in the stack, you can't necessarily
tell whether a subsequent module will be called until you know whether
the first one succeeds.  In fact, you could even write a single PAM
module which asks multiple questions, where the next question is
determined by the response to the previous question.  None of this
would be possible if all the questions had to be batched up at once,
which is one of the reasons why the PAM API is designed the way it is.


I hope this information is useful.

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