Tero Kivinen <[EMAIL PROTECTED]> writes:
> Few comments about the draft.
[ details skipped ]
> I think this example is bad, because it can already be performed using
> the basic userauth draft, it contains banners, it contains password
> queries, it contains password change-request, and it even contains
> advantage compared to this method, it can use users native language
> when printing out most of the prompts.
I think I agree with all of your points. However, I suspect that you
don't understand which problem the proposal tries to solve (I'm not
entirely sure I understand it either).
The existing ssh userauth mechanisms lets the client side "drive" the
authentication process; the user decides, for instance, whether to
attempt login using a password or using some smartcard.
On the other side, we have sysadmins that want to be able to
configure, at the server side, exactly how the authentication process
should proceed, for instance using PAM (Pluggable Authentiction
Modules, available at least on Linux and Solaris).
PAM, in its current incarnations, is not well suited for ssh2 style
user authentication. For instance it is more or less impossible for a
PAM-aware ssh server to find out the correct list of methods for the
"authentications that can continue" field of the USERAUTH_FAILURE
message.
The point of the proposal, as I understand it, is to create a more
PAM-friendly mechanism, where the server tells the client what it has
to do at each step. I.e., the authentication process is driven by
the PAM-framework, which speaks more or less directly with the client
side. And where the level of abstraction in these message is similar
to PAM's.
One other valid point is supporting a text-based challenge response
authentication protocol, for instance for the hardware tokens where
the user types a PIN-code and a server challenge, to produce a
response that should be presented to the server for authentication.
But that particular application can be supported with a simpler
authentication method, something like the "keyboard-query-response"
you are describing.
Of course, it is possible that I have missed some important problem
that the "generic challenge response" authentication method solves. If
so, please correct me.
For reference, I include my notes about ssh2 and PAM below (also
available in the lsh distribution,
ftp://ftp.lysator.liu.se/pub/security/lsh). Since I wrote this,
possible work-arounds for some of the problems have been pointed out
to me.
/Niels
----8<----
I spent a day reading the PAM documentation. My conclusion was that
PAM is not at all suited for handling ssh user authentication. There
are three main problems, the first two of which would be show-stoppers
for any SSH server, while the last is a problem that affects servers
like lshd which doesn't fork() for each connection.
(i) The design of PAM is to hide all details about the actual
authentication methods used, and that the application should never
know anything about that. However, ssh user authentication is about
particular authentication methods. When the client asks which
authentication methods can be used, the server should be able to tell
it, for example, whether or not password authentication is acceptable.
When the client tries the password authentication method, no other
method should be invoked. But PAM won't let the server know or control
such details. This problem excludes using PAM for anything but simple
password authentication.
(ii) PAM wants to talk directly to the user, to ask for passwords,
request password changes, etc. These messages are not abstracted *at*
*all*, PAM gives the application a string and some display hints, and
expects a string back as the users response. This mode of operation
doesn't fit with the ssh user-authentication protocol.
If PAM would tell the ssh server that it wanted the user to chose a
new password, for instance, the server could the appropriate message,
SSH_SSH_MSG_USERAUTH_PASSWD_CHANGEREQ, to the client, and pass any
response back to PAM. But PAM refuses to tell the application what it
really wants the user to do, and therefore there's no way the server
can map PAM's messages to the appropriate SSH packets. This problem
excludes using PAM for password authentication.
(iii) The PAM conversation function expects the server to ask the user
some question, block until a response is received, and then return the
result to PAM. That is very unfriendly to a server using a select()
loop to manage many simultaneous tasks. This problem by itself does
not exclude using PAM for a traditional accept(); fork()-style server,
but it is completely unacceptable for lshd.
