Subject: [eap] RE: Issue 256: Miscellaneous NITs

From: "Adrangi, Farid" <[email-masked]>
Date: Tue, 19 Oct 2004 05:45:59 -0700

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:[email-masked]] 
> Sent: Tuesday, October 19, 2004 2:49 AM
> To: Bari, Farooq
> Cc: [email-masked]; 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
> 
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Jari Arkko <[email-masked]>
Date: Tue, 19 Oct 2004 15:59:19 +0300

Adrangi, Farid wrote:

> I have
> really caused by the proposed solution). 

Attacks against weak EAP methods exist in any case, as do
the privacy problems of revealing your identity in a cleartext
message. However, it seems that "hints" or "advertisements"
-- be it at link or EAP layer -- make it possible for attackers
to fool the node into thinking that its somewhere else than
it really is, hence revealing more information than it would
perhaps otherwise reveal.

I don't think this is a big deal -- but it would be something
IETF RFCs would typically list in the security considerations
section.

But I'll let Bernard speak to the necessity of this change,
it was his issue after all. I was just following up on the
issue resolutions and checking if everything in the three
issues was indeed covered.

--Jari