eap Mailing List: RE: comments on draft-adrangi-eap-network-discovery-02.txt

[Bernard Aboba (aboba]

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

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

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.

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

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.