In message <>,
Tero Kivinen writes:
>
> BTW. There is no real difference compared to the RSA private key on
> the disk and in smartcard. The authentication is same, only thing that
Yes.
> differs is how easy it is to stole the private key. Note that when you
> are using smartcards the pin/passphrase is propably much much more
> easier than what you use for the key that is on the disk, so getting
> the pin by looking over persons shoulder is much easier.
Ok, yes, /in general/ a pin may be easier to acquire than a
passphrase for a disk-based private key. But if you steal the pin
you also need to have the smartcard, which presumably is more
difficult (and definitely more noticeable). That's the entire
point of smartcard authentication isn't it? 2-factor vs. 1-factor.
>
> > 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".
>
> There is no way you can do that anyways. The user can write his own
> client that can fake to do a smartcard authentication when it is doing
> normal disk based private key authentication. I dont see any use for
> that kind of false security.
Right, that's my point, a client can ignore a technology-specific flag.
But I would like to see if there is a way to force such a technology
specific flag (in the protocol, not administrativly), I do believe it is
useful (it IS useful). I think it's a worthwhile addition even if
the flag is only advisory, it quickly tells [a compliant] client how to
obtain a signature (or whatever the authentication data may be).
Anyway, let's kill this part of the discussion; it's off-topic for
this thread.
>
> > > and it even contains
> > > advantage compared to this method, it can use users native language
> > > when printing out most of the prompts.
> > I don't follow you. This example can use the user's native language.
>
> How? The server doesn't know how to speak Finnish. My client does know
> that. If we use the built-in messages without embedded strings then
> the client can print out dialogs in Finnish, but if the server sends
> me a message saying that "Change your password", my client doesn't
> know what the server is asking, and cannot translate it to "Vaihda
> salasanasi".
Ahh.. I thought you were referring to the language tags. Yes, you
are correct, specific messages can easily be translated when they
are "message codes" (PASSWD_CHANGEREQ) but the language tag also
provides some of that if the client is smart enough.
But specific message codes are not flexible.
Perhaps a good addition would be a language tag sent by the client
in the initial exchange to specify a preferred language for
subsequent exchanges?
I'm not sure that the proper place is in the auth protocol though,
perhaps in the transport spec (which is the first place a client
might receive language specific messages, I think).
~frank
