Strong User authentication - Discussion thread

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