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

[Bernard Aboba (aboba]

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

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

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?

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.

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

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

> Error handling is done according to RFC 3748.

There is no general error handling facility in EAP.  Are you referring to
a Notification-Request?

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

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.