|
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?
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.
|
