Strong User authentication - Discussion thread

[Michael StJohns <msj@nthpermutation.com>]

For the purposes of this discussion, I'm considering strong authentication as authentication that's resistant or immune to replay attacks and to attacks based on the capture of the login interaction.

The problem I'm trying to solve?  Seriously - we're still using plaintext passwords!


Most of the simple strong authentication models available are challenge/signature approaches.  The token generates a challenge, and the user logging into the token generates a signature over the challenge (and possibly other data).  The signature can either symmetric based (e.g. something like the CHAP protocol for IMAP or POP where both sides know the password), or asymmetric based (where the token has the public key and the user has the private key).

Other pseudo-strong models include OTP approaches based on a known shared secret seed, a PRNG and a common time source.

Let's assume we want to provide support for one or more of the above, and that we want to define an extensible model so we don't have to do this again.

On the user management side, we need to tag the user with his role, the mechanism being used for the login, and the authenticator material (e.g. shared secret, public key, shared seed).  But the user management piece could be a completely implementation dependent and not require changes to the PKCS11 model.   

As a general approach, C_Login doesn't constrain the format of the pin provided - it can be a string of any length of UTF8 characters.  Implementing the above may be as simple as encoding a user name and the user's calculated authenticator (e.g. OTP password, signed challenge)  in the pin field.

The last piece of the puzzle is how to get the challenge (if the mechanism needs it) out of the token.  One simple approach would be to define a CKU_GET_CHALLENGE and have C_Login place the challenge in the space provided for the PIN.  I'm slightly leery of this because the pin field in C_Login has always been defined as an "IN" field, but since the field wouldn't be written unless you specified this user type, it would probably work.  The other approach is to define an object with a well known handle and use C_GetAttributeValue to grab the challenge from a specific attribute (CKA_VALUE?).


Session security based on strong authentication:

The above all deal with the basics of enhancing the C_Login function, but may not provide a lot of additional security.  They change the state of the token from logged out to logged in, but do nothing to protect the login session itself.  An attacker could possibly insert data between the user and the token. 

One possible enhancement here is that the creation of the login session could result in the creation of shared symmetric keys on both sides of the session (on the token and with the user).  Those keys could then be used to "sign" each of the PKCS11 transaction calls.  That would require definitions of how to serialize each PKCS11 call and how the serialization would be signed.  That would also require being specific about the size of CK_ULONG and all the rest of the types.

Thoughts?

Mike