Appendix A. Evaluation Against Tunnel-Based EAP Method Requirements
This section preserves the RFC text for TEAPv1, including TLS tunnel establishment, tunneled authentication, TLV formats, cryptographic calculations, IANA registries, security considerations, and examples.
Appendix A. Evaluation Against Tunnel-Based EAP Method Requirements
This section evaluates all tunnel-based EAP method requirements
described in [RFC6678] against TEAP version 1.
A.1. Requirement 4.1.1: RFC Compliance
TEAPv1 meets this requirement by being compliant with [RFC3748],
[RFC4017], [RFC5247], and [RFC4962]. It is also compliant with the
"cryptographic algorithm agility" requirement by leveraging TLS 1.2
for all cryptographic algorithm negotiation.
A.2. Requirement 4.2.1: TLS Requirements
TEAPv1 meets this requirement by mandating TLS version 1.2 support as
defined in Section 3.2.
A.3. Requirement 4.2.1.1.1: Cipher Suite Negotiation
TEAPv1 meets this requirement by using TLS to provide protected
cipher suite negotiation.
A.4. Requirement 4.2.1.1.2: Tunnel Data Protection Algorithms
TEAPv1 meets this requirement by mandating cipher suites as defined
in Section 3.2.
A.5. Requirement 4.2.1.1.3: Tunnel Authentication and Key Establishment
TEAPv1 meets this requirement by mandating cipher suites that only
include cipher suites that use strong cryptographic algorithms. They
do not include cipher suites providing mutually anonymous
authentication or static Diffie-Hellman cipher suites as defined in
Section 3.2.
A.6. Requirement 4.2.1.2: Tunnel Replay Protection
TEAPv1 meets this requirement by using TLS to provide sufficient
replay protection.
A.7. Requirement 4.2.1.3: TLS Extensions
TEAPv1 meets this requirement by allowing TLS extensions, such as TLS
Certificate Status Request extension [RFC6066] and SessionTicket
extension [RFC5077], to be used during TLS tunnel establishment.
A.8. Requirement 4.2.1.4: Peer Identity Privacy
TEAPv1 meets this requirement by establishment of the TLS tunnel and
protection identities specific to the Inner Method. In addition, the
peer certificate can be sent confidentially (i.e., encrypted).
A.9. Requirement 4.2.1.5: Session Resumption
TEAPv1 meets this requirement by mandating support of TLS session
resumption as defined in Section 3.5.1 and TLS session resumption
using the methods defined in [RFC9190].
A.10. Requirement 4.2.2: Fragmentation
TEAPv1 meets this requirement by leveraging fragmentation support
provided by TLS as defined in Section 3.10.
A.11. Requirement 4.2.3: Protection of Data External to Tunnel
TEAPv1 meets this requirement by including the TEAP version number
received in the computation of the Crypto-Binding TLV as defined in
Section 4.2.13.
A.12. Requirement 4.3.1: Extensible Attribute Types
TEAPv1 meets this requirement by using an extensible TLV data layer
inside the tunnel as defined in Section 4.2.
A.13. Requirement 4.3.2: Request/Challenge Response Operation
TEAPv1 meets this requirement by allowing multiple TLVs to be sent in
a single EAP request or response packet, while maintaining the half-
duplex operation typical of EAP.
A.14. Requirement 4.3.3: Indicating Criticality of Attributes
TEAPv1 meets this requirement by having a mandatory bit in each TLV
to indicate whether it is mandatory to support or not as defined in
Section 4.2.
A.15. Requirement 4.3.4: Vendor-Specific Support
TEAPv1 meets this requirement by having a Vendor-Specific TLV to
allow vendors to define their own attributes as defined in
Section 4.2.8.
A.16. Requirement 4.3.5: Result Indication
TEAPv1 meets this requirement by having a Result TLV to exchange the
final result of the TEAP authentication so both the peer and server
have a synchronized state as defined in Section 4.2.4.
A.17. Requirement 4.3.6: Internationalization of Display Strings
TEAPv1 meets this requirement by supporting UTF-8 format in the
Basic-Password-Auth-Req TLV as defined in Section 4.2.14 and the
Basic-Password-Auth-Resp TLV as defined in Section 4.2.15.
A.18. Requirement 4.4: EAP Channel-Binding Requirements
TEAPv1 meets this requirement by having a Channel-Binding TLV to
exchange the EAP channel-binding data as defined in Section 4.2.7.
A.19. Requirement 4.5.1.1: Confidentiality and Integrity
TEAPv1 meets this requirement by running the password authentication
inside a protected TLS tunnel.
A.20. Requirement 4.5.1.2: Authentication of Server
TEAPv1 meets this requirement by mandating authentication of the
server before establishment of the protected TLS and then running
inner password authentication as defined in Section 3.2.
A.21. Requirement 4.5.1.3: Server Certificate Revocation Checking
TEAPv1 meets this requirement by supporting TLS Certificate Status
Request extension [RFC6066] during tunnel establishment.
A.22. Requirement 4.5.2: Internationalization
TEAPv1 meets this requirement by supporting UTF-8 format in Basic-
Password-Auth-Req TLV as defined in Section 4.2.14 and Basic-
Password-Auth-Resp TLV as defined in Section 4.2.15.
A.23. Requirement 4.5.3: Metadata
TEAPv1 meets this requirement by supporting Identity-Type TLV as
defined in Section 4.2.3 to indicate whether the authentication is
for a user or a machine.
A.24. Requirement 4.5.4: Password Change
TEAPv1 meets this requirement by supporting multiple Basic-Password-
Auth-Req TLV and Basic-Password-Auth-Resp TLV exchanges within a
single EAP authentication, which allows "housekeeping"" functions
such as password change.
A.25. Requirement 4.6.1: Method Negotiation
TEAPv1 meets this requirement by supporting inner EAP method
negotiation within the protected TLS tunnel.
A.26. Requirement 4.6.2: Chained Methods
TEAPv1 meets this requirement by supporting inner EAP method chaining
within protected TLS tunnels as defined in Section 3.6.2.
A.27. Requirement 4.6.3: Cryptographic Binding with the TLS Tunnel
TEAPv1 meets this requirement by supporting cryptographic binding of
the inner EAP method keys with the keys derived from the TLS tunnel
as defined in Section 4.2.13.
A.28. Requirement 4.6.4: Peer-Initiated EAP Authentication
TEAPv1 meets this requirement by supporting the Request-Action TLV as
defined in Section 4.2.9 to allow a peer to initiate another inner
EAP method.
A.29. Requirement 4.6.5: Method Metadata
TEAPv1 meets this requirement by supporting the Identity-Type TLV as
defined in Section 4.2.3 to indicate whether the authentication is
for a user or a machine.