RFC Errata
Found 5 records.
Status: Verified (3)
RFC 4187, "Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA)", January 2006
Note: This RFC has been updated by RFC 5448, RFC 9048
Source of RFC: IETF - NON WORKING GROUPArea Assignment: int
Errata ID: 959
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) [misleading wording]
In Section 3, the RFC text at the bottom of page 13 says:
[...]. In certain circumstances, shown in Figure 4, it is
possible for the sequence numbers to get out of sequence.
This sentence is misleading. Figure 4 only shows the *discovery*
of the de-synchronization; it does not show 'certain circumstances'
that might lead to this problem.
(2) [typo]
On page 18, the second paragraph of Section 4.1.1.7 says:
[...]. It is
recommended that the EAP servers implement some centralized mechanism
to allow all EAP servers of the home operator to map pseudonyms
| generated by other severs to the permanent identity. [...]
^^^^^^
It should say:
[...]. It is
recommended that the EAP servers implement some centralized mechanism
to allow all EAP servers of the home operator to map pseudonyms
| generated by other servers to the permanent identity. [...]
^
(3) [missing article]
The last paragraph of Section 4.1.1.8, on page 20, says:
If the peer does not receive a new pseudonym username in the
EAP-Request/AKA-Challenge message, the peer MAY use an old pseudonym
username instead of the permanent username on next full
authentication. [...]
It should say:
If the peer does not receive a new pseudonym username in the
EAP-Request/AKA-Challenge message, the peer MAY use an old pseudonym
| username instead of the permanent username on the next full
authentication. [...]
^^^^^
(4) [grammar / misleading punctuation]
The last paragraph of Section 4.1.2.1, on page 22, says:
Please note that only the EAP-AKA peer and the EAP-AKA server process
| the AT_IDENTITY attribute and entities that pass through; EAP packets
do not process this attribute. [...]
^ ^^
It should say:
Please note that only the EAP-AKA peer and the EAP-AKA server process
| the AT_IDENTITY attribute, and entities that pass through EAP packets
do not process this attribute. [...]
^^ ^
(5) [missing article]
The first paragraph of Section 4.1.3, on top of page 23, says:
| If EAP-AKA peer is started upon receiving an EAP-Request/Identity
message, then the peer MAY use an EAP-AKA identity in the EAP-
Response/Identity packet. [...]
It should say:
| If an EAP-AKA peer is started upon receiving an EAP-Request/Identity
message, then the peer MAY use an EAP-AKA identity in the EAP-
Response/Identity packet. [...]
(6) [grammar]
The second paragraph of Section 4.1.4, on mid-page 23, says:
If the server chooses to not ignore the contents of
| EAP-Response/Identity, then the server may already receive an EAP-AKA
| identity in this packet. However, if the EAP server has not received
any EAP-AKA peer identity (permanent identity, pseudonym identity, or
fast re-authentication identity) from the peer when sending the first
EAP-AKA request, or if the EAP server has received an
EAP-Response/Identity packet but the contents do not appear to be a
valid permanent identity, pseudonym identity, or a re-authentication
identity, then the server MUST request an identity from the peer
using one of the methods below.
It should say:
If the server chooses to not ignore the contents of
| EAP-Response/Identity, then the server may already have received an
EAP-AKA identity in this packet. However, if the EAP server has not
received any EAP-AKA peer identity (permanent identity, pseudonym
identity, or fast re-authentication identity) from the peer when
sending the first EAP-AKA request, or if the EAP server has received
an EAP-Response/Identity packet but the contents do not appear to be
a valid permanent identity, pseudonym identity, or a
re-authentication identity, then the server MUST request an identity
from the peer using one of the methods below.
(7) [misleading wording]
On page 25, the first paragraph of Section 4.1.6 says:
The section above specifies two possible ways the peer can operate
upon receipt of AT_PERMANENT_ID_REQ because a received
AT_PERMANENT_ID_REQ does not necessarily originate from the valid
| network. However, an active attacker may transmit an
EAP-Request/AKA-Identity packet with an AT_PERMANENT_ID_REQ attribute
to the peer, in an effort to find out the true identity of the user.
If the peer does not want to reveal its permanent identity, then the
peer sends the EAP-Response/AKA-Client-Error packet with the error
code "unable to process packet", and the authentication exchange
terminates.
It should say:
The section above specifies two possible ways the peer can operate
upon receipt of AT_PERMANENT_ID_REQ because a received
AT_PERMANENT_ID_REQ does not necessarily originate from the valid
| network. In fact, an active attacker may transmit an
EAP-Request/AKA-Identity packet with an AT_PERMANENT_ID_REQ attribute
to the peer, in an effort to find out the true identity of the user.
If the peer does not want to reveal its permanent identity, then the
peer sends the EAP-Response/AKA-Client-Error packet with the error
code "unable to process packet", and the authentication exchange
terminates.
(8) [[posted separately.]]
(9) [missing article]
The 4th paragraph of Section 5.1, near the bottom of page 32, says:
[...]. For example, on the second
| fast re-authentication, counter value is two or greater, etc. The
AT_COUNTER attribute is encrypted.
It should say:
[...]. For example, on the second
| fast re-authentication, the counter value is two or greater, etc.
The AT_COUNTER attribute is encrypted.
(10) [missing article]
The first paragraph of Section 5.3, near the bottom of page 33, says:
[...]. 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/-
AKA-Challenge message. This attribute contains a new
re-authentication identity for the next fast re-authentication. [..]
It 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/-AKA-Challenge message. This attribute contains a new
re-authentication identity for the next fast re-authentication. [..]
(The spurious blank after "EAP-" disappears due to the new line break.)
(11) IMPORTANT -- [misleading continuation indicator, again]
Repetition of the issue described in item (8) above:
In Section 5.4, in Figure 10 (on page 36), the 6 lines:
: :
: :
: :
: :
should be deleted, because these might erroneously be misunderstood
as indicating the omission of some protocol steps.
(12) [missing article]
The last paragraph of Section 5.5, on page 38, says:
It should be noted that in this case, peer identity is only
transmitted in the AT_IDENTITY attribute at the beginning of the
whole EAP exchange. The fast re-authentication identity used in this
AT_IDENTITY attribute will be used in key derivation (see Section 7).
It should say:
| It should be noted that in this case, the peer identity is only
transmitted in the AT_IDENTITY attribute at the beginning of the
whole EAP exchange. The fast re-authentication identity used in this
AT_IDENTITY attribute will be used in key derivation (see Section 7).
(13) [missing article]
Within Section 6.1, the 3rd paragraph on page 39 says:
[...]. A re-authentication
round is considered successful only if the peer has successfully
verified AT_MAC and AT_COUNTER attributes, and does not include the
AT_COUNTER_TOO_SMALL attribute in EAP-Response/AKA-Reauthentication.
It should say:
[...]. A re-authentication
round is considered successful only if the peer has successfully
| verified the AT_MAC and AT_COUNTER attributes, and does not include
the AT_COUNTER_TOO_SMALL attribute in EAP-Response/AKA-
Reauthentication.
(14) [grammar / articles]
Within Section 8.1, the text at the bottom page 46,
Attributes numbered within the range 0 through 127 are called
non-skippable attributes. When an EAP-AKA peer encounters a
non-skippable attribute type that the peer does not recognize, the
| peer MUST send the EAP-Response/AKA-Client-Error packet, and the
authentication exchange terminates. If an EAP-AKA server encounters
a non-skippable attribute that the server does not recognize, then
| the server sends EAP-Request/AKA-Notification packet with an
[<page break>]
[...]
should say:
Attributes numbered within the range 0 through 127 are called
non-skippable attributes. When an EAP-AKA peer encounters a
non-skippable attribute type that the peer does not recognize, the
| peer MUST send an EAP-Response/AKA-Client-Error packet, and the
authentication exchange terminates. If an EAP-AKA server encounters
a non-skippable attribute that the server does not recognize, then
| the server sends an EAP-Request/AKA-Notification packet with an
[<page break>]
[...]
(15) [missing article]
Section 9, on page 48 says:
| [...]. Message format is specified in
Section 8.1.
It should say:
| [...]. The message format is specified in
Section 8.1.
(16) IMPORTANT -- misleading specification !
On page 63, the 2nd paragraph of Section 10.15 says:
The value field of the AT_MAC attribute contains two reserved bytes
followed by a keyed message authentication code (MAC). The MAC is
| calculated over the whole EAP packet and concatenated with optional
message-specific data, with the exception that the value field of the
MAC attribute is set to zero when calculating the MAC. [...]
It should say:
The value field of the AT_MAC attribute contains two reserved bytes
followed by a keyed message authentication code (MAC). The MAC is
| calculated over the whole EAP packet, concatenated with optional
message-specific data, with the exception that the value field of the
MAC attribute is set to zero when calculating the MAC. [...]
Rationale:
"The MAC is calculated ... and concatenated ..."
could easily be misunderstood. From the context it can be
concluded that the potential ambiguity should be resolved and
clarified by omitting the word 'and', and replacing it by a comma.
(17) [improper, extraneous wording]
In Section 10.15, the second-to-last paragraph on page 63 says:
| The MAC algorithm is HMAC-SHA1-128 [RFC2104] keyed hash value. (The
HMAC-SHA1-128 value is obtained from the 20-byte HMAC-SHA1 value by
truncating the output to 16 bytes. Hence, the length of the MAC is
16 bytes.) The derivation of the authentication key (K_aut) used in
the calculation of the MAC is specified in Section 7.
It should say:
| The MAC algorithm is HMAC-SHA1-128 [RFC2104]. (The HMAC-SHA1-128
value is obtained from the 20-byte HMAC-SHA1 value by truncating the
output to 16 bytes. Hence, the length of the MAC is 16 bytes.) The
derivation of the authentication key (K_aut) used in the calculation
of the MAC is specified in Section 7.
Rationale: Beyond grammar, don't mess up 'algorithm' and 'value' !
(17) [missing article]
The second text paragraph of Section 10.18, on page 65, says:
The value field of the AT_NONCE_S attribute contains two reserved
bytes followed by a random number (16 bytes) that is freshly
generated by the server for this EAP-AKA fast re-authentication. The
random number is used as challenge for the peer and also as a seed
value for the new keying material. [...]
It should say:
The value field of the AT_NONCE_S attribute contains two reserved
bytes followed by a random number (16 bytes) that is freshly
generated by the server for this EAP-AKA fast re-authentication. The
| random number is used as a challenge for the peer and also as a seed
value for the new keying material. [...]
(18) [misleading wording]
Within Section 11, the second text paragraph on page 67 says:
[...]. The following attribute types are
specified in this document in [EAP-SIM]:
^
It should say:
[...]. The following attribute types are
| specified in this document and in [EAP-SIM]:
^^^^^
(19) [[posted separately.]]
Notes:
Whereas most items just should be noted for consideration when
preparing future derived work, at least items (8), (11), and (16)
seem to deserve an Errata Note.
from pending
Errata ID: 966
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
Section 12.7 says:
As described in Section 8, EAP-AKA allows the protocol to be extended by defining new attribute types. When defining such attributes, it should be noted that any extra attributes included in EAP-Request/AKA-Identity or EAP-Response/AKA-Identity packets are not included in the MACs later on, and thus some other precautions must be taken to avoid modifications to them.
It should say:
As described in Section 8, EAP-AKA allows the protocol to be extended by defining new attribute types. When defining such attributes, it should be noted that the AT_CHECKCODE attribute (see Section 10.13) can be used to achieve the protection of extra attributes included in EAP-Request/AKA-Identity or EAP-Response/AKA-Identity packets.
Notes:
This text is too pessimistic. The reader's attention should be
directed to Section 10.13 of the RFC. The (late) introduction of
the AT_CHECKCODE concept, as explained there, has taken care of
this issue; implementations should make use of this attribute.
from pending
Errata ID: 3967
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Huanggj
Date Reported: 2014-04-18
Verifier Name: Brian Haberman
Date Verified: 2014-06-05
Section 3 says:
After obtaining the subscriber identity, the EAP server obtains an authentication vector (RAND, AUTN, RES, CK, IK) for use in authenticating the subscriber. From the vector, the EAP server derives the keying material, as specified in Section 6.4.
It should say:
After obtaining the subscriber identity, the EAP server obtains an authentication vector (RAND, AUTN, RES, CK, IK) for use in authenticating the subscriber. From the vector, the EAP server derives the keying material, as specified in Section 7.
Status: Held for Document Update (2)
RFC 4187, "Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA)", January 2006
Note: This RFC has been updated by RFC 5448, RFC 9048
Source of RFC: IETF - NON WORKING GROUPArea Assignment: int
Errata ID: 3968
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Huanggj
Date Reported: 2014-04-19
Held for Document Update by: Brian Haberman
Date Held: 2014-06-05
Section 9.3 says:
When processing this message, the peer MUST process AT_RAND and AT_AUTN before processing other attributes. Only if these attributes are verified to be valid, the peer derives keys and verifies AT_MAC. The operation in case an error occurs is specified in Section 6.3.1.
Notes:
The words "these attributes" in sentence "Only if these attributes are verified to be valid, the peer derives keys and verifies AT_MAC." is obscured. It's not clear which attributes are indicated. "AT_RAND and AT_AUTN" or "other attributes"?
Errata ID: 170
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-11-26
Held for Document Update by: ron bonica
Date Held: 2006-12-01
Section 4.2.5 says:
| +------------------------------+
| | Server does not accept |
| | The fast re-authentication |
| | Identity |
| +------------------------------+
| |
: :
: :
: :
: :
| EAP-Request/AKA-Identity |
| (AT_FULLAUTH_ID_REQ) |
|<------------------------------------------------------|
It should say:
| +------------------------------+
| | Server does not accept |
| | The fast re-authentication |
| | Identity |
| +------------------------------+
| |
| EAP-Request/AKA-Identity |
| (AT_FULLAUTH_ID_REQ) |
|<------------------------------------------------------|
Notes:
In Section 4.2.5, Figure 9 (on page 31) contains six 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 9 was split over two pages; after joining the parts,
these continuation indicators have become ambiguous, and hence
should be deleted.
from pending