eap Mailing List: RE: Issue 256: Miscellaneous NITs

[Adrangi, Farid (farid.adrangi]

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:jari.arkko [at] piuha.net] 
> Sent: Tuesday, October 19, 2004 5:59 AM
> To: Adrangi, Farid
> Cc: Bari, Farooq; eap [at] frascone.com; 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
>