Subject: [eap] other issues in 2284bis-03.f

From: [email-masked] (Jari Arkko)
Date: Sun, 11 May 2003 23:43:27 +0300

A few additional questions and comments:

> 3.4 Lower layer indications
> 
>    Lower layer failure indications provided to EAP by the lower layer
>    MUST be processed and will cause an EAP exchange in progress to be
>    aborted. However, lower layer success indications MUST NOT affect EAP
>    message processing so that an EAP implementation MUST NOT conclude
>    that authentication has succeeded based on those indications. 

The last sentence has too many NOTs, I think. How about "However, lower
layer success indications MUST NOT affect EAP message processing so
that the EAP implementation would conclude ..."

> 4.1 Request and Response
> 
>    Description
> 
>       The Request packet (Code field set to 1) is sent by the
>       authenticator to the peer. Each Request has a Type field which
>       serves to indicate what is being requested. Additional Request
>       packets MUST be sent until a valid Response packet is received, or
>       an optional retry counter expires.

Retry counter? This seems to be the only place we talk about retry
counters. Perhaps a timeout is assumed instead? If so, "..., or
until a timeout expires."

> 7.14. 
> 
>    [a] On the peer, all EAP packets MUST be silently discarded, except
>        for those with Code=1 (Request) and Type=Method-Type. This
>        implies that methods supporting "strict interpretation" do not
>        utilize Notification, but instead support their own
>        method-specific error messages.

Hmm... perhaps they don't use notification at all and just want
to avoid getting them? Suggested rewrite: "... do not utilize Notification
or support their own method-specific notification messages."

 >     Where an authenticator operates as a pass-through, it forwards
 >    packets back and forth between the peer and a backend authentication
 >    server, based on the EAP layer header fields (Code, Identifier,
 >    Length). Since pass-through authenticators rely on a backend
 >    authenticator server to implement methods, the EAP method layer
 >    header fields (Type, Type-Data) are not examined as part of the
 >    forwarding decision. The forwarding model is illustrated in Figure 2.
 >    Compliant pass-through authenticator implementations MUST by default
 >    be capable of forwarding packets from any EAP method.

This specification is insufficient for me to implement a
passthrough: it doesn't do some things per above, but
what does it do then? I do realize that the proper
specification depends on the AAA protocol translation
for instance, so maybe we shouldn't expect to have a
full specification here. Perhaps reference 2869bis?
Or should we list the actions that the forwarding decision
must make?

--Jari