Found 1 record.

Status: Verified (1)

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

Note: This RFC has been updated by RFC 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