Search RFCs

RFC Editor

Found 1 record.

Status:Verified (1)

RFC 3748, "Extensible Authentication Protocol (EAP)", June 2004

Note: This RFC has been updated byRFC 5247, RFC 7057

Errata ID:5139
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Ivo Sedlacek
Date Reported: 2017-10-04
Verifier Name: Éric Vyncke
Date Verified: 2024-01-12

Section 3.4 says:

3.4.  Lower Layer Indications   The reliability and security of lower layer indications is dependent   on the lower layer.  Since EAP is media independent, the presence or   absence of lower layer security is not taken into account in the   processing of EAP messages.   To improve reliability, if a peer receives a lower layer success   indication as defined in Section 7.2, it MAY conclude that a Success   packet has been lost, and behave as if it had actually received a   Success packet.  This includes choosing to ignore the Success in some   circumstances as described in Section 4.2.   A discussion of some reliability and security issues with lower layer   indications in PPP, IEEE 802 wired networks, and IEEE 802.11 wireless   LANs can be found in the Security Considerations, Section 7.12.   After EAP authentication is complete, the peer will typically   transmit and receive data via the authenticator.  It is desirable to   provide assurance that the entities transmitting data are the same   ones that successfully completed EAP authentication.  To accomplish   this, it is necessary for the lower layer to provide per-packet   integrity, authentication and replay protection, and to bind these   per-packet services to the keys derived during EAP authentication.   Otherwise, it is possible for subsequent data traffic to be modified,   spoofed, or replayed.   Where keying material for the lower layer ciphersuite is itself   provided by EAP, ciphersuite negotiation and key activation are   controlled by the lower layer.  In PPP, ciphersuites are negotiated   within ECP so that it is not possible to use keys derived from EAP   authentication until the completion of ECP.  Therefore, an initial   EAP exchange cannot be protected by a PPP ciphersuite, although EAP   re-authentication can be protected.   In IEEE 802 media, initial key activation also typically occurs after   completion of EAP authentication.  Therefore an initial EAP exchange   typically cannot be protected by the lower layer ciphersuite,   although an EAP re-authentication or pre-authentication exchange can   be protected.

It should say:

3.4.  Lower Layer Indications   The reliability and security of lower layer indications is dependent   on the lower layer.  Since EAP is media independent, the presence or   absence of lower layer security is not taken into account in the   processing of EAP messages.   To improve reliability, if a peer receives a lower layer success   indication as defined in Section 7.12, it MAY conclude that a Success   packet has been lost, and behave as if it had actually received a   Success packet.  This includes choosing to ignore the Success in some   circumstances as described in Section 4.2.   A discussion of some reliability and security issues with lower layer   indications in PPP, IEEE 802 wired networks, and IEEE 802.11 wireless   LANs can be found in the Security Considerations, Section 7.12.   After EAP authentication is complete, the peer will typically   transmit and receive data via the authenticator.  It is desirable to   provide assurance that the entities transmitting data are the same   ones that successfully completed EAP authentication.  To accomplish   this, it is necessary for the lower layer to provide per-packet   integrity, authentication and replay protection, and to bind these   per-packet services to the keys derived during EAP authentication.   Otherwise, it is possible for subsequent data traffic to be modified,   spoofed, or replayed.   Where keying material for the lower layer ciphersuite is itself   provided by EAP, ciphersuite negotiation and key activation are   controlled by the lower layer.  In PPP, ciphersuites are negotiated   within ECP so that it is not possible to use keys derived from EAP   authentication until the completion of ECP.  Therefore, an initial   EAP exchange cannot be protected by a PPP ciphersuite, although EAP   re-authentication can be protected.   In IEEE 802 media, initial key activation also typically occurs after   completion of EAP authentication.  Therefore an initial EAP exchange   typically cannot be protected by the lower layer ciphersuite,   although an EAP re-authentication or pre-authentication exchange can   be protected.

Notes:

2nd paragraph of section 3.4 of RFC3748 states:
---------------------
To improve reliability, >>if a peer receives a lower layer success
indication as defined in Section 7.2<<, it MAY conclude that a Success
packet has been lost, and behave as if it had actually received a
Success packet. This includes choosing to ignore the Success in some
circumstances as described in Section 4.2.
---------------------

RFC3748 section 7.2 does not seem to state anything about lower layer indications.

RFC3748 section 7.12 contains some text on the lower layer indications and also RFC3748 section 7.16 contains some text on lower layer indications.

So, it is proposed to change 2nd paragraph of section 3.4 of RFC3748 to reference section 7.12 (or section 7.16) instead of referencing section 7.2.

-- Verifier note --

Indeed, the 2nd paragraph of section 3.4 should have a reference to section 7.12. draft-ietf-eap-rfc2284bis-00 has text relevant to section 3.4 that was moved to section 7.12 in later revisions.

Report New Errata