Subject: Re: [Emu] A comment on credential provisioning

From: "Hao Zhou (hzhou)" <[email-masked]>
Date: Wed, 9 Jul 2008 10:57:01 -0400

Bernard:
 
There might be multiple uses cases for credential provisioning and
enrollment. One case is just like you mentioned to initial bootstrap the
device. Other case might be provisioning additional credentials used for
other applications once the device has been fully provisioned. Third
case will be provisioning something useful for fast reconnect for future
authentications. Only in the first case, there is the potential MITM
attack you mentioned. In some deployment cases, this could be offset by
certain measures, such as using a relative strong password inner
authentication method, pre-provisioned trust anchor, restricted
environment etc. or tradeoff by admin for ease of deployment.   
 
In any case, the section cited is only discussing the use case needed to
be supported. The actual requirement section doesn't actually list any
requirement for credential provisioning. Other than the tunnel method
MUST support extensive attributes and EAP method. This will allow
someone to develop credential provisioning scheme using the EAP method
or attributes. We certainly don't want to develop a new tunnel method
preventing this from happening. Of course, security considerations
especially for MITM attack needs to be added. Are you ok with this
approach?  

________________________________

	From: [email-masked] [mailto:[email-masked]] On
Behalf Of Bernard Aboba
	Sent: Thursday, June 26, 2008 4:17 AM
	To: [email-masked]
	Subject: [Emu] A comment on credential provisioning

	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

---

From: "Bernard Aboba" <[email-masked]>
Date: Wed, 9 Jul 2008 14:12:09 -0700

I'm ok with saying that the tunnel method MUST support attribute
extensibility and EAP methods running within it.  As you say, an EAP method
could handle the credential provisioning, it doesn't need to be part of the
tunnel protocol.  The WFA's WPS EAP method is an example of this.  

If there is a section focusing on the use case, then it should make it clear
what concrete requirements come out of that (e.g. attribute extensibility,
EAP method support), as opposed to talking about the need to support
credential provisioning in general. 

From: Hao Zhou (hzhou) [mailto:[email-masked]] 
Sent: Wednesday, July 09, 2008 7:57 AM
To: Bernard Aboba; [email-masked]
Subject: RE: [Emu] A comment on credential provisioning

Bernard:

There might be multiple uses cases for credential provisioning and
enrollment. One case is just like you mentioned to initial bootstrap the
device. Other case might be provisioning additional credentials used for
other applications once the device has been fully provisioned. Third case
will be provisioning something useful for fast reconnect for future
authentications. Only in the first case, there is the potential MITM attack
you mentioned. In some deployment cases, this could be offset by certain
measures, such as using a relative strong password inner authentication
method, pre-provisioned trust anchor, restricted environment etc. or
tradeoff by admin for ease of deployment.   

In any case, the section cited is only discussing the use case needed to be
supported. The actual requirement section doesn't actually list any
requirement for credential provisioning. Other than the tunnel method MUST
support extensive attributes and EAP method. This will allow someone to
develop credential provisioning scheme using the EAP method or attributes.
We certainly don't want to develop a new tunnel method preventing this from
happening. Of course, security considerations especially for MITM attack
needs to be added. Are you ok with this approach?  

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Bernard Aboba
Sent: Thursday, June 26, 2008 4:17 AM
To: [email-masked]
Subject: [Emu] A comment on credential provisioning

Section 3.7 of the tunnel requirements document states the following: 

   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

   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.