Subject: [eap] Proposed resolution to Issue 129: More NITs

From: [email-masked] (Bernard Aboba)
Date: Mon, 12 May 2003 11:13:09 -0700 (PDT)

The text of Issue 129 is enclosed below. The proposed resolution is as
follows:

Change the text in Section 5.5 from:

"Displayable Message
This is interpreted to be a human readable string of
characters, and MUST NOT affect operation of the protocol.
The message encoding MUST follow the UTF-8 transformation
format [RFC2279]."

To:

Displayable Message
This is interpreted to be a human readable string of
characters. The message encoding MUST follow the
UTF-8 transformation format [RFC2279].

Change the text in Section 3.4 from:

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

To:

"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 cannot conclude
that authentication has succeeded based on those indications."

Change the text in Section 7.14 from:

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

To:

"[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
send or expect to receive Notification-Requests but instead support their
own method-specific error messages."

Change:

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

To:

"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). This includes performing validity checks on the Code, Identifer
and Length fields, as described in Section 4.1.

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. The use of
the RADIUS protocol for encapsulation of EAP in pass-through
operation is described in [RFC2869bis]."

------------------------------------------------------------
Issue 129: More NITs
Submitter name: Jari Arkko
Submitter email address: [email-masked]
Date first submitted: May 12, 2003
Reference:
Document: EAP-03.f
Comment type: T
Priority: S
Section: Various
Rationale/Explanation of issue:
>From the terms section:

> Displayable Message
> This is interpreted to be a human readable string of
> characters, and MUST NOT affect operation of the protocol.
> The message encoding MUST follow the UTF-8 transformation
> format [RFC2279].

First, I'm not too happy to have keyword behaviour in the terms
section. Secondly, in Section 5.5 this term is used
for the OTP challenge, which I believe contains machine
readable sequence numbers and seeds. That would seem
to affect the behaviour of the protocol! Suggested rewrite:
move the MUST-NOT-affect-operation requirement to the
relevant sections where the term is referred to. Keep the
UTF-8 requirement here. Consider replacing 5.5 "displayable
message" with simply a reference to the OTP RFC format.

> 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."
[BA] This section is trying to indicate that Requests are retransmitted
until a maximum retry counter expires. The goal is not to give up just
because a single retransmission attempt timed out.

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

---

From: [email-masked] (Jari Arkko)
Date: Mon, 12 May 2003 22:20:53 +0300

> UTF-8 transformation format [RFC2279].

Ok (but that was in Section 1.2)

And we need a change to Section 5.5, because that still refers
to Displayable Message. In there, change "The Request contains
a displayable message containing an OTP challenge." to "The
Request contains an OTP challenge in the format described
in [RFC2289].".

> that authentication has succeeded based on those indications."

Hmm... I still have trouble parsing it. Could be my problem, but
did you mean "MUST NOT affect EAP message processing; an EAP
implementation cannot conclude..."?

> own method-specific error messages."

Ok.

> operation is described in [RFC2869bis]."

Very good, just what I was looking for. Thanks!

--Jari