eap Mailing List: RE: Issue 256: Miscellaneous NITs

[Adrangi, Farid (farid.adrangi]

Thanks Jari.  We were thinking completely different than you.  We will
go with your suggestion.  Thanks again.
BR,
Farid

> -----Original Message-----
> From: Jari Arkko [mailto:jari.arkko [at] piuha.net] 
> Sent: Friday, October 22, 2004 3:51 AM
> To: Adrangi, Farid
> Cc: Bari, Farooq; eap [at] frascone.com; Bernard Aboba; 
> Pasi.Eronen [at] nokia.com
> Subject: Re: Issue 256: Miscellaneous NITs
> 
> 
> 
> 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.
> 
> 
>