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