Subject: RE: [eap] comments on draft-adrangi-eap-network-discovery-02.txt

From: "Adrangi, Farid" <[email-masked]>
Date: Mon, 9 Aug 2004 22:56:27 -0700

Hi Bernrad,
Thanks.  please see my responses inline.
BR,
Farid

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Bernard Aboba
> Sent: Monday, August 09, 2004 4:47 PM
> To: [email-masked]
> Subject: [eap] comments on draft-adrangi-eap-network-discovery-02.txt
> 
> 
> This version is much improved over -01.  With a little bit of 
> cleanup I
> think it will be ready for a "pseudo WG last call" (and 
> review by 802.11).
> 
> My only substantive comment about this version concerns 
> Section 3.  IMHO,
> this section should be provided as an Appendix to the 
> document, with the
> exception of any normative requirements on the client.  My 
> advice would be
> to put those requirements into Section 1.
> 

Section 3 is an important part of the solution, so I would rather not to
do it as an appendix.  However, we can follow your advice if you
strongly feel that's the best way to structure the draft.

> I think that Section 1 could use a bit more guidance for
> implementations.  Take this statement from Section 3:
> 
> "   Client implementation[s] MUST support all three options."
> 
> Since the client doesn't have any way to know which option has been
> deployed on the AP/AAA server, this normative statement is 
> not meaningful.
> What I think you mean to say is that the client may receive a 
> hint in an
> initial EAP-Identity/Request, or the hint could be received in a
> subsequent EAP-Identity/Request after an initial 
> EAP-Identity/Response is
> sent.
> 

I agree.  And, I also think the point here is that the client should not
need to know which delivery option is implemented by the access network.
So, how about the following text?

"
The client implementation MUST be able to receive identity hint
information in an initial EAP-Identity/Request, or in a subsequent
EAP-Identity/Request after an initial EAP-Identity/Response is sent.
This will enable the client to work with the three delivery options
transparently.
"

> Also, we had talked about some advice for implementations, such as:
> 
> a. Implementations SHOULD have a default value for the maximum number
>    of EAP-Identity round-trips, in case the hint is not taken by the
>    peer or is not acceptable to the EAP server.  It is suggested that
>    no more than three retries by used by default.
> 

Doesn't the following paragraph (included in the draft) address this
problem?

"
   When the initial RADIUS Access-Request is received, if the access
   network RADIUS proxy cannot route the RADIUS packet to the next AAA
   hop, it SHOULD send identity hint information to the client (via
   Access-Challenge encapsulating an EAP Identity Request).  When a
   subsequent RADIUS Access-Request is received, if the access network
   RADIUS proxy still cannot route the RADIUS packet to the next AAA
   hop, then it SHOULD discard the packet.  Optionally, the access
   network RADIUS server can also send an error notification (via
   Access-Challenge encapsulating an EAP Notification) with an
   appropriate error message.
"

> b. It is suggested that an EAP-Notification by sent by the EAP
>    server after the maximum retry limit is reached, to inform the
>    peer why it is being disconnected, prior to sending an EAP-Failure.
> 
> 

The above paragraph (the last sentence) also mentions about the optional
EAP-Notification that can be sent.  However, I am not sure if we need to
send an EAP-Failure afterward since no EAP method has started at this
point.  Please advise -- will also check RFC 3748 again on this.

> Some NITs:
> 
> Section 5
> 
> "There, is MUST be considered just" -> "Therefore, it MUST be 
> considered"

Ok.
> _______________________________________________
> 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: Tue, 10 Aug 2004 07:20:25 -0700 (PDT)

> This will enable the client to work with the three delivery options

I think you should say "An EAP peer implementing this specification MUST
be able to receive..."  After all, this specification is optional.

> Doesn't the following paragraph address the problem?
>
> "

I don't think it does.  This draft should not have any normative
statements concerning RADIUS or DIAMETER.  After all, it's supposed to
be about EAP, not AAA.  I'd suggest rewriting it as follows:

"   The authenticator MAY send an identity hint to the peer in the
    initial EAP-Request/Identity.  If the identity hint is not
    sent initially (such as when the authenticator does not
    support this specification), then if the EAP server receives
    an EAP-Response/Identity with an unacceptable NAI Realm,
    EAP servers implementing  this specification SHOULD reply
    with an EAP-Request/Identity containing an identity hint.

    If after the EAP server sends an EAP-Request/Identity
    containing an identity hint, the peer responds with an
    EAP-Response/Identity containing an unacceptable NAI
    Realm, then the EAP server MAY respond immediately with
    an EAP-Failure packet, or it MAY first send an
    EAP-Notification providing information on the reason
    for the failure."

You can then specify in the Appendix (formerly Section 3) that the role of
EAP server may be played by the authenticator (where an initial
EAP-Request/Identity is sent with an identity hint), a RADIUS client
or proxy (where the NAI Realm is used for forwarding), or a RADIUS server.

> point.  Please advise -- will also check RFC 3748 again on this.

The problem with not sending an EAP Failure is that the peer will hang, so
I think that it is more polite.  See the above text for a suggestion.

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 10 Aug 2004 10:22:09 -0700 (PDT)

Another comment.

In Section 3, the term "Wireless client" is used.  I'd suggest that the
term "EAP peer" be used instead.  Instead of AP, I'd use "EAP
Authenticator" or NAS.

I'd recommend that step 1 (Association) be removed, since the document is
applicable to all access media, and inclusion of the Association exchange
appears to preclude EAP pre-authentication.

In Section 3, the term "AN RADIUS server" is used.  From what I can tell,
this is actually a RADIUS proxy.  Also the abbreviation "AN" is not
defined in the terminology section.  Perhaps the term "local RADIUS proxy"
might be more appropriate.  The term "next RADIUS server" is used
as well.  I think what is meant here is "home RADIUS server", no?

I'd prefer if the terms EAP-Request/Identity and EAP-Response/Identity
were written out, rather than being abbreviated.

In Section 3.1, 3.2 and 3.3, in the figures, the EAP conversation is shown
to occur only between the AP and the AN RADIUS server.  I'd suggest that this
be corrected to show the conversation going between the peer and the home
server.

In Section 3.3, a RADIUS proxy is shown responding to an
EAP-Request/Identity.  An implication might be drawn that the RADIUS
proxy is EAP-aware.  What is happening is that the RADIUS proxy does not
have a route for the NAI Realm included in the User-Name attribute.  In
this situation, rather than silently discarding the Access-Request, it
formulates an Access-Challenge with an EAP-Request/Identity containing an
identity  hint.  So the RADIUS proxy doesn't actually have to interpret
the contents of the EAP-Message attribute.

Also, I think there is an implication here that a State attribute is being
sent;  otherwise, how would the RADIUS proxy know if an identity hint had
previously been sent by it to the peer?  Note that this implies that the
RADIUS proxy would not know if the authenticator had sent an identity hint
originally, so that it would still need to retry (3 EAP Responses would be
received in all).

Overall, my recommendation is that the requirements on EAP peers and
servers deriving from Section 3.3 go into Section 1, phrased purely in EAP
terms (as suggested earlier).  In the Appendix, you can go into the AAA
implications -- however, please avoid the use of normative language since
this specification isn't about RADIUS or Diameter (if it were, it would
require review from the RADEXT or AAA WGs).
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap