Subject: [KEYPROV] [issue26] Interaction between DSKPP and User Authentication

From: Andrea Doherty <[email-masked]>
Date: Wed, 12 Sep 2007 18:56:05 +0000

New submission from Andrea Doherty <[email-masked]>:

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.

----------
messages: 69
nosy: andrea, keyprov
priority: critical
status: unread
title: Interaction between DSKPP and User Authentication

_________________________________________________________
KEYPROV Roundup Issue Tracker <[email-masked]>
<http://www.tschofenig.priv.at:8080/keyprov/issue26>
_________________________________________________________

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