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

From: Darren Moffat <[email-masked]>
Date: Mon, 18 Dec 2000 19:28:43 -0800 (PST)

>   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.

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!).

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.

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).

--
Darren J Moffat

---

From: Martin Forssen <[email-masked]>
Date: Tue, 19 Dec 2000 11:08:09 +0100 (MET)

> I advocate using PAM that is quite a consession from me!).

Do we really need an informational draft here? I think it suffices to
say that the ssh-server is not always able to predict the questions
which would be asked and might therefore not be able to mimic it.

> 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.

The draft is not at all meant to be just a front end for PAM. It is meant
to be a fronted to anything which can be used without adding any other
specific code to the clients. I put the multiprompts in there because I
instinctively think there might be a need for them. We actually use them
in our implementation when we do SecurID authentication. Under some
circumstances the user is allowed to choose a new PIN for their card,
and to enter this we use two fields.

I think part of the differences between us here is that we think of
different user interfaces. If one envisions a tty-based interface then
restricting us to one question per message is not so bad since the old
question is probably still visible on the screen. But for a windows-
based interface it is much more user-friendly to have as many questions
as possible in one dialog instead of popping up one new dialog for each
question, at least IMHO.

> 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

I did not get the impression that there was any consensus to remove that
ability. Actually I did not feel that there was any need to change the
actual protocol at all. The draft needs some clarifications here and
there and that is all. At least that is the impression I got, but I
might be biased.

	/MaF

---

From: Sami Lehtinen <[email-masked]>
Date: Wed, 20 Dec 2000 14:29:00 +0200

Martin Forssen, on December 19. 2000, wrote:
  : On 18 Dec, Darren Moffat wrote:
  : > 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
  : 
  : I did not get the impression that there was any consensus to remove that
  : ability. Actually I did not feel that there was any need to change the
  : actual protocol at all. The draft needs some clarifications here and
  : there and that is all. At least that is the impression I got, but I
  : might be biased.

Even though you are biased :) there was consensus that the draft
currently looks good for what it is meant to do.

-- 
[[email-masked]          --  Sami J. Lehtinen  --           [email-masked]]
[work:+358 9 85657425][gsm:+358 50 5170 258][http://www.iki.fi/~sjl]
[SSH Communications Security Corp               http://www.ssh.com/]