eap Mailing List: Re: Issue 256: Miscellaneous NITs

[Jari Arkko (jari.arkko]

I think you are thinking something completely different
than I (and presumably Bernard) were thinking. It does
not matter what option is used, because the client does
not know if the advertisement comes from a legitimate
network with option X or from an attacker. In any case,
if the attacker makes it look like option 2 or 3, it
can still fool the peer into thinking that it needs to
reveal another identity than it originally did. Remember,
they may be multiple identities on a single peer. And
again, this is not a practical problem, in my opinion
(particularly when it already exists also at other layers),
but probably deserves to be documented.

But we are running out of time before the deadline. Lets
try to close this issue. Here's a new suggested replacement
of paragraph 1.

Here's suggested new formulation of the first paragraph of
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.

   Unauthenticated hints may result in peers inadvertantly
   revealing other or additional identities than they intended
   to, leading to a privacy vulnerability. Note that in EAP,
   the identity the peer wants to use is in general carried in
   a cleartext message, so this is only a variation of an
   existing vulnerability. Method-specific identity protection
   is one of the ways that this vulnerability can be addressed.

   Similarly, in a situation where the peer has multiple identities
   to choose from, an unauthenticated hint can lead to a situation
   where an attacker convinces the peer to choose an identifier
   that is bound to the weakest EAP method. To guard against
   this vulnerability, the use of as strong EAP methods as possible
   is recommended. Note that this vulnerability is similar to an
   existing vulnerability where link layers advertise network
   names (such as 802.11 SSIDs) without authenticating these
   advertisements either at all or only at the end of the
   authentication process.

--Jari

Adrangi, Farid wrote:
> Thanks Jari.  So, to have a text more relavent to the draft, how about
> the following text (which goes between the existing two paragraph in the
> draft)?
>
> "
> For delivery options 2 and 3, unauthenticated hints are advertised after
> the user's identity is revealed to the network.  In the delivery option
> 1 however, unauthenticated hints may result in peers inadvertently
> revealing their identities, leading to a privacy vulnerability.  
>
> If weak EAP methods are used, this could potentially lead to attacks for
> stealing user's credential. It should also be noted that such attacks
> against weak EAP methods exist in any case, as do the privacy problems
> of revealing the identity in a clear text message.