Subject: [Emu] A comment on credential provisioning

From: Bernard Aboba <[email-masked]>
Date: Thu, 26 Jun 2008 01:16:47 -0700

Section 3.7 of the tunnel requirements document states the following: 

3.7.  Credential Provisioning and Enrollment

   When a peer has authenticated with EAP, this is a convenient time to
   distribute credentials to that peer that may be used for later
   authentication exchanges.  For example, the authentication server can
   provide a private key or shared key to the peer that can be used by
   the peer to perform rapid re-authentication or roaming.  In addition
   there have been proposals to perform enrollment within EAP, such as
   [I-D.mahy-eap-enrollment].

   The tunnel method SHOULD support carrying credential distribution
   protocols.Given the extensive EMU WG discussion relating to ZKPP, and the need to avoid MITM attacks, 
it seems quite odd to me that the WG would so readily take on the credential provisioning problem. 

As we move increasingly towards a world in which network access will be increasingly likely to 
require authentication, mechanisms for credential provisioning will become increasingly important. 
For example, consider the situation where someone has obtained a spanking new handset/PC/notebook
and wishes to get connected in an environment where authentication is required for all access 
mechanisms:  VPN/WLAN/Ethernet/PPP, etc.  

That said, moving from a state where no credentials, trust anchors or policy is provisioned to
one where everything is set up can be quite tricky:

a. No trust anchor may be provisioned, which makes server certificate authentication difficult. 
Without server certificate authentication, we need to be very careful about MITM attacks!

b. If the server may be a rogue, then the dictionary attack protection provided by the TLS
tunnel is worth much.  This implies that the credential provisioning mechanism itself
needs to be immune to dictionary attack.  Merely binding the inner authentication to 
the outer tunnel only demonstrates that there is no MITM attack, but it doesn't demonstrate
that the server is authentic.  Unless the client is willing to consider its password compromised
if the cryptographic binding fails (a nasty situation) we're back to the pure password
discussion initiated by Glen and Dan, or a poor man's substitute, such a progressive
disclosure, which was used in the WFA WPS EAP method. 

Given all of this, my advice would be to delete Section 3.7.  Leaving this in is likely to 
lead to a lot of additional discussion which is largely tangential to the core of what
needs to be accomplished.  If and when the WG decides to add the password-based
method item to the Charter, we could bring this item back.  But until then, it seems
like it would be best ruled out of scope.

_______________________________________________
Emu mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/emu