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

From: John Vollbrecht <[email-masked]>
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:

> 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.)
>
> _______________________________________________
> eap mailing list
> [email-masked]
> http://mail.frascone.com/mailman/listinfo/eap

_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap