Subject: RFC 4186 errata

From: Alfred Hönes <[email-masked]>
Date: Sun, 26 Nov 2006 22:13:39 +0100 (MEZ)

Hello,
the recent publication of RFC 4746 (EAP-PAX) has caused me to
also study RFC 4186 (EAP-SIM) authored by you.
There, I found a couple of textual issues, at least two of which
seem to be rather significant.

After first presenting these two most important issues, further
flaws are reported in RFC textual order.

I use change bars ('|' in column 1) and occasionally up/down
pointing marker lines ('^^^'/'vvv') to emphasize the location
of textual issues and/or proposed corrections.

(1)  IMPORTANT -- mis-specification of a protocol limit

Section 8.1, near the bottom of page 46, contains the explanation:

   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.

This is wrong.  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.
                                                         ^^
Rationale:
  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.

(2)  IMPORTANT -- misleading specification !

On page 62, the 2nd paragraph of 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.  [...]

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.

(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.  [...]

Please comment.

At least, items (1) and (2) -- and perhaps (7) and (9) as well --
seem to deserve an Errata Note.

Preferrably, you should submit an Author's Errata Note to the
RFC Editor's RFC Errata web pages, making freely use of the
material supplied above.  But if you like, I can formally
submit an Errata Note on my own, with your consent.

Best regards,
  Alfred Hönes.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [email-masked]                     |
+------------------------+--------------------------------------------+

---

From: Alfred Hönes <[email-masked]>
Date: Sun, 26 Nov 2006 23:25:32 +0100 (MEZ)

Hello,
the recent publication of RFC 4746 (EAP-PAX) has caused me to
also study RFC 4187 (EAP-AKA) authored by you.
There, I found a couple of textual issues, I'd like to comment on.

Below, these flaws are reported in RFC textual order.

(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)  IMPORTANT -- [misleading continuation indicator]

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.

          |                            +------------------------------+
          |                            | Server does not accept       |
          |                            | The fast re-authentication   |
          |                            | Identity                     |
          |                            +------------------------------+
          |                                                       |
          :                                                       :
          :                                                       :

          :                                                       :
          :                                                       :
          |     EAP-Request/AKA-Identity                          |
          |     (AT_FULLAUTH_ID_REQ)                              |
          |<------------------------------------------------------|

should say:

          |                            +------------------------------+
          |                            | Server does not accept       |
          |                            | The fast re-authentication   |
          |                            | Identity                     |
          |                            +------------------------------+
          |                                                       |
          |     EAP-Request/AKA-Identity                          |
          |     (AT_FULLAUTH_ID_REQ)                              |
          |<------------------------------------------------------|

(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:

       :                                                       :
       :                                                       :

       :                                                       :
       :                                                       :

(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:

It should say:

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)  [text too pessimistic?]

The second paragraph of Section 12.7, on page 71/72, 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
 <<page break>>
   included in the MACs later on, and thus some other precautions must
   be taken to avoid modifications to them.

IMHO, according to the rules specified in Section 10.13, application
of the AT_CHECKCODE attribute should generally rule out this issue!

Please comment.

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.

Best regards,
  Alfred Hönes.

--

---

From: Alfred Hönes <[email-masked]>
Date: Tue, 5 Dec 2006 15:04:28 +0100 (MEZ)

Hello,

you already have been copied my original messages reporting
textual issues with RFC 4186 and RFC 4187 to the authors of
these documents.

The Message-IDs have been
  <[email-masked]>  and
  <[email-masked]> ,
respectively.

Now, on Fri, 1 Dec 2006 14:23:22 +0200, in message
<[email-masked]>
(also copied to you) Henry Maverinen <[email-masked]>
responded:

> Subject: RE: RFC 4186 errata
>
>
> Hello all,
> 
> Alfred, thank you for your detailed study of RFC 4186.
> I agree with the corrections that you proposed.
> 
> If it is OK to Joe, I'd appreaciate if you can submit
> an Errata Note to RFC Editor's web pages, as you kindly
> proposed to do.
> 
> Best regards,
> Henry

and on Fri, 1 Dec 2006 14:23:25 +0200, in message
<[email-masked]>
Henry Maverinen wrote:

> Subject: RE: RFC 4187 errata
> 
> 
> Hello all,
> 
> Alfred, thank you for studying and commenting the EAP-AKA document -
> again.  I fully agree with the corrections that you proposed.
> 
> Regarding issue (19), I agree the text is too pessimistic. The reason
> is that the AT_CHECKCODE concept was not included in early drafts.
> Since we introduced AT_CHECKCODE, the issue has been taken care of.
> 
> If it is OK to Jari, I'd appreaciate if you can submit
> an Errata Note to RFC Editor's web pages, as you kindly
> proposed to do.
> 
> Best regards,
> Henry

Following Henry's suggestion, I have slightly reworked my original
notes.  Most of the original text already had been formatted for
easy incorporation in an errata note; additional explanatory text,
'Rationale', and 'Notes' have been cut off now.  The single open
question (item (19) for RFC 4187) is now addressed with a concrete
text proposal, incorporating wording from Henry's response.
[ Henry: please double check again! ]

Enclosed you find two attachments with the concise errata text.

Best regards,
  Alfred Hönes.

--