Verify Errata

[osdingo]

Errata ID: 5765 Errata ID: 6157 Errata ID: 5127 Errata ID: 5128 Errata ID: 5767 Errata ID: 5768 Errata ID: 5770 Errata ID: 5775 Errata ID: 5844 Errata ID: 5845 Errata ID: 7145 Errata ID: 7259

[osdingo]

Errata ID: 5765 - Fixed - Authority ID TLV is marked as optional (Section 4.2.2)

[osdingo]

Errata ID: 6157 Fixed - Status field text it section 4.2.9 references party since the message could be sent by client or server.

[osdingo]

Errata ID: 5127 Fixed - Correctly describes the derivation of IMSK

Errata Resolution:

Status: Hold For Document Update or Verified Type: Technical Section: 5.2

Original Text: IMSK = First 32 octets of TLS-PRF(EMSK, "TEAPbindkey@ietf.org" | "\0" | 64) where "|" denotes concatenation, EMSK is the EMSK from the inner method, "TEAPbindkey@ietf.org" consists the ASCII value for the label "TEAPbindkey@ietf.org" (without quotes), "\0" = is a NULL octet (0x00 in hex), length is the 2-octet unsigned integer in network byte order, and TLS-PRF is the PRF negotiated as part of TLS handshake [RFC5246].

Corrected Text: IMSK[j] = First 32 octets of TLS-PRF(EMSK[j], "TEAPbindkey@ietf.org", 0x00 | 0x00 | 0x40) where "|" denotes concatenation and the TLS-PRF is defined in [RFC5246] as

PRF(secret, label, seed) = P_(secret, label | seed).

The secret is the EMSK from the j'th inner method, the label is "TEAPbindkey@ietf.org" consisting of the ASCII value for the label "TEAPbindkey@ietf.org" (without quotes), the seed consists of the "\0" null delimiter (0x00) and 2-octet unsigned integer length in network byte order (0x00 | 0x40) specified in [RFC5295].

[osdingo]

Errata ID: 5128 Fixed - Key derivation now uses correct function signature

Errata Resolution:

Status: Hold For Document Update or Verified Type: Technical Section: 5.2

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

Corrected Text: IMCK[j] = the first 60 octets of TLS-PRF(S-IMCK[j-1], "Inner Methods Compound Keys", IMSK[j])

[osdingo]

Errata ID: 5767 Fixed: Referenced sections have been updated and well as other sections in the document.

Errata Resolution:

Status: Hold For Document Update

[osdingo]

Errata ID: 5768 Fixed: Calculation of compound MAC has been clarified

Errata Resolution:

Status: Hold For Document Update or Verified Type: Technical Section: 5.3

Original Text: 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:

1 The entire Crypto-Binding TLV attribute with both the EMSK and MSK Compound MAC fields zeroed out.

2 The EAP Type sent by the other party in the first TEAP message.

3 All the Outer TLVs from the first TEAP message sent by EAP server to peer. If a single TEAP message is fragmented into multiple TEAP packets, then the Outer TLVs in all the fragments of that message MUST be included.

4 All the Outer TLVs from the first TEAP message sent by the peer to the EAP server. If a single TEAP message is fragmented into multiple TEAP packets, then the Outer TLVs in all the fragments of that message MUST be included.

Corrected Text: The Compound MAC computation is as follows:

Compound-MAC = the first 20 octets of MAC( CMK[n], BUFFER )

where n is the number of the last successfully executed inner method, MAC is the MAC function negotiated in TLS (e.g. TLS 1.2 in [RFC5246]), and BUFFER is created after concatenating these fields in the following order:

1.  The entire Crypto-Binding TLV attribute with both the EMSK and MSK Compound MAC fields zeroed out.

2.  The EAP Type sent by the other party in the first TEAP message, which MUST be TEAP, encoded as one octet of 0x37.

3.  All the Outer TLVs from the first TEAP message sent by EAP server to peer. If a single TEAP message is fragmented into multiple TEAP packets, then the Outer TLVs in all the fragments of that message MUST be included.

4.  All the Outer TLVs from the first TEAP message sent by the peer to the EAP server. If a single TEAP message is fragmented into multiple TEAP packets, then the Outer TLVs in all the fragments of that message MUST be included.

If no inner EAP authentication method is run then no EMSK or MSK will be generated. If an IMSK needs to be generated then the MSK and therefore the IMSK is set to 0 (e.g., MSK = 32 octets of 0x00s).

[osdingo]

Errata ID: 5770 Fixed: EAP MSK generation has been updated

Errata Resolution:

Status: Hold For Document Update or Verified Type: Technical Section: 5.4

Original Text: 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.

The EMSK is typically only known to the TEAP peer and server and is not provided to a third party. The derivation of additional keys and transportation of these keys to a third party are outside the scope of this document.

If no EAP methods have been negotiated inside the tunnel or no EAP methods have been successfully completed inside the tunnel, the MSK and EMSK will be generated directly from the session_key_seed meaning S-IMCK = session_key_seed.

Corrected Text:

TEAP authentication assures the Master Session Key (MSK) and Extended Master Session Key (EMSK) output from the EAP authentication 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 methods with key material from TEAP Phase 1. The resulting MSK and EMSK are generated from the final ("n"th) inner method, as part of the IMCK[n] key hierarchy via the following derivation:

  MSK  = the first 64 octets of TLS-PRF(S-IMCK[n],
         "Session Key Generating Function")
  EMSK = the first 64 octets of TLS-PRF(S-IMCK[n],
         "Extended Session Key Generating Function")

The TLS-PRF is defined in [RFC5246] as

  PRF(secret, label, seed) = P_<hash>(secret, label | seed).

where "|" denotes concatenation. The secret is S-IMCK[n] where n is the number of the last generated S-IMCK[j] from Section 5.2. The label is is the ASCII value for the string without quotes. The seed is empty (0 length) and is omitted from the derivation.

The EMSK is typically only known to the TEAP peer and server and is not provided to a third party. The derivation of additional keys and transportation of these keys to a third party are outside the scope of this document.

If no EAP authentication methods have been negotiated inside the tunnel or no EAP authentication methods have been successfully completed inside the tunnel, the MSK and EMSK will be generated directly from the session_key_seed meaning S-IMCK[0] = session_key_seed.

As we noted above, not all inner methods generate both MSK and EMSK, so we have to maintain two independent derivations of S-IMCK[j], one for each of MSK[j] and EMSK[j]. The final derivation using S-IMCK[n] must choose only one of these keys.

If the Crypto-Binding TLV contains an EMSK compound MAC, then the derivation is taken from the S_IMCK_EMSK[n]. Otherwise it is taken from the S_IMCK_MSK[n].

[osdingo]

Errata ID: 5775 Fixed: updated as part of the resolution to 5770 and 5768

Errata Resolution:

Status: Hold For Document Update (fixed as part of 5768 text perhaps it could be rejected citing that it is fixed by 5768?)

[jsalowey]

Errata ID: 5844 Fixed: Examples C1 and C2 are updated Errata Resolution:

Status: Hold For Document Update or Verified (PAC was removed from EAP-TEAP revision) Type: Technical Section: C.1

Original Text:

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

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

Corrected Text:

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

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

[jsalowey]

Errata ID: 5845 Fixed: section has been rewritten to remove ambiguity Errata Resolution:

Status: Hold For Document Update

[jsalowey]

Errata ID: 7145 Fixed: the new section contains the recommended text and other clarifications Errata Resolution:

Status: Hold For Document Update or Verified (section was rewritten to make it clearer) Type: Technical Section: 3.3.1

Original Text:

The Crypto-Binding TLV MUST be exchanged and verified before the final Result TLV exchange, regardless of whether or not there is an inner EAP method authentication.

Corrected Text:

Except as noted below, the Crypto-Binding TLV MUST be exchanged and verified before the final Result TLV exchange, regardless of whether or not there is an inner EAP method authentication

[jsalowey]

Errata ID: 7259 Fixed: a new section was created for EAP-MSCHAPv2

Errata Resolution:

Status: Hold For Document Update or Verified (new section created and existing section was rewritten to make it clearer) Type: Technical Section: 3.3.2

Original Text:

The use of EAP-FAST-GTC as defined in RFC 5421 [RFC5421] is NOT RECOMMENDED with TEAPv1 because EAP-FAST-GTC is not compliant with EAP-GTC defined in [RFC3748]. Implementations should instead make use of the password authentication TLVs defined in this specification. The authentication server initiates password authentication by sending a Basic-Password-Auth-Req TLV defined in Section 4.2.14. If the peer wishes to participate in password authentication, then it responds with a Basic-Password-Auth-Resp TLV as defined in Section 4.2.15 that contains the username and password. If it does not wish to perform password authentication, then it responds with a NAK TLV indicating the rejection of the Basic- Password-Auth-Req TLV. Upon receiving the response, the server indicates the success or failure of the exchange using an Intermediate-Result TLV. Multiple round trips of password authentication requests and responses MAY be used to support some "housecleaning" functions such as a password or pin change before a user is authenticated.

Corrected Text:

The use of EAP-FAST-GTC as defined in RFC 5421 [RFC5421] is NOT RECOMMENDED with TEAPv1 because EAP-FAST-GTC is not compliant with EAP-GTC defined in [RFC3748]. Implementations should instead make use of the password authentication TLVs defined in this specification. The authentication server initiates password authentication by sending a Basic-Password-Auth-Req TLV defined in Section 4.2.14. If the peer wishes to participate in password authentication, then it responds with a Basic-Password-Auth-Resp TLV as defined in Section 4.2.15 that contains the username and password. If it does not wish to perform password authentication, then it responds with a NAK TLV indicating the rejection of the Basic- Password-Auth-Req TLV. Upon receiving the response, the server indicates the success or failure of the exchange using an Intermediate-Result TLV. Multiple round trips of password authentication requests and responses MAY be used to support some "housecleaning" functions such as a password or pin change before a user is authenticated.

If using EAP-MSCHAPv2 as an inner method, the EAP-FAST-MSCHAPv2 variant defined in [RFC5422] MUST be used.