eap Mailing List: Re: Issue 256: Miscellaneous NITs

[Jari Arkko (jari.arkko]

This is the part of Bernard's issue that I don't see
addressed in the new draft. Hopefully I just missed
some text somewhere else than in the Security Considerations
section. If not, I have a text suggestion below which
you can add & resubmit.

> Section 4
>
> "  Identity hint information is delivered inside an EAP Identity Request
>    before the user authenticates to the network, and before the network
>    is authenticated to the user.  This information can be modified by an
>    attacker.  Therefore, it MUST be considered an unauthenticated hint
>    that does not override any local policies at the peer."
>
> I think you need to say a bit more about what an attacker could do with
> this and the potential counter-measures.  The main threat seems to be
> discovery of the potential peer identities. If the peer is using a weak
> EAP method for some identities, this might be used by an attacker to
> steal credentials for that identity.
>
> So you might refer to specific local policies that cannot be overriden,
> such as requiring mutual authentication, strong keys, etc.  Also, the peer
> may choose to restrict the hints to which it will respond -- a given
> identity might be locked down to a particular SSID and not given out to
> another one, regardless of the hint.

Here's suggested new formulation for Section 4:

4.  Security considerations

   Identity hint information is delivered inside an EAP Identity Request
   before the user authenticates to the network, and before the network
   is authenticated to the user.  This information can be modified by an
   attacker.  Therefore, it MUST be considered an unauthenticated hint.

   Unauthenticated hints may result in peers inadvertantly revealing
   their identities, leading to a privacy vulnerability. More seriously,
   if a weak EAP method is associated with one of the peer's identities, this
   may lead to a bidding down attack or a successful attack against
   that identity. To guard against these vulnerabilities, peers may have
   local policies that can not be overriden. Such policies may indicate,
   for instance, that a particular identity is only used together with
   a specific link-layer network or device identity and not used on others,
   despite any hints that the peer may have received. Note that while
   such policies make attacks harder, popular link layers may not
   support authentication of such link layer information, at least
   not until EAP authentication has completed. As a result, these
   vulnerabilities may remain.

   In case the identity hint information is used to select a mediating
   network for NAI decoration, it should be noted that at least with
   some EAP methods, there is no way for the home network AAA server to
   verify that the mediating network used was actually the same one that
   the peer had requested.

--Jari