eap Mailing List: Re: DISCUSS: draft-ietf-eap-netsel-problem

[Bernard Aboba (bernard_aboba]

This is a very good point, and one that has come up in other contexts 
recently.

The lack of a pre-configured profile is a very fundamental change which has 
multiple repercussions.  While the exposure of credentials can be solved by 
only allowing EAP methods meeting the criteria of RFC 4017, other problems 
are not as easy to deal with, such as determining whether the network or 
realm name advertised by the access point matches the credentials provided 
by the EAP server.   This issue has recently arisen not only with client 
unauthenticated access to Emergency Services (e.g. the EMU WG response to 
the IEEE 802.11u liaison request), but also in WiMAX, where the issue has 
arisen as to how the NSP ID can be verified during provisioning.

> From: Tim Polk <tim.polk [at] nist.gov>
> To: iesg [at] ietf.org
> CC: eap-chairs [at] tools.ietf.org,draft-ietf-eap-netsel-problem [at] tools.ietf.org
> Subject: DISCUSS: draft-ietf-eap-netsel-problem Date: Thu, 01 Nov 2007 
> 10:43:41 -0400
>
> Discuss:
> This discuss supports and expands Chris Newman's discuss with respect to 
> credential
> selection and use.
>
> The introduction begins by noting current network access clients are 
> typically
> preconfigured with access networks and corresponding identities and 
> credentials.
> The document devotes a great deal of energy to the implications of network
> discovery on the "identity selection problem".  However, credential 
> selection is
> viewed as simply another aspect of identity selection, and is treated far 
> less
> rigorously.  I beleive that new security issues with respect to credentials 
> are
> introduced by the move away from preconfigured access networks, and need
> to be discussed in more detail.
>
> Given the difficulties in UI design that Chris has already highlighted, I 
> would
> say that some credential types and authentication methods used with
> preconfigured access networks will be inappropriate for use when network
> discovery is employed.  Specifically, weaker credentials and mechanisms
> that reveal something about the credential would seem to be a bad idea.
>
> I believe that additional material in the body (either in 2.2 or in a new
> subsection 2.x) is needed, as well as an expansion of the security
> considerations section.