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

From: "Adrangi, Farid" <[email-masked]>
Date: Wed, 20 Oct 2004 14:38:55 -0700

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.
"

BR,
Farid

> -----Original Message-----
> From: Jari Arkko [mailto:[email-masked]] 
> Sent: Tuesday, October 19, 2004 5:59 AM
> To: Adrangi, Farid
> Cc: Bari, Farooq; [email-masked]; Bernard Aboba
> Subject: Re: Issue 256: Miscellaneous NITs
> 
> 
> 
> Adrangi, Farid wrote:
> 
> > 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. 
> > 
> > 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). 
> 
> 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
> 
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Jari Arkko <[email-masked]>
Date: Fri, 22 Oct 2004 13:50:30 +0300

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