1. Introduction

Dieser Abschnitt bewahrt den RFC-Text fuer TEAPv1, einschliesslich TLS tunnel establishment, tunneled authentication, TLV formats, cryptographic calculations, IANA registries, security considerations und examples.

1.  Introduction

   A tunnel-based Extensible Authentication Protocol (EAP) method is an
   EAP method that establishes a secure tunnel and executes other EAP
   methods under the protection of that secure tunnel.  A tunnel-based
   EAP method can be used in any lower-layer protocol that supports EAP
   authentication.  There are several existing tunnel-based EAP methods
   that use Transport Layer Security (TLS) [RFC8446] to establish the
   secure tunnel.  EAP methods supporting this include Protected EAP
   (PEAP) [PEAP], EAP Tunneled Transport Layer Security (EAP-TTLS)
   [RFC5281], and EAP Flexible Authentication via Secure Tunneling (EAP-
   FAST) [RFC4851].  However, they all are either vendor-specific or
   informational, and the industry calls for a Standards Track tunnel-
   based EAP method.  [RFC6678] outlines the list of requirements for a
   standard tunnel-based EAP method.

   This document describes the Tunnel Extensible Authentication Protocol
   (TEAP) version 1, which is based on EAP-FAST [RFC4851].  The changes
   from EAP-FAST to TEAP are largely minor in order to meet the
   requirements outlined in [RFC6678] for a standard tunnel-based EAP
   method.

   This document also defines cryptographic derivations for use with TLS
   1.2.  When TLS 1.3 is used, the definitions of cryptographic
   derivations in [RFC9427] MUST be used instead of the ones given here.

   Note that while it is technically possible to use TEAPv1 with TLS 1.0
   and TLS 1.1, those protocols have been deprecated in [RFC8996].  As
   such, the definitions given here are only applicable for TLS 1.2 and
   TLS 1.3.

1.1.  Interoperability Issues

   This document contains substantial changes from [RFC7170].  These
   changes are largely clarifications and corrections to that
   specification.

   However, there is one major change from [RFC7170] in the
   specification of the cryptographic-binding information.  While there
   were multiple implementations of [RFC7170], the text in that document
   was interpreted differently by each implementation.  The
   implementations are interoperable, but only for a subset of the
   functionalities described in [RFC7170].

   This specification describes how TEAPv1 works in theory but also
   explains what subset of TEAPv1 is currently interoperable.  In order
   to simplify the description of an already complex specification, all
   interoperability issues are documented separately from the normal
   protocol operation.

   Please see Section 5 for further discussion of interoperability
   issues.

1.2.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

1.3.  Terminology

   Much of the terminology in this document comes from [RFC3748].
   Additional terms are defined below:

   Type-Length-Value (TLV)
      The TEAP utilizes objects in TLV format.  The TLV format is
      defined in Section 4.2.

   Inner Method
      An authentication method that is sent as application data inside
      of a TLS exchange that is carried over TEAP.  The Inner Method can
      be an EAP authentication method, a username/password
      authentication, or a vendor-specific authentication method.  Where
      the TLS connection is authenticated, the Inner Method could also
      be a Public Key Cryptography Standard (PKCS) exchange.