Subject: [eap] Issue 223: PRI Cleanup

From: Bernard Aboba <[email-masked]>
Date: Sun, 15 Feb 2004 09:51:24 -0800 (PST)

Issue 223: PRI cleanup
Submitter: Bernard Aboba
Submitter email address: [email-masked]
Date first submitted: February 15, 2003
Reference:
Document: RFC2284bis-08
Comment type: E
Priority: S
Section: 2.4, 4.2, 5.1, 5.2, 5.3.1, 5.3.2, 5.4, 5.5, 5.6, 7.2
Rationale/Explanation of issue:

Now that PRIs are not a security claim any more, we need to remove them
from the list of security claims for each of the methods defined in RFC
2284bis. Also, the language in Sections 2.4, 4.2 and 7.2 is not consistent
with the definition of result indications in Section 1.2 or 7.16.

In Section 2.4, change "protected result indications" to "result
indications".

In Section 4.2, change the implementation note to the following:

Implementation Note: Because the Success and Failure packets are
not acknowledged, they are not retransmitted by the authenticator,
and may be potentially lost. A peer MUST allow for this
circumstance as described in this note. See also Section 3.4 for
guidance on the processing of lower layer success and failure
indications.

As described in Section 2.1, only a single EAP authentication
method is allowed within an EAP conversation. EAP methods may
implement result indications. After the authenticator sends
a failure result indication to the peer, regardless of the
response from the peer, it MUST subsequently send a Failure
packet. After the authenticator sends a success result
indication to the peer, and receives a success result indication
from the peer, it MUST subsequently send a Success packet.

On the peer, once the method completes unsuccessfully (that is,
either the authenticator sends a failure result indication,
or the peer decides that it does not want to continue
the conversation, possibly after sending a failure result
indication), the peer MUST terminate the conversation and indicate
failure to the lower layer. The peer MUST silently discard
Success packets and MAY silently discard Failure packets. As a
result, loss of a Failure packet need not result in a timeout.

On the peer, after success result indications have been
exchanged by both sides, a Failure packet MUST be silently
discarded. The peer MAY, in the event that an EAP Success is not
received, conclude that the EAP Success packet was lost and that
authentication concluded successfully.

If the authenticator has not sent a result indication, and
the peer is willing to continue the conversation, once the
method completes the peer waits for a Success or Failure
packet and MUST NOT silently discard either of them. In the event
that neither a Success nor Failure packet is received, the peer
SHOULD terminate the conversation to avoid lengthy timeouts in
case the lost packet was an EAP Failure.

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. However, an
authenticator MAY omit having the peer authenticate to it in
situations where limited access is offered (e.g., guest access).
In this case the authenticator MUST send a Success packet.

Where the peer authenticates successfully to the authenticator,
but the authenticator does not send a result indication,
the authenticator MAY deny access by sending a Failure
packet where the peer is not currently authorized for network
access."

In Sections 5.1, 5.2, 5.3.1, 5.3.2, 5.4, 5.5, 5.6, delete:

" Protected result ind.: No"

In Section 7.2, change:

" [b] Security claims. This is a statement of the claimed security
properties of the method, using terms defined in Section 7.2.1:
mutual authentication, integrity protection, replay protection,
confidentiality, key derivation, dictionary attack resistance,
fast reconnect, cryptographic binding, protected result
indications. The Security Claims section of an EAP method
specification SHOULD provide justification for the claims that
are made. This can be accomplished by including a proof in an
Appendix, or including a reference to a proof."

To:

" [b] Security claims. This is a statement of the claimed security
properties of the method, using terms defined in Section 7.2.1:
mutual authentication, integrity protection, replay protection,
confidentiality, key derivation, dictionary attack resistance,
fast reconnect, cryptographic binding. The Security Claims section
of an EAP method specification SHOULD provide justification for
the claims that are made. This can be accomplished by including
a proof in an Appendix, or including a reference to a proof."
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Jari Arkko <[email-masked]>
Date: Sun, 15 Feb 2004 19:44:18 +0200

Agreed. Lets see if we still have time for -09...