eap Mailing List: RE: Review of draft-adrangi-eap-network-discovery-00.txt

[Adrangi, Farid (farid.adrangi]

Hi Bernard,
Please see my response inline.
BR,
Farid

> 
> BTW, I think the draft needs a very short IANA Considerations 
> section that
> says "There are no considerations for IANA."
> 
Ok.
> > I see your point.  Most of AAA behavior discussion is done 
> in describing
> > the option 3 -- therefore it is going to be hard to describe how the
> > option 3 would work without making any references to AAA.  
> I will try to
> > reword the text in option 3, and send it to you for review.
> 
> I'm not sure you even need to describe the options in much 
> detail.  You
> can just have an "Implementation Considerations" section that 
> lists the
> three options and says a few words about the pros/cons.  But making
> recommendations is probably going too far.

Ok, I will restructure/reword this -- I like the idea of having an
"Implementation Considerations" section.

> 
> > Does IEEE describe how a peer can guard against spoofed SSIDs?
> 
> IEEE 802.11i does provide this information actually -- by checking the
> parameters in the Beacon/Probe Response against those included in the
> 4-way handshake.  But I'm not clear how to protect against 
> bogus network
> information on the client.  For example, what should the client do if:
> 
> a. An initial EAP-Request/Identity did not include a hint, but after
> sending an EAP-Response/Identity, the peer receives *both* an
> EAP-Request/Identity with a hint, *and* an EAP-Request for a method?
> 
> b. An EAP-Request/Identity contains hints for unknown NAIs
> 
> > we could include some discussion on potential attacks and 
> possibly how a
> > peer can guard against them if you think it is necessary 
> even though we
> > are saying the information should be used as a hint.
> 

I think our focus here is (b) and I would reword it like "An
EAP-Request/Identity contains hints for mediating network names".  I
don't think the (a) is an option as the home network will not know about
the access network's roaming agreements with 1 or more mediating
network.  Let's talk about what bogus network information means here.  I
can think of two scenarios: 1) client associates with a bogus SSID,
starts EAP, and receives some bogus network information.  In this case,
associating with the bogus SSID is the problem - what ever happens after
that obviously is going to be questionable.  2) Associating with a
valid/legitimate SSID.  In this case, the access network may advertise
only a subset of the mediating networks (based on its own preference),
or route the AAA packets different from what specified through the
user's preference (i.e., via decorated NAI).  I don't think we can
detect the former one.  However, for the latter one, the home network
may be able to detect the problem in real time if it knows the path that
the AAA packet took, or during the settlement time.  

We may want to list some known attack scenarios in the draft and leave
out how these attacks can be detected.  What do you think?  
 

> I guess I'm unclear what "hint" means here -- under what 
> conditions should
> conforming implementations ignore the "hint" -- and how are 
> the "hints"
> used in addition to the information specified in RFC 3770?
> 
> 
Hint here means that network information is delivered through an
unprotected channel, the initial EAP-Identity Request.