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 PROTECTED] Sent: Wednesday, July 09, 2008 7:57 AM To: Bernard Aboba; emu@ietf.org 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 PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bernard Aboba Sent: Thursday, June 26, 2008 4:17 AM To: emu@ietf.org 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 Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
