RFC Errata
RFC 4186, "Extensible Authentication Protocol Method for Global System for Mobile Communications (GSM) Subscriber Identity Modules (EAP-SIM)", January 2006
Source of RFC: IETF - NON WORKING GROUPArea Assignment: ops
See Also: RFC 4186 w/ inline errata
Errata ID: 957
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-11-26
Verifier Name: Henry Haverinen
Date Verified: 2006-12-01
(1) [[posted separately.]] (2) [[posted separately.]] (3) [missing article] Within Section 1, the 2nd paragraph on page 5 says: EAP-SIM specifies optional support for protecting the privacy of subscriber identity using the same concept as the GSM, which uses pseudonyms/temporary identifiers. [...] It should say: | EAP-SIM specifies optional support for protecting the privacy of the subscriber identity using the same concept as the GSM, which uses pseudonyms/temporary identifiers. [...] (4) [missing article] Section 2, near the bottom of page 6, says: Fast Re-authentication Username The username portion of fast re-authentication identity, i.e., not including any realm portions. It should say: Fast Re-authentication Username | The username portion of the fast re-authentication identity, i.e., not including any realm portions. (5) [missing article] The first paragraph of Section 4.2.3, on page 19, says: If EAP-SIM peer is started upon receiving an EAP-Request/Identity message, then the peer MAY use an EAP-SIM identity in the EAP- Response/Identity packet. [...] It should say: | If the EAP-SIM peer is started upon receiving an EAP-Request/Identity message, then the peer MAY use an EAP-SIM identity in the EAP- Response/Identity packet. [...] (6) [missing article] The Section title (on page 19 and in the ToC), v 4.2.4. Server Operation in the Beginning of EAP-SIM Exchange should better say: vvvv 4.2.4. Server Operation in the Beginning of an EAP-SIM Exchange (7) [misleading continuation indicator] In Section 4.3.6, Figure 7 (on page 29) contains for lines that might erroneously be misunderstod to indicate the omission of some protocol steps (which is not the case). I suspect that this is an artifact from a draft version where Figure 7 was split over two pages; after joining the parts, these continuation indicators have become ambiguous, and hence should be deleted. On mid-page 29, the lines: | EAP-Request/SIM/Start | | (AT_FULLAUTH_ID_REQ, AT_VERSION_LIST) | |<------------------------------------------------------| | | : : : : : : : : |EAP-Response/SIM/Start | |(AT_IDENTITY with a pseudonym identity, AT_NONCE_MT, | | AT_SELECTED_VERSION) | |------------------------------------------------------>| should say: | EAP-Request/SIM/Start | | (AT_FULLAUTH_ID_REQ, AT_VERSION_LIST) | |<------------------------------------------------------| | | |EAP-Response/SIM/Start | |(AT_IDENTITY with a pseudonym identity, AT_NONCE_MT, | | AT_SELECTED_VERSION) | |------------------------------------------------------>| (8) [grammar / articles] Within Section 5.3, the text on top of page 32, If the EAP server supports fast re-authentication, it MAY include the | skippable AT_NEXT_REAUTH_ID attribute in the encrypted data of EAP-Request/SIM/Challenge message (Section 9.3). This attribute contains a new fast re-authentication identity for the next fast re-authentication. The attribute also works as a capability flag | that, indicating that the server supports fast re-authentication, and that the server wants to continue using fast re-authentication within the current context. The peer MAY ignore this attribute, in which case it MUST use full authentication next time. If the peer wants to use re-authentication, it uses this fast re-authentication identity | on next authentication. Even if the peer has a fast re-authentication identity, [...] should say: If the EAP server supports fast re-authentication, it MAY include the | skippable AT_NEXT_REAUTH_ID attribute in the encrypted data of the EAP-Request/SIM/Challenge message (Section 9.3). This attribute contains a new fast re-authentication identity for the next fast re-authentication. The attribute also works as a capability flag, | indicating that the server supports fast re-authentication, and that the server wants to continue using fast re-authentication within the current context. The peer MAY ignore this attribute, in which case it MUST use full authentication next time. If the peer wants to use re-authentication, it uses this fast re-authentication identity | on the next authentication. Even if the peer has a fast re-authentication identity, [...] (9) [misleading continuation indicator, again] Repetition of the issue described in item (7) above: In Section 5.4, in Figure 8 (on page 35), the 4 lines: : : : : : : : : should be deleted, because these might erroneously be misunderstood as indicating the omission of some protocol steps. (10) [missing article] In Section 7, the paragraph at the bottom of page 43 says: The notation n*Kc in the formula above denotes the n Kc values concatenated. The Kc keys are used in the same order as the RAND | challenges in AT_RAND attribute. NONCE_MT denotes the NONCE_MT value (not the AT_NONCE_MT attribute, but only the nonce value). The Version List includes the 2-byte-supported version numbers from AT_VERSION_LIST, in the same order as in the attribute. [...] It should say: The notation n*Kc in the formula above denotes the n Kc values concatenated. The Kc keys are used in the same order as the RAND | challenges in the AT_RAND attribute. NONCE_MT denotes the NONCE_MT value (not the AT_NONCE_MT attribute, but only the nonce value). The Version List includes the 2-byte-supported version numbers from AT_VERSION_LIST, in the same order as in the attribute. [...]
Notes:
from pending