RFC Errata
Found 10 records.
Status: Verified (10)
RFC 7170, "Tunnel Extensible Authentication Protocol (TEAP) Version 1", May 2014
Note: This RFC has been updated by RFC 9427
Source of RFC: emu (sec)
Errata ID: 5127
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Tuure Vartiainen
Date Reported: 2017-09-25
Verifier Name: Paul Wouters
Date Verified: 2024-04-01
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: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Tuure Vartiainen
Date Reported: 2017-09-25
Verifier Name: Paul Wouters
Date Verified: 2024-04-01
Section 5.2. says:
IMCK[j] = TLS-PRF(S-IMCK[j-1], "Inner Methods Compound Keys",
IMSK[j], 60)
It should say:
IMCK[j] = the first 60 octets of TLS-PRF(S-IMCK[j-1],
"Inner Methods Compound Keys",
IMSK[j])
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)"
Paul Wouters(AD): Corrected the text proposed by the original submitter, as it now appears in 7170bis
Errata ID: 5765
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Jouni Malinen
Date Reported: 2019-06-28
Verifier Name: Roman Danyliw
Date Verified: 2022-03-18
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: 5768
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Jouni Malinen
Date Reported: 2019-06-29
Verifier Name: Paul Wouters
Date Verified: 2024-04-01
Section 5. 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:
It should say:
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:
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).
Paul Wouters(AD): Corrected Text provided by the WG and in 7170bis
Errata ID: 5775
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Jouni Malinen
Date Reported: 2019-07-04
Verifier Name: Paul Wouters
Date Verified: 2024-04-01
Section 5. 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:
It should say:
[Append to the end of section 5.3] If no key generating inner 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 all zeroes (i.e., IMSK = MSK = 32 octets of 0x00s).
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.
Paul Wouters(AD): Corrected Text provided by the WG and in 7170bis
Errata ID: 5844
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Jouni Malinen
Date Reported: 2019-08-24
Verifier Name: Paul Wouters
Date Verified: 2024-04-01
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: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Jouni Malinen
Date Reported: 2019-08-24
Verifier Name: Paul Wouters
Date Verified: 2024-04-01
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.
Errata ID: 6157
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Eliot Lear
Date Reported: 2020-05-04
Verifier Name: Roman Danyliw
Date Verified: 2022-03-17
Section 4.2.9 says:
Status
The Status field is one octet. This indicates the result if the
server does not process the action requested by the peer.
It should say:
Status
The Status field is one octet. This indicates the result if the
party who receives this TLV does not process the action.
Notes:
The status field is carried in the "Request-Action" frame. As is stated at the start of the section, the frame can be sent either by the server or the peer.
Errata ID: 7145
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Eliot Lear
Date Reported: 2022-10-05
Verifier Name: Paul Wouters
Date Verified: 2024-04-01
Section 3.3.3 says:
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.
It should say:
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
Notes:
The text contradicts itself in the same paragraph, because it goes on to say:
The server may send the final Result TLV along with an
Intermediate-Result TLV and a Crypto-Binding TLV to indicate its
intention to end the conversation. If the peer requires nothing more
from the server, it will respond with a Result TLV indicating success
accompanied by a Crypto-Binding TLV and Intermediate-Result TLV if
necessary.
So there are actually several legal combinations here:
1. Server and peer perform a crypto-binding exchange in anticipation of later sending Result TLVs
2. The server and peer combine their crypto-binding and Result TLV in the same message.
3. One side initiates a crypto-binding TLV and the OTHER responds with both crypto-binding and Result TLV.
The practice seems to be to include the crypto-binding TLVs alongside Result TLVs.
Errata ID: 7259
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Jouni Malinen
Date Reported: 2022-12-01
Verifier Name: Paul Wouters
Date Verified: 2024-04-01
Section 3.3.2 says:
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.
It should say:
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.
Notes:
While RFC 7170 does not really require this and would be technically correct as-is for this area, deployed implementations of EAP-TEAP seem to have used MSK/IMSK derivation for an inner EAP method in a manner that matches what was done with EAP-FAST. This could be called non-compliant, but for the sake of interoperability, it might make more sense to describe what is done in deployed implementation instead. The only technical difference here is in swapping the first and the second 16 octets of EAP-MSCHAPv2 MSK when it is used as the IMSK for EAP-TEAP.