Re: Comments for draft-ietf-secsh-auth-kbdinteract-01.txt

[Frank Cusack <fcusack%fcusack.com@localhost>]

OK, this is the last of the old kbdint messages which I think still
could stand some addt'l comment.

On Mon, Dec 18, 2000 at 07:28:43PM -0800, Darren Moffat wrote:
> >   The server SHOULD NOT reply with the SSH_MSG_USERAUTH_FAILURE
> >message
> >   if the failure is based on the user name or service name; instead
> >it
> >   SHOULD send SSH_MSG_USERAUTH_INFO_REQUEST message(s) which look
> >just
> >   like the one(s) which would have been sent in cases where
> >   authentication should proceed, and then send the failure message
> >   (after a suitable delay, as described below).  The goal is to make
> >it
> >   impossible to find valid user names by just comparing the results
> >   when authenticating as different users.
> 
> I think the goal here is basically sound, however as you point out
> this SHOULD NOT may actually be hard to implement in some cases, but
> being a SHOULD NOT rather than a MUST means that if it is too hard for
> a particular system then it can reply SSH_MSG_USERAUTH_FAILURE
> 
> >This is not good, as the server doesn't necessarily have a method to
> >get the possible messages from a device (library etc.). For example,
> >we don't know what PAM would query from the user if it existed. PAM
> >doesn't allow invalid users to continue the login after account
> >checkin. Point being, with PAM the server shouldn't take any stand on
> >what the PAM queries or tells the users; this depends on the PAM
> >configuration.
> 
> Whither or not PAM is used in a particular secsh server side is an
> implmentation detail, but it is an important one because using PAM
> opens up the scope for messages and interaction outside of the control
> of the ssh server software.

And this bears mentioning, if using PAM this is trivially easy; any PAM
module (that prompts for information) has this same design consideration.
If backended by PAM, sshd shouldn't really do anything special.  IE, if
PAM fails without sending any kind of prompt, then sshd shouldn't add an
artificial prompt.  But if sshd is doing the auth "natively" and finds
"no user" it SHOULD still prompt the user.

> It actually depends on exactly how PAM is used how difficult this
> becomes to implement.  Personally I would say that if PAM is being
> used:
> 	pam_authenticate()
> 		PAM_SUCCESS =>	SSH_MSG_USERAUTH_SUCCESS
> 		PAM_USER_UNKNOWN => SSH_MSG_USERAUTH_FAILURE
> 		PAM_NEW_AUTHTOK_REQD => call pam_chauthtok() and
> 			send SSH_MSG_USERAUTH_SUCCESS if it returns
> 			PAM_SUCCESS otherwise SSH_MSG_USERAUTH_FAILURE
> 	Most others result in SSH_MSG_USERAUTH_FAILURE.
> 
> I guess it depends on exactly how you see PAM and kbdinteract
> working together.  The way I see it is that any converstaion that PAM
> does with the user is one kbdinteract "session" regardless of how many
> PAM modules actually get run - since there is no (supported) way for the PAM
> application to get information about which modules succeed and which
> fail or to run only certain modules.
> 
> I suspect that in many cases things like Engima Safeword and Securid
> will actuall get implmented as PAM modules rather than coded directly
> into the secsh server software.  Or at least the should be for systems
> that support PAM to avoid code duplication.
> 
> I think what is needed here is an informational draft on how PAM
> and kdbinteract are used with each other.  While it is good that we
> consider PAM in this draft I don't think kdinteract should depend on
> it or make specific consessions for it (For those that know how much
> I advocate using PAM that is quite a consession from me!).

I hope you feel differently now. :-)  PAM is a good thing.  It's not
perfect, but it is better than what existed before.  kbdint was designed
specifically with PAM in mind, I am of the opinion that yes, specific
concessions should in fact be made for PAM.

> To back this up futher the example in the draft of a user changing
> their password couldn't be coded that way using PAM since you don't
> know what modules in the PAM stack are going to prompt you in advance,
> it may be that the password fails some strength checks between the
> inital user entry and the re-entering and the output of the error
> message is dependant on what the user typed.
> 
> But the draft as it stands is sufficiently flexible to allow for an
> implmentation with PAM since the interaction would be a series of single
> prompt messages.  I just don't see the point in the added complexity
> of allowing for multiple prompts.

PAM modules can send multiple prompts.  The standard example is the
change password prompt.  It's MUCH better to send this as a single
protocol exchange so that a GUI client can present a more sensible
dialog.  With two seperate exchanges, the messages are disconnected
from each other (what does "enter it again" mean in the second exchange?).

> IIRC there was also disussion in the wg meeting last week about removing
> the ablity to send multiple prompts in one SSH_MSG_USERAUTH_INFO_REQUEST
> can someone remind me on the consensus of that (if there was one) ?  I
> seem to remeber someone saying something that it helped them implement
> PAM support on the server (I can't see how this would be the case since
> the PAM framework doesn't support multiple prompts for input with out
> user feedback - it maybe someone has a module that does something like
> this but the PAM framework doesn't require it).

Sure it does (both support and require it).

/fc