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