RFC Errata
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
See Also: RFC 4187 w/ inline errata
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