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

From: "Adrangi, Farid" <[email-masked]>
Date: Sun, 6 Jun 2004 20:23:06 -0700

Hi Bernard,
Thanks so much for your review and comments.  Please see my responses
below.
BR,
Farid

> 
> 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 problem statement draft provides an overview of four problems:

1) Access Netowrk Discocery
2) Idenitifier Selection
3) Selection of roaming intermediaries
4) Payload routing

Here we are focusing only on the problem #3 as we did in the original
draft (published before the problem statement draft). I don't think it
would be a good idea to eliminate the section entirely via reference to
the problem statement draft .  We have already slimmed down the section
1 with the help of Jari - and as you noticed we used Figure 3 as per
Jari's suggestion.   I can go through it again, maybe we can make it
more concise -- please this section is pretty short. 

> The terminology section should define the terms "MN" and "HSN".
> 
Yes.  Good catch.  In the latest version, the intent was not to use
these terms.  But, I think I left a few in the document -- will fix...

> There are a number of issues with Section 2:
> 
> a. The CHAR, DIGIT and ALPHA terminals are not defined or referenced.

DIGIT, ALPHA, CHAR are defined in RFC 2234.  I noticed alphanum was
undefined when I ran it through the ABNF checker - I have fixed it in
the later version along with other things -- please also see my response
to Jari's mail.  Here are the moidified ABNF definitions:

   identity-request-data = displayable-string [ %d0 network-info ]
   displayable-string = *CHAR

   network-info = attribute "=" value

   attribute =  1*( ALPHA / "-" / "_" / DIGIT)

   value = 1*( %x01-FF ) ; any non-null UTF-8 char

----

   value = Realm [ ";" Realm ]

   Realm = *( domainlabel "." ) toplabel
   domainlabel    =  (ALPHA / DIGIT) *( ALPHA / DIGIT / "-" )
   toplabel         =  ALPHA * (ALPHA / DIGIT)

> b. Is "=" a legal character within value?

Currently it is, as it does not make the definition ambiguious.  Do you
have any concerns about it?

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

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

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

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.  

> Section 4 notes that the network information is a hint.  This 
> implies that
> existing implementations will ignore the hint, presumably without
> affecting interoperability.  

That's true.

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

Does IEEE describe how a peer can guard against spoofed SSIDs? I guess
we could include some discussion on potential attacks and possibly how a
peer can guard against them if you think it is necessary even thought we
are saying the information should be used as a hint.  

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

Ok
> by the way, have you
> checked the ABNF??), RFC 3748 and RFC 2486bis.

I am not sure what the question is here.

> _______________________________________________
> eap mailing list
> [email-masked]
> http://mail.frascone.com/mailman/listinfo/eap
> 
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 7 Jun 2004 07:07:55 -0700 (PDT)

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

> 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

> peer can guard against them if you think it is necessary even though we

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?