Re: DISCUSS: draft-ietf-eap-netsel-problem
From: Bernard Aboba (bernard_abobahotmail.com)
Date: Fri, 2 Nov 2007 07:03:59 -0700 (PDT)
Thanks.

One question is the security of the EAP method. If the RFC 4017 mandatory criteria are met, then even if there is not a pre-configured profile, an attacker with a rogue authenticator should not be able to obtain long-term credentials.

Another question is how the peer verifies that the EAP server is authorized to serve the selected realm. For example, if the identity "fred [at] example.com" is chosen, should the peer require that the Server-Id match "example.com" in some way? Does this imply that the layer 2 advertisement mechanism should provide the realm?

In WiFi this has arisen in the context of Emergency Services where it may be desirable to verify that a given network is "legitimate" in some sense before placing an Emergency Services call with it. Unfortunately, the SSID is not globally unique so that without a pre-configured profile, it is not possible to determine whether a given Server-Id is authorized to serve a particular SSID. However, one may be able to match the Server-Id against the realm advertised as described in RFC 4284.

In WiMAX this issue has issue has arisen because IEEE 802.16e only identified layer 2 networks by their NSP ID, not their realm. If the peer does not have a pre-configured profile (as they won't if they have just purchased a device at retail, but not signed up for a provider yet), then this creates a few problems:

a. The NSP ID is a number that is meaningless to an ordinary user.
b. NSP IDs are allocated by the IEEE 802 RAC, which only cares about ensuring against duplication, *not* about determining whether the numbers are being requested to legitimate spectrum owners.
c. As a result, there is no existing process to verify legitimate ownership of an NSP ID or correspondence between an NSP ID and a Server-Id.


One potential solution has been to advertise a realm instead (a la RFC 4284). This enables the advertised realm to be matched against the Server-Id.


Results generated by Tiger Technologies using MHonArc.