Frank Cusack <[EMAIL PROTECTED]> writes:
> Tero Kivinen writes:
>
> > For example most of the case the smartcard are using the normal public
> > key authentication (RSA). If there are some other kinds smartcards
> > that use some other authentication methods, then it is better to
> > separate them based on the authentication method (public key, one time
> > password) not based on the technology (smartcard).
> >
>
> I disagree. [Arguably] RSA authentication using a smartcard is much
> more secure then RSA using a private key stored on disk. The current
> definitions do not allow for specifying that RSA must be done via
> a smartcard.
>
> I'm not saying that authentications /should/ be classified according
> to technology, only that there definitely should to be a way to
> "mandate" that an authentication uses a certain technology.
> That said, I don't know how to FORCE a user to use a smartcard
> vs. a disk-based key -- a "non-compliant" client implementation
> could ignore any flag from the server saying "use x technology".
You can't base any security on the assumption that clients will be
"compliant".
If you want to mandate use of a physical smartcard, the way to go is
to make sure that the private key is known to the smartcard, but *not*
to the user. I.e., you need a tamperproof smartcard. (Whether or not
tamper-proof devices exists in reality, I don't know).
> 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.
As far as I can tell, having the client list available device types
does *not* require the client to know anything (or be recompiled,
whatever) just because you obtain a new type of device. All that's
needed is a line "Keybord-interactive-devices foo,bar" in the user's
.ssh/config file.
> As many noticed, this draft really is meant for PAM, which is indeed
> a generic keyboard-interactive authentication. I added the non-keyboard
> types to attempt to deal with PAM_BINARY, but I do agree that it is
> too limiting to add that into this draft. Also, PAM_BINARY is really
> a kludge to make PAM do things that the original design didn't
> account for.
As I read the PAM spec, one of the primary design goals of PAM is to
support sophisticated authentication methods (for instance smartcards
using public key cryptography). But I have too little experience with PAM
to say whether it has failed meet this goal or not.
/Niels
