Subject: [KEYPROV] DSKPP: AuthenticationData in <ClientHello>

From: "Doherty, Andrea" <[email-masked]>
Date: Wed, 12 Sep 2007 14:48:11 -0400

As noted in draft-doherty-keyprov-dskpp-01, Security Considerations
(Section 7.5), "Attacks on the Interaction between DSKPP and User
Authentication":
   If keys generated in DSKPP will be associated with a particular user
   at the DSKPP server (or a server trusted by, and communicating with
   the DSKPP server), then in order to protect against threats where an
   attacker replaces a client-provided encrypted R_C with his own R'C
   (regardless of whether the public-key variant or the shared-secret
   variant of DSKPP is employed to encrypt the client nonce), the server
   SHOULD not commit to associate a generated K_TOKEN with the given
   cryptographic module until the user simultaneously has proven both
   possession of the device that hosts the cryptographic module
   containing K_TOKEN and some out-of-band provided authenticating
   information (e.g., a temporary password).

However, as defined in Section 4.3.1.3, when the protocol is run over a
transport layer that is not secure (e.g., HTTP), the use of
AuthenticationData does not properly bind K_TOKEN with password:
	K_TOKEN = f1 (R_S, R_C), but
	AuthenticationData = MAC (password, R_S, serverURL, (client)ID) 

This makes the protocol susceptible to a MITM.  It would be better if:
	AuthenticationData = MAC (password, R_S, R_C, ....).

But this means that for four-pass, AuthenticationData should not be
passed in <ClientHello> since that would force R_C to be sent in the
clear.  The strongest reason for putting AuthenticationData in
<ClientHello> was to handle DoS by ensuring that server resources were
not bound until the server could authenticate the user.  But, there may
be other application-oriented ways of handling DoS, and MITM is more
important. Therefore, ignoring AuthenticationData in <ClientHello> for
four-pass, and requiring the server to only rely on AuthenticationData
passed in <ClientNonce> would be preferred.

For two-pass, AuthenticationData should still be passed in
<ClientHello>, which includes R_C.  However, if we assume the server
does not know the relationship between users and specific crypto modules
(i.e., the server does not have a priori knowledge that user A is the
owner of token B), then another solution could be to require (very)
strong passwords and perform:
	Hash (password || device_public_key)

This combination is easy to verify (for the correct server), while not
exposing the password in the clear, but rather binds it to a specific
public key, which is also transmitted.  This would work equally well for
2-pass based on shared secrets as that based on public keys.  For 2-pass
based on a password, we could assume both passwords are strong.

Of course, the best solution is requiring TLS/HTTPS, but a stated goal
of the DSKPP is to support HTTP.

Comments would be appreciated.  I'll post this as issue in the Issue
Tracker.

Andrea

_______________________________________________
KEYPROV mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/keyprov