Subject: [eap] Proposed resolution to Issue 151: EAP-04 comments

From: [email-masked] (Bernard Aboba)
Date: Sat, 2 Aug 2003 19:42:08 -0700 (PDT)

The text of Issue 151 is enclosed below.  Overall, these changes look good
and the proposed resolution is to accept them, with the exception of the
change relating to "granting access."  Since only some methods do key
derivation, the existing paragraph seems to cover more cases and the
proposed text does not really substitute for it.

Here are the proposed fixes:

In Section 2, change:

"ince EAP is a peer-to-peer protocol, an
independent and simultaneous authentication may take place in
the reverse direction."

To:

"Since EAP is a peer-to-peer protocol, an independent and
simultaneous authentication may take place in the reverse
direction (depending on the capabilities of the lower layer)."

In Section 4.2, change:

"Success or Failure packets MUST NOT be sent by
an EAP authenticator prior to completion of the final round
of a given method. A peer EAP implementation receiving a
Success or Failure packet prior to completion of the method
in progress MUST silently discard it."

To:

"Success and Failure packets MUST NOT be sent by an EAP
authenticator if the specification of the given method does not
explicitly permit the method to finish at that point. A peer EAP
implementation receiving a Success or Failure packet where
sending one is not explicitly permitted MUST silently discard it."

In Section 5.7, change:

"EAP Types from 0 through 255 are semantically
identical whether they appear as single octet EAP Types or as
Vendor-Types when Vendor-Id is zero."

To:

"EAP Types from 0 through 255 are semantically
identical whether they appear as single octet EAP Types or as
Vendor-Types when Vendor-Id is zero. There is one exception to
this rule: Expanded Nak and Legacy Nak packets share the same
code, but must be treated differently because they have a
different format."

In Appendix B, add "Support for mutual authentication and key derivation."

In the reference section, update the references to RFC 2869bis (should
obtain an RFC number soon) and SASLPREP.

Also, change references to PIC to a reference to IKEv2.

----------------------------------------------------------------------------
Issue 151: EAP-04 comments
Submitter name: Pasi Eronen
Submitter email address: [email-masked]
Date first submitted: July 6, 2003
Reference:
http://mail.frascone.com/pipermail/public/eap/2003-July/001412.html
Document: EAP-04
Comment type: T
Priority: 1
Section: Various
Rationale/Explanation of issue:

Overall, the draft looks fine, and it seems that we're finally
close to getting it finished! In hindsight, there are a couple
of things that might have been clearer if organized differently,
but it probably doesn't make sense to do such changes at this
point.
---

(Section 2) "Since EAP is a peer-to-peer protocol, an
independent and simultaneous authentication may take place in
the reverse direction. Both peers may act as authenticators
and authenticatees at the same time. For a discussion of
security issues in peer-to-peer operation, see Section 7.7.

I think this does not apply to all lower layers. Perhaps it
should be rephrased to something like "Some lower layers for
carrying EAP, such as PPP, may support peer-to-peer operation,
in which an independent and...".

[Jari Arkko]
Yes. [Alternative re-formulation: "Since EAP is a peer-to-peer
protocol, an independent and simultaneous authentication may take
place in the reverse direction (depending on the capabilities
of the lower layer)."]
---

(Section 4.2) "Success or Failure packets MUST NOT be sent by
an EAP authenticator prior to completion of the final round
of a given method. A peer EAP implementation receiving a
Success or Failure packet prior to completion of the method
in progress MUST silently discard it."

I think there are several EAP methods where the number of rounds
varies (so the phrase "the final round" is not well defined),
depending on many issues, including whether the method is
going to succeed or not.

Perhaps this would better take that into account?

"Success and Failure packets MUST NOT be sent by an EAP
authenticator if the specification of the given method does not
allow the method to finish at that point. A peer EAP
implementation receiving a Success or Failure packet where
sending one is not allowed MUST silently discard it."

[Jari Arkko] Sounds good!
---

(Section 4.2) "If the peer attempts to authenticate to the
authenticator and fails to do so, the authenticator MUST send a
Failure packet and MUST NOT grant access by sending a Success
packet."

I know that this was beaten to death already :-) But since
we have not defined what "failing to authenticate to the
authenticator" means, does this actually impose any
requirements for EAP implementations?

(The problem is that "failing to authenticate" could be thought
as "not successfully authenticating"; but according to the
definition of "successful authentication" in Section 1.2, the
above requirement does not make much sense.)

Perhaps this would capture the intent?

"If the peer attempts to authenticate to the authenticator using
a method that provides key derivation, the authenticator SHOULD
NOT grant access by sending a Success packet if the key
derivation has failed for some reason."

[Jari Arkko] Works for me. Maybe delete "for some reason".
---

(Section 5.7) "EAP Types from 0 through 255 are semantically
identical whether they appear as single octet EAP Types or as
Vendor-Types when Vendor-Id is zero."

(Section 5.7) "An implementation that supports the Expanded
attribute MUST treat EAP Types that are less than 256
equivalently whether they appear as a single octet or as the
32-bit Vendor-Type within a Expanded Type where Vendor-Id is
0." and

Otherwise fine, but Expanded Nak packets have a different format
than Legacy Nak packets, so they are not treated exactly
identically.

Perhaps we should add something like "There is one exception to
this rule: Expanded Nak and Legacy Nak packets share the same
code, but must be treated differently because they have a
different format." (an alternative would be to change the
code of Expanded Naks to something else, but probably
this is easier?)

[Jari Arkko] Yes.
---
Appendix B: Two significant changes to RFC 2284 are not
mentioned: mutual authentication and key derivation
(RFC 2284 did not even mention either of them).

[Jari Arkko] Ok.
----
References: There are newer versions of RFC2869bis and SASLPREP
drafts available (Ok, RFC editor will probably handle these...)

[Jari Arkko] Better update them now, just for consistency.
----
References: PIC is most likely dead and superceded by IKEv2, so
maybe we should remove references to PIC and add a pointer to
IKEv2?

[Jari Arkko]  Yes, that can be done. (Both the IKEv2 and PANA references
would be non-normative, by the way, so that we don't have
to wait for either one to complete.)

---

From: [email-masked] (John Vollbrecht)
Date: Mon, 04 Aug 2003 12:08:48 -0400

These seem good to me -- John

--On Saturday, August 2, 2003 7:42 PM -0700 Bernard Aboba 
<[email-masked]> wrote:

> -------------------------------------------------------------------------
> --- Issue 151: EAP-04 comments
> _______________________________________________
> eap mailing list
> [email-masked]
> http://mail.frascone.com/mailman/listinfo/eap