eap Mailing List: Re: Issue 223: PRI Cleanup

[Jari Arkko (jari.arkko]

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

Bernard Aboba wrote:
> Issue 223: PRI cleanup
> Submitter: Bernard Aboba
> Submitter email address: aboba [at] internaut.com
> 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
> eap [at] frascone.com
> http://mail.frascone.com/mailman/listinfo/eap