RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 3 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 GROUP
Area 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.

Report New Errata



Advanced Search