RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 9 records.

Status: Reported (9)

RFC 7170, "Tunnel Extensible Authentication Protocol (TEAP) Version 1", May 2014

Source of RFC: emu (sec)

Errata ID: 5127
Status: Reported
Type: Technical
Publication Format(s) : TEXT

Reported By: Tuure Vartiainen
Date Reported: 2017-09-25

Section 5.2. says:

IMSK = First 32 octets of TLS-PRF(EMSK, "TEAPbindkey@ietf.org" |
     "\0" | 64)

It should say:

IMSK = First 32 octets of TLS-PRF(EMSK, "TEAPbindkey@ietf.org" |
     "\0", 64)

Notes:

According to

RFC5246 The Transport Layer Security (TLS) Protocol Version 1.2

5. HMAC and the Pseudorandom Function

"TLS's PRF is created by applying P_hash to the secret as:

PRF(secret, label, seed) = P_<hash>(secret, label + seed)"

Errata ID: 5128
Status: Reported
Type: Technical
Publication Format(s) : TEXT

Reported By: Tuure Vartiainen
Date Reported: 2017-09-25

Section 5.2. says:

IMCK[j] = TLS-PRF(S-IMCK[j-1], "Inner Methods Compound Keys",
                IMSK[j], 60)

It should say:

IMCK[j] = TLS-PRF(S-IMCK[j-1], "Inner Methods Compound Keys" | 
                IMSK[j], 60)

Notes:

According to

RFC5246 The Transport Layer Security (TLS) Protocol Version 1.2

5. HMAC and the Pseudorandom Function

"TLS's PRF is created by applying P_hash to the secret as:

PRF(secret, label, seed) = P_<hash>(secret, label + seed)"

Errata ID: 5765
Status: Reported
Type: Technical
Publication Format(s) : TEXT

Reported By: Jouni Malinen
Date Reported: 2019-06-28

Section 4.2.2 says:

   M

      Mandatory, set to one (1)

It should say:

   M

      0 (Optional)

Notes:

Authority-ID TLV is used only as an Outer TLV (in TEAP/Start) and Section 4.3.1 mandates all Outer TLVs to be marked as optional ("Outer TLVs MUST be marked as optional"). As such, Section 4.2.2 is incorrect in claiming the Authority-ID TLV to use M=1.

Errata ID: 5767
Status: Reported
Type: Technical
Publication Format(s) : TEXT

Reported By: Jouni Malinen
Date Reported: 2019-06-28

Section 3.3.1 says:

   EAP method messages are carried within EAP-Payload TLVs defined in
   Section 4.2.10.  If more than one method is going to be executed in
   the tunnel, then upon method completion, the server MUST send an
   Intermediate-Result TLV indicating the result.

It should say:

   EAP method messages are carried within EAP-Payload TLVs defined in
   Section 4.2.10.  Upon completion of each EAP authentication method in
   the tunnel, the server MUST send an Intermediate-Result TLV
   indicating the result.

Notes:

TEAP description is somewhat vague in discussion about "EAP methods" vs. "EAP authentication methods" as it comes to the EAP methods performed in Phase 2 within the TLS tunnel. RFC 3748 defines Identity request/response as an EAP method. However, this method is not an "authentication method" which is a special case of an method where the Type is 4 or greater.

RFC 7170 uses correct terminology in the first paragraph of Section 3.3.1 when talking about multiple authentication methods not being allowed by RFC 3748 in a single EAP conversation. However, many, but not all, of the following "[EAP] method" instances are actually referring to "[EAP] authentication method". This results in incorrect claims on when the Intermediate-Result TLV and Crypto-Binding TLV are used. They are not used after an EAP non-authentication method like Identity (e.g., see the example in C.3); they are used after each EAP authentication method like EAP-pwd.

Furthermore, the comment about "more than one method is going to be executed in the tunnel" does not sound accurate. This applies even if only a single EAP authentication method is executed in the tunnel (Identity method is not required to be executed). The proposed text in this errata entry addresses these two issues in Section 3.3.1. The following additional changes would be needed to make rest of the specification use the terms more accurately:

3.3.3: "after each successful EAP method" --> "after each successful EAP authentication method"
3.8.3: "completion of the EAP method" --> "completion of the EAP authentication method"
4.2.11: "between multiple inner EAP methods within EAP" --> "after each inner EAP authentication method"
4.2.13: "after each successful EAP method" --> "after each successful EAP authentication method"

Errata ID: 5768
Status: Reported
Type: Technical
Publication Format(s) : TEXT

Reported By: Jouni Malinen
Date Reported: 2019-06-29

Section 5.3 says:

   The Compound MAC computation is as follows:

      CMK = CMK[j]
      Compound-MAC = MAC( CMK, BUFFER )

   where j is the number of the last successfully executed inner EAP
   method, MAC is the MAC function negotiated in TLS 1.2 [RFC5246], and
   BUFFER is created after concatenating these fields in the following
   order:

Notes:

This definition of how Compound MAC is computed is not compatible with the definition of Compound MAC fields in the Crypto-Binding TLV. Those fields have a fixed length of 20 octets based on Section 4.2.13 (and that TLV is claimed to have a fixed length of 76 octets). However, the MAC function negotiated in TLS have variable mac_length (e.g., MAC=SHA256 used HMAC-SHA256 with mac_length=32).

How is this supposed to work? Is Section 4.2.13 wrong in claiming that the Compound MAC fields are 20 octets? Or is Section 5.3 wrong in not specifying MAC() function to truncate the output to 20 octets? One of those need to be changed since the current design would work only with the mac_length=20 case (i.e., MAC=SHA with HMAC-SHA1).

Furthermore, that "TLS 1.2" part should not be hardcoding this to not allow TLS 1.3 or newer versions from being used.

It is also a bit strange to see the BUFFER include "The EAP Type sent by the other party in the first TEAP message." since that can only be EAP Type=TEAP, i.e., 55. If that is indeed a fixed value, it does not seem to add any protection for a negotiated parameter as a part of the crypto binding. Regardless, it would be good to be clearer in the text on how this "EAP Type" is to be encoded here (assumable it is a single octet field with value 0x37).

Errata ID: 5770
Status: Reported
Type: Technical
Publication Format(s) : TEXT

Reported By: Jouni Malinen
Date Reported: 2019-07-01

Section 5.4 says:

   TEAP authentication assures the Master Session Key (MSK) and Extended
   Master Session Key (EMSK) output from the EAP method are the result
   of all authentication conversations by generating an Intermediate
   Compound Key (IMCK).  The IMCK is mutually derived by the peer and
   the server as described in Section 5.2 by combining the MSKs from
   inner EAP methods with key material from TEAP Phase 1.  The resulting
   MSK and EMSK are generated as part of the IMCKn key hierarchy as
   follows:

      MSK  = TLS-PRF(S-IMCK[j], "Session Key Generating Function", 64)
      EMSK = TLS-PRF(S-IMCK[j],
           "Extended Session Key Generating Function", 64)

   where j is the number of the last successfully executed inner EAP
   method.

Notes:

Section 5.4 claims that IMCK (and as such, also) S-IMCK[j] is derived by combining the MSKs from inner EAP methods while Section 5.2 talks about two different derivations: one based on MSK and the other one based on EMSK. Section 5.2 seems clear on both MSK and EMSK based values being used in Compound MAC (since both are actually included in the Crypto-Binding TLV). However, Section 5.2 does not clarify how a unique S-IMCK[j] should be derived since there can be two different IMSK[j] values based on whether the inner EAP method generates MSK and EMSK. This gets even more confusing if there is a series of inner EAP methods of which at least one generates both MSK and EMSK, at least one generates only MSK, and at least one does not generate either MSK or EMSK. How exactly would MSK/EMSK from TEAP be derived in those cases? Based on Section 5.4, these are based on S-IMCK[j], but it is not clear how that is derived due to Section 5.2 having three different ways of deriving the IMSK[j] and two different Compound MAC values (and consequently, two different ways of deriving S-IMCK[j] after each successfully completed EAP authentication method).

It does not look like this could work in practice. There needs to be a clear definition of how to derive a single S-IMCK[j] value for TEAP MSK/EMSK derivation. It would also be helpful to clarify how CMK[j] is derived for each inner EAP method in case of different MSK/EMSK derivation support between the EAP methods used in the sequence.

Errata ID: 5775
Status: Reported
Type: Technical
Publication Format(s) : TEXT

Reported By: Jouni Malinen
Date Reported: 2019-07-04

Section 5.3 says:

   For authentication methods that generate keying material, further
   protection against man-in-the-middle attacks is provided through
   cryptographically binding keying material established by both TEAP
   Phase 1 and TEAP Phase 2 conversations.  After each successful inner
   EAP authentication, EAP EMSK and/or MSKs are cryptographically
   combined with key material from TEAP Phase 1 to generate a Compound
   Session Key (CMK).  The CMK is used to calculate the Compound MAC as
   part of the Crypto-Binding TLV described in Section 4.2.13, which
   helps provide assurance that the same entities are involved in all
   communications in TEAP.  During the calculation of the Compound MAC,
   the MAC field is filled with zeros.

   The Compound MAC computation is as follows:

      CMK = CMK[j]
      Compound-MAC = MAC( CMK, BUFFER )

   where j is the number of the last successfully executed inner EAP
   method, MAC is the MAC function negotiated in TLS 1.2 [RFC5246], and
   BUFFER is created after concatenating these fields in the following
   order:

Notes:

Section 5.3 does not describe how CMK is derived for the case where not inner EAP authentication method is executed (e.g., when Basic-Password-Auth is used at TLV level). Section 5.4 seems to address that case by implying that S-IMCK = session_key_seed (S-IMCK[0] does indeed have that value, but MSK/EMSK derivation uses S-IMCK[j], so use of S-IMCK here is slightly misleading). This seems to imply that MSK/EMSK derivation uses S-IMCK[0] and as such, Compound MAC derivation might use CMK[0], but CMK[0] is not defined (Section 5.2 defines CMK[j] for j=1..n-1, but not for j=0.

Furthermore, Section 4.2.13 is not clear on what Flags should be used in Crypto-Binding TLV when no inner EAP authentication method is executed. The only three values defined for Flags (1..3) all imply that either EMSK or MSK (or both) based Compound MAC is present, but there is no inner EAP method MSK/EMSK in this case since no such inner EAP method was executed. Maybe a new Flags value should be defined or alternatively, the MSK Compound MAC case could be extended to cover this no inner-EAP case with CMK[0] defined as proposed above to calculate the MSK Compound MAC.

Errata ID: 5844
Status: Reported
Type: Technical
Publication Format(s) : TEXT

Reported By: Jouni Malinen
Date Reported: 2019-08-24

Section C.1 says:

                            <- Crypto-Binding TLV (Request),
                                Result TLV (Success),
                                (Optional PAC TLV)

       Crypto-Binding TLV(Response),
       Result TLV (Success),
       (PAC-Acknowledgement TLV) ->

It should say:

                            <- Intermediate-Result-TLV (Success),
                                Crypto-Binding TLV (Request),
                                Result TLV (Success),
                                (Optional PAC TLV)

       Intermediate-Result-TLV (Success),
       Crypto-Binding TLV(Response),
       Result TLV (Success),
       (PAC-Acknowledgement TLV) ->

Notes:

Section 3.3.2 implies that Intermediate-Result TLV is used after each round of Basic-Password-Auth-Req/Resp TLVs. However, the example sequence in C.1 does not show this. The proposed change in this errata adds the Intermediate-Result TLV indication here. Similar change should be done in C.2 (i.e., add Intermediate-Result TLV (Failure) to the messages that include Result TLV) since the language in 3.3.2 describe the indication to be used for both success and failure cases.

In addition to this change in C.1, it would be good to clarify the specification globally to avoid confusion about this case since almost all discussion regarding Intermediate-Result TLV currently is in the context of inner EAP authentication. 3.3.2 should have a MUST statement similar to 3.3.1. 3.6 should cover success or failure indications of basic password auth like it does EAP methods. 4.2.11 should note Intermediate-Result TLV is used with both inner EAP and basic password auth. 4.2.13 should mention basic password auth in the "regardless of whether there is an inner EAP method authentication or not" sentence.

Errata ID: 5845
Status: Reported
Type: Technical
Publication Format(s) : TEXT

Reported By: Jouni Malinen
Date Reported: 2019-08-24

Section 3.3.1 says:

   EAP method messages are carried within EAP-Payload TLVs defined in
   Section 4.2.10.  If more than one method is going to be executed in
   the tunnel, then upon method completion, the server MUST send an
   Intermediate-Result TLV indicating the result.

It should say:

   EAP method messages are carried within EAP-Payload TLVs defined in
   Section 4.2.10.  Upon method completion, the server MUST send an
   Intermediate-Result TLV indicating the result.

Notes:

Description of whether Intermediate-Result TLV is supposed to be used in the case where only a single inner EAP authentication method is used. Section 3.3.1 says "more than one method is going to be executed in the tunnel, then upon method completion, the server MUST send an Intermediate-Result TLV indicating the result", Section 3.3.3 says "The Crypto-Binding TLV and Intermediate-Result TLV MUST be included to perform cryptographic binding after each successful EAP method in a sequence of one or more EAP methods", 4.2.13 says "It MUST be included with the Intermediate-Result TLV to perform cryptographic binding after each successful EAP method in a sequence of EAP methods", Annex C.3 shows an example exchange with a single inner EAP authentication method with use of Intermediate-Result TLV.

It looks like the majority of the places discussion this topic implies that there is going to be an Intermediate-Result TLV after each inner EAP authentication method and the text in 3.3.1 is the only clear case of conflicting (or well, at least misleading if one were to claim it does not explicitly say MUST NOT for the one inner EAP authentication method case). As such, I'd conclude the Intermediate-Result TLV is indeed going to be exchanged after each EAP authentication method and the proposed text change to 3.3.1 covers that.

Report New Errata