eap Mailing List: RE: Issue 256: Miscellaneous NITs

[Adrangi, Farid (farid.adrangi]

Thanks Jari.  

I understand the described attack problem below, but I don't think this
is particularly caused by the proposed solution in this draft.  In
option 2 and 3 (described in the draft), the user's identity is exposed
before the mediating network information gets advertised. 

This issue was also raised a few revisions ago, and we responded to the
issue with the same question.  But, we did not get an answer!  I have
nothing against your proposed text but I just wanted to understand the
rationale for adding more information about the attack (which is not
really caused by the proposed solution).  Thanks a bunch.

BR,
Farid



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