RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 4 records.

Status: Verified (3)

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 GROUP
Area Assignment: ops

Errata ID: 171
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 8.1 says:

   Length

         Indicates the length of this attribute in multiples of four
         bytes.  The maximum length of an attribute is 1024 bytes.  The
         length includes the Attribute Type and Length bytes.

It should say:

   Length

         Indicates the length of this attribute in multiples of four
         bytes.  The maximum length of an attribute is 1020 bytes.  The
         length includes the Attribute Type and Length bytes.

Notes:

As there is no offset defined, the maximum encoded Length value
of 255 corresponds to a total of 4*255 = 1020 octets.

Note:
Other protocols incorporate an offset of -1 in similar cases, e.g.,
when a TLV Length field comprises the length of the 'T' and 'L',
also removing the artificially designed-in error case (Length=0),
that otherwise must be checked for by all implementations!
Some people speak of bad protocol design when encountering
Length fields that do not indicate the true length of an object
value proper, which might be zero.

from pending

Errata ID: 956
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 10.14 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.

Notes:

"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.

from pending

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

Status: Held for Document Update (1)

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 GROUP
Area Assignment: ops

Errata ID: 1576
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT

Reported By: Guy Lespade
Date Reported: 2008-10-16
Held for Document Update by: ron bonica

Section 6.1 says:

Within this section, the 3rd paragraph on page 38 says:

   The receipt of a notification code with the S bit set to one (values
|  32768...65536) does not imply failure.  Notification code "Success"
   (32768) has been reserved as a general notification code to indicate
   successful authentication.


It should say:

   The receipt of a notification code with the S bit set to one (values
|  32768...65535) does not imply failure.  Notification code "Success"
   (32768) has been reserved as a general notification code to indicate
   successful authentication.

Notes:

Within this section, 2nd paragraph on page 38, values start from 0, so they end at 65535 (2^16 - 1).

Report New Errata



Advanced Search