RFC Errata
Found 3 records.
Status: Held for Document Update (2)
RFC 5247, "Extensible Authentication Protocol (EAP) Key Management Framework", August 2008
Note: This RFC has been updated by RFC 8940
Source of RFC: eap (int)
Errata ID: 5011
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Jouni Malinen
Date Reported: 2017-05-07
Held for Document Update by: Roman Danyliw
Date Held: 2020-07-27
Section Appendix A says:
EAP-AKA
EAP-AKA is defined in [RFC4187]. The EAP-AKA Session-Id is the
concatenation of the EAP Type Code (0x17) with the contents of the
RAND field from the AT_RAND attribute, followed by the contents of
the AUTN field in the AT_AUTN attribute:
Session-Id = 0x17 || RAND || AUTN
It should say:
EAP-AKA
EAP-AKA is defined in [RFC4187]. When using full authentication,
the EAP-AKA Session-Id is the
concatenation of the EAP Type Code (0x17) with the contents of the
RAND field from the AT_RAND attribute, followed by the contents of
the AUTN field in the AT_AUTN attribute:
Session-Id = 0x17 || RAND || AUTN
When using fast re-authentication, the EAP-AKA Session-Id is the
concatenation of the EAP Type Code (0x17) with the contents of the
NONCE_S field from the AT_NONCE_S attribute, followed by the
contents of the MAC field from the AT_MAC attribute from
EAP-Request/AKA-Reauthentication:
Session-Id = 0x17 || NONCE_S || MAC
Notes:
RFC 5247 was supposed to define exported parameters for existing EAP methods in Appendix A. The way Session-Id was defined for EAP-AKA and EAP-SIM works only for the full authentication case, i.e., it cannot be used when the optional fast re-authentication case is used since the used parameters (RAND, AUTN, NONCE_MT) are not used in the fast re-authentication case. Based on RFC 4187 chapter 5.2 (and similar chapter in RFC 4186), NONCE_S corresponds to RAND and MAC in EAP-Request/AKA-Reauthentication corresponds to AUTN. That would seem to imply that the Session-Id could be defined using NONCE_S and MAC instead of RAND and AUTN/NONCE_MT.
The corrected text in this errata shows the changes for EAP-AKA. Similar changes should be done for EAP-SIM (replace RAND || NONCE_MT with NONCE_S || MAC for fast re-authentication).
It should be noted that EAP-AKA' (RFC 5448) specification did not follow the MUST requirement in RFC 5247, i.e., it did not define Session-Id derivation. That could be done in an update of RFC 5247 with a clone of EAP-AKA design.
In addition, RFC 5247 did not define Session-Id definition for PEAP and there does not seem to exist any IETF RFC which such definition. That could also be included in RFC 5247 update and done similarly to EAP-TLS (Session-Id = EAP type || client.random || server.random).
It would be good to have a clear IETF reference for these details since EAP Session-Id is needed for ERP (RFC 6696) and that is now seeing additional implementation and deployment interest as a component of FILS authentication (IEEE 802.11ai). Same definition of EAP Session-Id is needed to make FILS shared key authentication implementation interoperable.
Errata ID: 1711
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Yoshihiro Ohba
Date Reported: 2008-12-20
Held for Document Update by: Brian Haberman
Date Held: 2009-03-11
Section 4 says:
EAP pre-authentication
In EAP pre-authentication, an EAP peer pre-establishes EAP keying
material with an authenticator prior to arrival. EAP
pre-authentication only affects the timing of EAP authentication,
but does not shorten or eliminate EAP (phase 1a) or AAA (phase 1b)
exchanges; Discovery (phase 0) and Secure Association Protocol
(phase 2) exchanges occur as described in Section 1.3. As a
result, the primary benefit is to enable EAP authentication to be
removed from the handoff critical path, thereby reducing latency.
Use of EAP pre-authentication within IEEE 802.11 is described in
[IEEE-802.11] and [8021XPreAuth].
Proactive key distribution
In proactive key distribution, keying material and authorizations
are transported from the backend authentication server to a
candidate authenticator in advance of a handoff. As a result, EAP
(phase 1a) is not needed, but the Discovery (phase 0), and Secure
Association Protocol exchanges (phase 2) are still necessary.
Within the AAA exchange (phase 1b), authorization and key
distribution functions are typically supported, but not
authentication. Proactive key distribution is described in
[MishraPro], [IEEE-03-084], and [HANDOFF].
It should say:
Move the reference 8021XPreAuth to the second paragraph.
Notes:
The reference [8021XPreAuth] describes a mechanism in which EAP
authentication happens only once with the serving authenticator, i.e.,
one EAP authentication with the serving authenticator generates
multiple MSKs and distributed to serving authenticator and target
authenticator, and there is no additional EAP authentication
performed between peer and target authenticator. This does not match
the definition of pre-authentication as described by the first paragraph;
hence the reference should be moved to the second paragraph.
Status: Rejected (1)
RFC 5247, "Extensible Authentication Protocol (EAP) Key Management Framework", August 2008
Note: This RFC has been updated by RFC 8940
Source of RFC: eap (int)
Errata ID: 1642
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Yoshihiro Ohba
Date Reported: 2008-12-20
Rejected by: Jari Arkko
Date Rejected: 2009-03-11
Section 4 says:
EAP pre-authentication
In EAP pre-authentication, an EAP peer pre-establishes EAP keying
material with an authenticator prior to arrival. EAP
pre-authentication only affects the timing of EAP authentication,
but does not shorten or eliminate EAP (phase 1a) or AAA (phase 1b)
exchanges; Discovery (phase 0) and Secure Association Protocol
(phase 2) exchanges occur as described in Section 1.3. As a
result, the primary benefit is to enable EAP authentication to be
removed from the handoff critical path, thereby reducing latency.
Use of EAP pre-authentication within IEEE 802.11 is described in
[IEEE-802.11] and [8021XPreAuth].
Proactive key distribution
In proactive key distribution, keying material and authorizations
are transported from the backend authentication server to a
candidate authenticator in advance of a handoff. As a result, EAP
(phase 1a) is not needed, but the Discovery (phase 0), and Secure
Association Protocol exchanges (phase 2) are still necessary.
Within the AAA exchange (phase 1b), authorization and key
distribution functions are typically supported, but not
authentication. Proactive key distribution is described in
[MishraPro], [IEEE-03-084], and [HANDOFF].
It should say:
EAP pre-authentication
In EAP pre-authentication, an EAP peer pre-establishes EAP
keying material with an authenticator through which the peer has
routed the EAP authentication prior to arrival. EAP
pre-authentication only affects the timing of EAP
authentication, but does not shorten or eliminate EAP (phase 1a)
or AAA (phase 1b) exchanges through the authenticator.
Discovery (phase 0) and Secure Association Protocol (phase 2)
exchanges occur as described in Section 1.3. As a result, the
primary benefit is to enable EAP authentication to be removed
from the handoff critical path, thereby reducing latency. Use
of EAP pre-authentication within IEEE 802.11 is described in
[IEEE-802.11].
Proactive key distribution
In proactive key distribution, keying material and authorizations
are transported from the backend authentication server to a
candidate authenticator in advance of a handoff. As a result, EAP
(phase 1a) is not needed, but the Discovery (phase 0), and Secure
Association Protocol exchanges (phase 2) are still necessary.
Within the AAA exchange (phase 1b), authorization and key
distribution functions are typically supported, but not
authentication. Proactive key distribution is described in
[MishraPro], [IEEE-03-084], [HANDOFF] and [8021XPreAuth].
Notes:
The EAP pre-authentication definition should be more clear that an EAP peer
runs EAP authentication through the target authenticator before EAP keying material will be pre-established with the target authenticator prior to arrival.
--VERIFIER NOTES--
Discussion between EAP and HOKEY chairs and the ADs revealed that this is not an appropriate change.