RE: Review of draft-adrangi-eap-network-discovery-00.txt
From: Bernard Aboba (abobainternaut.com)
Date: Mon, 7 Jun 2004 09:53:25 -0400 (EDT)
> > a. The CHAR, DIGIT and ALPHA terminals are not defined or referenced.
>
> DIGIT, ALPHA, CHAR are defined in RFC 2234.

A reference to RFC 2234 would be good.

> I guess you are right!  We could do that :-)

I think it would ensure that there is no divergence.

BTW, I think the draft needs a very short IANA Considerations section that
says "There are no considerations for IANA."

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

> 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 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?


Results generated by Tiger Technologies using MHonArc.