From 0fb3c8b2ccdd4b348ea0961634883a3b418a0912 Mon Sep 17 00:00:00 2001 From: Alexander Clouter Date: Thu, 19 Mar 2026 09:35:30 +0000 Subject: [PATCH 1/3] ws --- draft-dekok-emu-teapv2.md | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/draft-dekok-emu-teapv2.md b/draft-dekok-emu-teapv2.md index a13d8a6..e6864db 100644 --- a/draft-dekok-emu-teapv2.md +++ b/draft-dekok-emu-teapv2.md @@ -52,7 +52,7 @@ Tunnel Extensible Authentication Protocol (TEAP) version 1 was first defined in {{?RFC7170}}. However, implementations of that specification were found to have limited interoperability, due to the complexity of the design, and to under-specification of the -cryptographic key deriviations that it defined. +cryptographic key derivations that it defined. TEAPv1 was updated and clarified in {{I-D.ietf-emu-rfc7170bis}}. That document described a large amount of potential functionality in the @@ -63,7 +63,7 @@ which could potentially allow on-path attackers control control over the data being transported inside of the TLS tunnel. We do not review the full security issues with TEAPv1 here. Instead, -we define TEAPv2, with new and simpler cryptographic key deriviations. +we define TEAPv2, with new and simpler cryptographic key derivations. These derivations address all of the known issues with TEAPv1. NOTE: For simplicity, this current draft defines TEAPv2 as a delta @@ -95,7 +95,7 @@ calculation had significant differences between independent implementations. These differences were due to complex derivations of multiple intermediate keys, some of which were defined ambiguously. This complexity and lack of clarity lead to interoperability problems. -TEAPv2 simplifies the key deriviations, reduces the number of +TEAPv2 simplifies the key derivations, reduces the number of intermediate keys, and gives smaller (and hopefully clearer) definitions for the derivations. @@ -166,12 +166,12 @@ inner methods will provide an MSK or an EMSK. TEAPv2 uses the Crypto-Binding TLV to protect both parties from the attacks outlined in {{RFC6677}}. As those attacks are only possible when the inner method is EAP, TEAPv2 defines key derivations only when -then inner method is EAP. TEAPv2 does not define key deriviations or +then inner method is EAP. TEAPv2 does not define key derivations or use the Crypto-Binding TLV for other inner method exchanges. -The key deriviations described below MUST be done when the inner +The key derivations described below MUST be done when the inner method is EAP (i.e. when the parties exchange EAP-Payload TLVs). The -key deriviations described below MUST NOT be done when the inner +key derivations described below MUST NOT be done when the inner method is anything other than EAP (i.e. when the inner method does not include EAP-Payload TLVs). @@ -215,7 +215,7 @@ generated from the final round seed ([](#master-key)). ### Intermediate Key Seeding {#key-seeding} -The intermediate compound key deriviations for TEAPv2 depend on the +The intermediate compound key derivations for TEAPv2 depend on the following RoundSeed structure. The RoundSeed structure is defined using the same syntax as is used for TLS {{RFC8446}}: @@ -380,7 +380,7 @@ Section 3}} defines a maximum RADIUS packet length of 4096 octets. This limit can therefore be in conflict with different local network limits seen by the EAP peer. -As a result, TEAPv2 mandates a maximum MTU. TEAPv2 impementations are +As a result, TEAPv2 mandates a maximum MTU. TEAPv2 implementations are limited to sending EAP packets which are no larger than 1280 octets in size. That is, the EAP packet Length field ({{RFC3748, Section 4}}) MUST contain a value which is no larger than 1280. From 30c2c8888288bf0001a13e27c82b6ac9205c74d6 Mon Sep 17 00:00:00 2001 From: Alexander Clouter Date: Thu, 19 Mar 2026 09:51:07 +0000 Subject: [PATCH 2/3] RFC9930 published, update references --- draft-dekok-emu-teapv2.md | 34 +++++++++++++++++----------------- 1 file changed, 17 insertions(+), 17 deletions(-) diff --git a/draft-dekok-emu-teapv2.md b/draft-dekok-emu-teapv2.md index e6864db..35f2c33 100644 --- a/draft-dekok-emu-teapv2.md +++ b/draft-dekok-emu-teapv2.md @@ -27,7 +27,7 @@ normative: RFC3748: RFC8174: RFC8446: - I-D.ietf-emu-rfc7170bis: + RFC9930: informative: RFC6677: @@ -42,7 +42,7 @@ venue: This document defines the Tunnel Extensible Authentication Protocol (TEAP) version 2. It addresses a number of security and interoperability issues which were found during the publication of -TEAPv1 ({{I-D.ietf-emu-rfc7170bis}}). +TEAPv1 ({{RFC9930}}). --- middle @@ -54,9 +54,9 @@ specification were found to have limited interoperability, due to the complexity of the design, and to under-specification of the cryptographic key derivations that it defined. -TEAPv1 was updated and clarified in {{I-D.ietf-emu-rfc7170bis}}. That +TEAPv1 was updated and clarified in {{RFC9930}}. That document described a large amount of potential functionality in the -protocol, but also noted in {{I-D.ietf-emu-rfc7170bis, Section 5.1}} +protocol, but also noted in {{RFC9930, Section 5.1}} that only a small subset of that functionality was interoperable. In addition, the interoperable parts of the protocol had security issues which could potentially allow on-path attackers control control over @@ -76,11 +76,11 @@ TEAPv1 document. Most parts of TEAPv1 are unchanged. The message and TLV formats are the same, as are the derivations for the session_key_seed -({{I-D.ietf-emu-rfc7170bis, Section 6.1}}). The derivations for the +({{RFC9930, Section 6.1}}). The derivations for the Master Session Key (MSK) and the Extended Master Session Key (EMSK) -({{I-D.ietf-emu-rfc7170bis, Section 6.4}}) have had only minor changes. +({{RFC9930, Section 6.4}}) have had only minor changes. -The Crypto-Binding TLV {{I-D.ietf-emu-rfc7170bis, Section 4.2.13}} has +The Crypto-Binding TLV {{RFC9930, Section 4.2.13}} has the same format as for TEAPv1, although its value is now calculated via a different derivation. The Crypto-Binding TLV is now used only when the inner exchange is an EAP authentication method. @@ -105,11 +105,11 @@ operations. ## Outline of this Document This document largely follows the same outline as -{{I-D.ietf-emu-rfc7170bis}}. Where changes from that document are +{{RFC9930}}. Where changes from that document are made, the same section titles are used in order to ensure easy comparison of the documents. New sections are added, with new titles. For parts of TEAP which are not mentioned herein, this document makes -no changes from {{I-D.ietf-emu-rfc7170bis}}. +no changes from {{RFC9930}}. ## Specification Requirements @@ -129,13 +129,13 @@ Round > > A round can include multiple inner message exchanges, e.g. EAP-TLS. > -> This term was used in {{I-D.ietf-emu-rfc7170bis}}, but was not +> This term was used in {{RFC9930}}, but was not > defined in that document. # Negotiation TEAPv2 uses the same version negotiation method as is defined in -{{I-D.ietf-emu-rfc7170bis, Section 3.1}}, with the Version field set +{{RFC9930, Section 3.1}}, with the Version field set to two (2) for TEAPv2. TEAPv2 MUST use TLS 1.3 or later. TEAPv2 MUST NOT use TLS-PSK. @@ -143,13 +143,13 @@ TEAPv2 MUST use TLS 1.3 or later. TEAPv2 MUST NOT use TLS-PSK. # Cryptographic Calculations The crytographic calculations for TEAPv2 have been substantially -simplified from those defined in {{I-D.ietf-emu-rfc7170bis, Section +simplified from those defined in {{RFC9930, Section 6}}. ## TEAP Authentication Phase 1: Key Derivations {#key-derivations} The session key seed is the same as defined in -{{I-D.ietf-emu-rfc7170bis, Section 6.2.1}} for TEAPv2. That +{{RFC9930, Section 6.2.1}} for TEAPv2. That definition is reproduced here verbatim: ~~~~ @@ -337,7 +337,7 @@ method as for TEAPv1. That definition is reproduced here verbatim: CMK is taken from the DerivedKey structure which was calculated for this round. The definition of BUFFER is the same as in -{{I-D.ietf-emu-rfc7170bis, Section 6.3}} for TEAPv1. +{{RFC9930, Section 6.3}} for TEAPv1. For TEAPv2, only one CMK is derived for each inner message. This limitation also means that only one Compound-MAC is derived for the @@ -392,19 +392,19 @@ message exchanges. ## TEAPv2 Message Format The TEAPv2 message format is identical to that of TEAPv1 -({{I-D.ietf-emu-rfc7170bis, Section 4.1}}) with only one change: the +({{RFC9930, Section 4.1}}) with only one change: the Ver field is set to "2", to indicate that this is TEAPv2. ## TEAPv2 TLVs The TEAPv2 TLV format and TLV definitions are identical to that for -TEAPv1 ({{I-D.ietf-emu-rfc7170bis, Section 4.2}}), with only the +TEAPv1 ({{RFC9930, Section 4.2}}), with only the changes and additions noted below. ### Crypto-Binding TLV {#crypto-binding} The format of the TEAPv2 Crypto-Binding TLV is the same as for TEAPv1 -({{I-D.ietf-emu-rfc7170bis, Section 4.2.13}}), with the following +({{RFC9930, Section 4.2.13}}), with the following changes: * The Version field MUST set to two (2). From ea9d48b2d02933b6170d719b09b6826853ad0b5e Mon Sep 17 00:00:00 2001 From: Alexander Clouter Date: Thu, 19 Mar 2026 09:57:28 +0000 Subject: [PATCH 3/3] Fragment-MTU TLV --- draft-dekok-emu-teapv2.md | 82 ++++++++++++++++++++++++++++++++++++++- 1 file changed, 81 insertions(+), 1 deletion(-) diff --git a/draft-dekok-emu-teapv2.md b/draft-dekok-emu-teapv2.md index 35f2c33..eade038 100644 --- a/draft-dekok-emu-teapv2.md +++ b/draft-dekok-emu-teapv2.md @@ -363,7 +363,7 @@ derivation than was done for TEAPv1. The following sections describe the message formats used in TEAPv2. The fields are transmitted from left to right in network byte order. -## EAP MTU +## EAP MTU {#eap-mtu} {{RFC3748, Section 3.1}} defines a minimum EAP MTU of 1020 octets. However, it defines no maximum MTU, {{RFC3748}} also provides no way @@ -422,6 +422,86 @@ changes: * The MSK Compound-MAC field is calculated as described above in [](#computing-compound-mac). +### Fragment-MTU TLV {#fragment-mtu-tlv} + +The Fragment-MTU TLV allows an EAP peer to indicate its preference of +MTU to use for the EAP fragments it will receive. + +The value MUST reflect any overhead in the transport used by EAP, +such as EAPOL and RADIUS/EAP-Message, and as such MUST be lower +than the local link MTU of the peer. + +Values lower than 200 bytes are ignored and treated as if 200 was provided. + +Values above 1280 are ignored as per the guidance in []{#eap-mtu} and treated +as if 1280 was provided. + +For example, RADIUS sent over a 1500 MTU link has an overhead of at least +twenty (20) bytes for the RADIUS header, eight (8) bytes for the UDP header, + and twenty (20) for either IPv4 or forty (40) bytes for IPv6. For this the +value of Fragment-MTU MUST be no larger than 1432 and is RECOMMENDED to be +at least one hundred (100) bytes smaller to cater for additional RADIUS +attributes and any tunneling transports. The leaves a value of 1332 which +is higher than 1280 which is the maximum MTU which would make the +Fragment-MTU TLV superfluous and SHOULD not be sent. + +For RADIUS transports, there are two use cases: + + * Home servers can determine if the RADIUS packet was received fragmented + and respond with a smaller Fragment-MTU TLV for the originating peer to + use. + + * Proxy servers forwarding EAP responses can determine if the RADIUS packet + was received fragmented and update the RADIUS request to reflect a + reduced value of Framed-MTU as described by {{RFC2869, Section 2.3.3}}. + +The value of Fragment-MTU MUST be the smallest of the value received by the +peer and any locally determined value either decided by the administrator or +learned from an out-of-bound source such as the RADIUS/Framed-MTU attribute. +Chosen the smallest value guards against differing link layer MTU that may +occur due to asymmetric routing of the encapsulating transport such as +RADIUS. + +Upon a peer receiving a Fragment-MTU TLV, it MUST send EAP fragments no +larger than the value proposed. + +The Fragment-MTU TLV MAY appear as an Outer TLV to assist administrators. + +The Fragment-MTU TLV is defined as follows: + +~~~~ + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +|M|R| TLV Type | Length | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +| Fragment MTU | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +~~~~ + +M + +> Mandatory, set to zero (0) + +R + +> Reserved, set to zero (0) + +TLV Type + +> 20 - Fragment-MTU + +Length + +> 2 + +Fragment MTU + +> The MTU field is two octets and reflects the preference of the peer +> for the maximum fragment size to use. +> +> Values above 1280 are ignored. + # Security Considerations # IANA Considerations