Subject: [eap] EAP-04 comments

From: [email-masked] ([email-masked])
Date: Sun, 6 Jul 2003 17:20:04 +0300

EAP-04 comments
Submitter name: Pasi Eronen
Submitter email address: [email-masked]
Date first submitted: July 6, 2003
Reference:=20
Document: RFC2284bis
Comment type: E/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.=20

---

   (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 indendent and...".

---

   (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=20
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."

---

   (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=20
we have not defined what "failing to authenticate to the
authenticator" means, does this actually impose any=20
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."

---

   (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."
 =20
   (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?)

---

Appendix B: Two significant changes to RFC 2284 are not
mentioned: mutual authentication and key derivation=20
(RFC 2284 did not even mention either of them).

----

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

----

References: PIC is most likely dead and superseded by IKEv2, so
maybe we should remove references to PIC and add a pointer to
IKEv2?

----

Best regards,
Pasi

---

From: [email-masked] (Jari Arkko)
Date: Sun, 06 Jul 2003 17:29:40 +0300

[email-masked] wrote:
> Reference: 
> point. 

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

> depending on many issues, including whether the method is 
> going to succeed or not.
> 

SOunds good!

> I know that this was beaten to death already :-) But since 
> authenticator" means, does this actually impose any 

Works for me. Maybe delete "for some reason".

> different format." 

Yes.

> mentioned: mutual authentication and key derivation 

Ok.

> drafts available (Ok, RFC editor will probably handle these...)

Better update them now, just for consistency.

> maybe we should remove references to PIC and add a pointer to

Yes!

Thanks for your comments, Pasi.

--Jari

---

From: [email-masked] (Alper Yegin)
Date: Sun, 06 Jul 2003 21:46:07 -0700

> maybe we should remove references to PIC and add a pointer to

... and to PANA.

Alper

---

From: [email-masked] (Jari Arkko)
Date: Mon, 07 Jul 2003 10:44:46 +0300

>>maybe we should remove references to PIC and add a pointer to

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

--Jari

---

From: [email-masked] (John Vollbrecht)
Date: Tue, 08 Jul 2003 18:01:19 -0400

--On Sunday, July 6, 2003 5:20 PM +0300 [email-masked] wrote:
comments in line

> but it probably doesn't make sense to do such changes at this
I agree it is good, and thanks to all who worked on it, especially Nick and 
Pasi.

> in which an indendent and...".
I agree the meaning of this is not clear.  I think it would be good to talk 
about the signalling between layers rather than what different layers do. 
This could be an interesting discussion.
> sending one is not allowed MUST silently discard it."
I like this
> derivation has failed for some reason."
I think key derivation is a method and RADIUS (or other) issue, not really 
EAP.   Here I think Policy can come in play, and trying to avoid all policy 
gets counter productive at some point.  Again an interesting discussion.

> code of Expanded Naks to something else, but probably
I like this
> (RFC 2284 did not even mention either of them).
probably good to mention, but again these are method issues not "EAP" 
issues.  Use of some policy makes these work.  Perhaps that is where they 
should be mentioned.

> maybe we should remove references to PIC and add a pointer to
I like this idea very much.

John

> ----
>
> Best regards,
> Pasi
> _______________________________________________
> eap mailing list
> [email-masked]
> http://mail.frascone.com/mailman/listinfo/eap
>