Subject: [eap] Review of draft-adrangi-eap-network-discovery-00.txt

From: Bernard Aboba <[email-masked]>
Date: Sun, 6 Jun 2004 09:54:25 -0700 (PDT)

This document is comprised of several major sections:

1. Introduction (problem statement)
2. Specification of the ABNF
3. Delivery options
4. Security Considerations

Overall, it seems to me that the material in Section 1 could be
slimmed down or eliminated entirely via reference to the EAP Network
Selection problem statement document.  For example, one of the figures in
Section appears to be duplicated as Figure 3 in the problem statement
draft, as is some of the discussion.

The terminology section should define the terms "MN" and "HSN".

There are a number of issues with Section 2:

a. The CHAR, DIGIT and ALPHA terminals are not defined or referenced.
b. Is "=" a legal character within value?
c. Rather than referencing RFC 2486bis, a separate definition of "Realm"
   is used that differs from that in RFC 2486bis.  Since there is already
   a normative reference to RFC 2486bis, referencing the definition of
   "Realm" in that document shouldn't be a big deal.

Section 3 includes discussion of AAA behavior, including normative
language that appears to update RFC 3579 and RFC 2607.  It also
contains suggestions for operator deployment.  Both of these
considerations don't seem necessary to me in a document of this type,
which should focus on defining the EAP extension.  Instead, I'd suggest
that Section 3 be limited to discussion of EAP issues.

Section 4 notes that the network information is a hint.  This implies that
existing implementations will ignore the hint, presumably without
affecting interoperability.  It also implies that the peer needs to be
robust against misleading information, but this section does not
describe the potential attacks or how a peer can guard against them.
I'm not sure that the analogy to the SSID is a good one, unless it's
being suggested that Channel Bindings be used to verify the network
information after the fact.

Section 6, references

Assuming that discussion of AAA is eliminated in this document, then
normative references ot RADIUS or Diameter should not be needed.  The only
normative references would then be to RFC 2234 (by the way, have you
checked the ABNF??), RFC 3748 and RFC 2486bis.
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: "Adrangi, Farid" <[email-masked]>
Date: Mon, 7 Jun 2004 14:49:04 -0700

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.  
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap