On Wed, 24 Feb 1999, Frank Cusack wrote:
> Here is another version of the draft. Please comment before Friday
> so I can submit a reasonably non-controversial version :)
> before the conference deadline.
That is a noble goal:-)
The main problem here is that we are trying to merge two different
philosofies (sp?) for doing user authentication.
> In message <>,
> Martin Forssen writes:
> > I would feel more comfortable if we used the same list format as the
> > sshauth draft does (ie a comma-separated string). I would like to
> > propose the following format instead:
> >
> > byte SSH_MSG_USERAUTH_REQUEST
> > string username
> > string service
> > string "password-plus"
> > string methods
> >
> > Where methods is a comma-separated strings of supported authentication
> > methods using the keyboard input type.
> >
> > The rationale for having the methods field is that the user may have
> > multiple methods availbale (for example both SecurID and CryptoCard).
> > This list should be normally be provided by the user. The server should
> > also be able to ignore this field if it knows from some other context
> > which method(s) are avilable for the user.
>
> This requires client knowledge of the auth device; and a new client
> would be required for each auth device. One of the goals was to
> not require new client code to support new authentications that
> /could/ be handled by existing methods.
No, read my text again. I meant the list of methods to be supplied by the
user. For example by setting some option to a list of devices he/she has.
The list is also only advisory to the server. I fully agree with the goal
of not having to update the client to support new methods (as long as they
are text-based) and my proposal was carefully though out to allow just
that.
> So as long as the input happens with the keyboard, I think specifying
> the actual device is better left in the server code. Maybe you
> can provide an example where the server does need to know what devices
> are available?
Well the user might have both but left one of them at the office? But the
point is that my change gives the server the choice of either letting the
client specify method or to just override the client. A PAM-driven server
might just ignore this field.
Therefore I think my proposal is more flexible since it allows for
different server implementations to do it differently. It allows for both
philosofies to be implemented in the server.
Apart from this I have no major issues with your draft. I have a couple of
small comments which will appear in a later message (after I reach the
office despite all the bussdrivers being on strike:-().
/MaF
