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

[Adrangi, Farid (farid.adrangi]

Hi Bernard,
Thanks for your reply. Please see my comments inline.
BR,
Farid

> 
> > First, the intent here is *NOT* to have EAP server to provide this
> > hint
> > - the hint comes from the AP or the access network AAA server.
> 
> The EAP Server is defined as the endpoint initiating EAP.
> How can the EAP server not be involved in the conversation?
> 

EAP server will be involved eventually.  But, the AAA routing happens
before the EAP server comes into the picture.  For example, who sends
the initial EAP-Identity Request when the WLAN client associates to the
AP?  Answer: the AP for the access network AAA proxy.  If so, then, the
WLAN client responds with the EAP-Identity Response which may contain a
decorated NAI.  The AAA proxy uses the decorated NAI to determine how to
route the AAA packet which also encapsulates EAP.  So, the AAA routing
happens before the EAP server becomes involved.  Please let me know if I
am missing your point here?


> > Valid problem.  But, I think this is not related to
> mediating network
> > discovery rather it is a credential selection problem.  If
> so, I would
> > prefer to discuss this in a separated draft if you are okay
> with that?
> 
> My original understanding was that the hints were given in
> the form of an NAI Realm as defined in RFC 2486bis, providing 
> information on the NAI Realm required in the EAP-Response/Identity.
> 
Correct.

> For example, say an EAP peer receives an EAP-Request with
> NAIRealm=foo.com.
> 
> The peer has potential identities for boo [at] example.com, and
> boo [at] foo.com.  Based on the hint, my understanding was that 
> the peer would select boo [at] foo.com.  Is this correct?
> 

Here are the assumption for the problem that we are solving:

- The user has one identity (boo [at] example.com).
- The access network does not have a direct relationship with
example.com - i.e., it cannot forward the AAA packet to example.com
directly.
- the access network has roaming relationship with the foo.com (the
intermediary)
- example.com has roaming relationship with foo.com (the intermediary)
- Using the proposed solution and 2486bis, the user forms a decorated
NAI : example!boo [at] foo.com. to influence the routing of AAA packet
through foo.com to example.com.

I would like to treat the scenario that you described (i.e., multiple
identities; identity/credential selection) as a separate problem -- it
is also treated as such in the problem statement draft.


> Of course there are other cases too, such as where "foo.com" 
> is advertised in the NAIRealm and the peer has 
> "boo [at] example.com" and therefore might send a decorated NAI 
> (boo!example.com [at] foo.com).  But it seems like the basic case 
> should also work.
> 
> Is it still true that the "NAIRealm" grammar references RFC 
> 2486bis? It sounds like there is a "short form" grammar also 
> under discussion.
> 

The draft clearly refers to RFC 2486bis for the NAI grammer and the NAI
decoration syntax - please let's not confuse the grammer "NAIRealm"
attribute (defined in the EAP-discovery draft) and the NAI grammer
(which include NAI realm) defined in 2486bis.  If someone wants to
change the NAI grammar or use a different syntax for NAI decoration,
then he/she should convince the authors of RFC 2486bis for that change!
The grammer for "NAIRealm" attribute is defined to express the MN
information -- example:

NAIRealm=anyisp1.com;anyisp2.org;mnc.mcc  -- Where the syntax for
anyisp.com and mnc.mcc is compliant with the syntax of NAI realm defined
in the 2486bis (page 5).

> > Are you referring to other implementation that already use the 
> > EAP-Identity type-data field (the space after the null) in 
> proprietary 
> > manner?  Please clarify.
> 
> Yes.  Those implementations will continue to exist, so they 
> can't be outlawed.
> 

Agree.  First, this should not be a problem if MN information is
conveyed on a subsequent EAP-Identity Request -- and that's the delivery
option the draft recommends.  In other cases, "NAIRealm" attribute
should coexist with other proprietary stuff placed after the NULL
character in the EAP-Identity Request.  There are two possibilities:

1) "NAIRealm" attribute is always placed last after the proprietary
stuff.  So, the client searches for the keyword "NAIReal" and consumes
the information after that as the MN information. Note that the
assumption here is that the proprietary information does not contain the
"NAIRealm" followed by "=" keyword.
2) "NAIRealm" can be placed anywhere after the NULL character.  Extend
the grammar to indicate the end of NAIRealm attribute.

I like the first option -- what is your advice?   I will update the
draft based on that.

> > Yes.  We will add a text that the proposed solution is 
> fully compliant
> > with RFC 3748.   Unless you see some inconsistency here?
> 
> What's needed is some advice on how to avoid problems.  For 
> example, EAP servers should give up after N (n=3?) attempts, etc.
> 

Ok.  I need to double check RFC 3748 -- my understanding was that we use
whatever is recommended in RFC 3748 for these problems -- for example :
retries.

> > Error handling is done according to RFC 3748.
> 
> There is no general error handling facility in EAP.  Are you 
> referring to a Notification-Request?
> 
Yes.
> > example, just mnc.mcc.  This means that the space can utilized much 
> > more efficiently.
> 
> This implies a change to the grammar, no?  Wouldn't this make 
> the NAIRealms incompatible with the NAI Realm grammar in RFC 2486bis?

It should not.  My understanding is that mnc.mcc is a valid realm
according to 2486bis - no?  

> 
> I think if you are going to use a different grammar, then you 
> probably also need to indicate this somehow, perhaps with a 
> different keyword. Note that this also changes the scope of 
> the draft since now it is no longer a general facility for 
> realm hints, but one which is 3GPP specific.
> 
> 
> 

We will *NOT* use a different grammar other than NAI realm defined in
2486bis.  Being compliant to RFC 3748 and RFC 2486 are the key
requirements for us.