Network Working Group                                            G. Zorn
Internet-Draft                                               Network Zen
Intended status: Standards Track                                   Q. Wu
Expires: September 9, 2011                                        Huawei
                                                              D. Harkins
                                                          Aruba Networks
                                                           March 8, 2011


          The Tunneled Extensible Authentication Method (TEAM)
                         draft-zorn-emu-team-02

Abstract

   The Extensible Authentication Protocol (EAP) provides support for
   multiple authentication methods.  This document defines the Tunneled
   Extensible Authentication Method (TEAM), which provides an encrypted
   and authenticated tunnel based on transport layer security (TLS) that
   encapsulates EAP authentication mechanisms.  TEAM uses TLS to protect
   against rogue authenticators, protect against various attacks on the
   confidentiality and integrity of the inner EAP method exchange and
   provide EAP peer identity privacy.  TEAM also provides support for
   chaining multiple EAP mechanisms, cryptographic binding between
   authentications performed by inner EAP mechanisms and the tunnel,
   exchange of arbitrary parameters (TLVs), and fragmentation and
   reassembly.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.  This document may not be modified,
   and derivative works of it may not be created, except to format it
   for publication as an RFC or to translate it into languages other
   than English.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on September 9, 2011.

Copyright Notice



Zorn, et al.            Expires September 9, 2011               [Page 1]


Internet-Draft                    TEAM                        March 2011


   Copyright (c) 2011 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Requirements Language  . . . . . . . . . . . . . . . . . . . .  6
   3.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  6
   4.  Protocol Overview  . . . . . . . . . . . . . . . . . . . . . .  8
     4.1.  Operational Model  . . . . . . . . . . . . . . . . . . . .  8
     4.2.  Sequences  . . . . . . . . . . . . . . . . . . . . . . . . 10
     4.3.  TEAM Phase 1 . . . . . . . . . . . . . . . . . . . . . . . 10
       4.3.1.  Initial identity exchange  . . . . . . . . . . . . . . 10
       4.3.2.  TLS Session Establishment  . . . . . . . . . . . . . . 11
       4.3.3.  Session Resumption . . . . . . . . . . . . . . . . . . 13
       4.3.4.  Version Negotiation  . . . . . . . . . . . . . . . . . 14
     4.4.  TEAM Phase 2 . . . . . . . . . . . . . . . . . . . . . . . 15
       4.4.1.  Protected Conversation . . . . . . . . . . . . . . . . 15
       4.4.2.  Protected Termination  . . . . . . . . . . . . . . . . 18
       4.4.3.  Provisioning of Credentials  . . . . . . . . . . . . . 19
     4.5.  Error Handling . . . . . . . . . . . . . . . . . . . . . . 21
     4.6.  Fragmentation and Reassembly . . . . . . . . . . . . . . . 22
     4.7.  Key Derivation . . . . . . . . . . . . . . . . . . . . . . 24
       4.7.1.  Compound Session Key Derivation  . . . . . . . . . . . 25
     4.8.  Ciphersuite Negotiation  . . . . . . . . . . . . . . . . . 26
   5.  TEAM Protocol Description  . . . . . . . . . . . . . . . . . . 26
     5.1.  TEAM Protocol Layers . . . . . . . . . . . . . . . . . . . 26
     5.2.  TEAM Packet Format . . . . . . . . . . . . . . . . . . . . 27
   6.  Type-Length-Value Tuples . . . . . . . . . . . . . . . . . . . 29
     6.1.  TLV Format . . . . . . . . . . . . . . . . . . . . . . . . 30
     6.2.  Result TLV . . . . . . . . . . . . . . . . . . . . . . . . 31
     6.3.  NAK TLV  . . . . . . . . . . . . . . . . . . . . . . . . . 32
     6.4.  Error-Code TLV . . . . . . . . . . . . . . . . . . . . . . 33
     6.5.  Crypto-Binding TLV . . . . . . . . . . . . . . . . . . . . 34
     6.6.  Connection-Binding TLV . . . . . . . . . . . . . . . . . . 36
     6.7.  Vendor-Specific TLV  . . . . . . . . . . . . . . . . . . . 38
     6.8.  URI TLV  . . . . . . . . . . . . . . . . . . . . . . . . . 39
     6.9.  EAP-Payload TLV  . . . . . . . . . . . . . . . . . . . . . 40



Zorn, et al.            Expires September 9, 2011               [Page 2]


Internet-Draft                    TEAM                        March 2011


     6.10. Intermediate-Result TLV  . . . . . . . . . . . . . . . . . 41
     6.11. Calling-Station-Id TLV . . . . . . . . . . . . . . . . . . 42
     6.12. Called-Station-Id TLV  . . . . . . . . . . . . . . . . . . 43
     6.13. NAS-Port-Type TLV  . . . . . . . . . . . . . . . . . . . . 45
     6.14. Server-Identifier TLV  . . . . . . . . . . . . . . . . . . 46
     6.15. Identity-Type TLV  . . . . . . . . . . . . . . . . . . . . 47
     6.16. Server-Trusted-Root TLV  . . . . . . . . . . . . . . . . . 48
     6.17. PKCS#7 TLV . . . . . . . . . . . . . . . . . . . . . . . . 49
     6.18. Request-Action-TLV . . . . . . . . . . . . . . . . . . . . 50
     6.19. TLV Rules  . . . . . . . . . . . . . . . . . . . . . . . . 51
       6.19.1. Outer TLVs . . . . . . . . . . . . . . . . . . . . . . 52
       6.19.2. Inner TLVs . . . . . . . . . . . . . . . . . . . . . . 53
       6.19.3. EAP-Payload TLV  . . . . . . . . . . . . . . . . . . . 54
       6.19.4. Connection-Binding TLV . . . . . . . . . . . . . . . . 54
       6.19.5. Server-Trusted-Root TLV  . . . . . . . . . . . . . . . 54
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 55
     7.1.  Authentication and Integrity Protection  . . . . . . . . . 55
     7.2.  Method Negotiation . . . . . . . . . . . . . . . . . . . . 55
     7.3.  TLS Session Cache Handling . . . . . . . . . . . . . . . . 56
     7.4.  Certificate Revocation . . . . . . . . . . . . . . . . . . 57
     7.5.  Separation of EAP Server and Authenticator . . . . . . . . 58
     7.6.  Separation of TEAM Phase 1 and 2 Servers . . . . . . . . . 58
     7.7.  Identity Verification  . . . . . . . . . . . . . . . . . . 60
     7.8.  Man-in-the-Middle Attack Protection  . . . . . . . . . . . 61
     7.9.  Cleartext Forgeries  . . . . . . . . . . . . . . . . . . . 62
     7.10. TLS Ciphersuites . . . . . . . . . . . . . . . . . . . . . 63
     7.11. Denial of Service Attacks  . . . . . . . . . . . . . . . . 63
     7.12. Server Unauthenticated Tunnel Provisioning Mode  . . . . . 64
     7.13. Security Claims  . . . . . . . . . . . . . . . . . . . . . 65
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 66
     8.1.  EAP Type . . . . . . . . . . . . . . . . . . . . . . . . . 67
     8.2.  TLV Types  . . . . . . . . . . . . . . . . . . . . . . . . 67
     8.3.  TLV Values . . . . . . . . . . . . . . . . . . . . . . . . 67
   9.  Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 67
   10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 68
   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 68
     11.1. Normative References . . . . . . . . . . . . . . . . . . . 68
     11.2. Informative References . . . . . . . . . . . . . . . . . . 69
   Appendix A.  Compliance with Requirements for a Tunnel Based
                EAP Method  . . . . . . . . . . . . . . . . . . . . . 71
     A.1.  General Requirements . . . . . . . . . . . . . . . . . . . 71
     A.2.  Tunnel Requirements  . . . . . . . . . . . . . . . . . . . 71
     A.3.  Tunnel Payload Requirements  . . . . . . . . . . . . . . . 72
     A.4.  Channel Binding Requirements . . . . . . . . . . . . . . . 72
     A.5.  Username/Password Requirements . . . . . . . . . . . . . . 72
     A.6.  Requirements Around Carriage of EAP Methods  . . . . . . . 73





Zorn, et al.            Expires September 9, 2011               [Page 3]


Internet-Draft                    TEAM                        March 2011


1.  Introduction

   The Extensible Authentication Protocol (EAP), defined in [RFC3748],
   provides support for multiple authentication methods.  EAP over PPP
   [RFC3748] is typically deployed with leased lines or modem
   connections.  [IEEE.802-1X.2004] defines EAP over IEEE 802 local area
   networks (EAPOL).

   Since its initial development, a number of weaknesses in the EAP
   framework have become apparent.  These include lack of support for:

      Identity protection
      Protected method negotiation
      Protected notification messages
      Protected termination messages
      Sequences of EAP methods
      Fragmentation and reassembly
      Exchange of arbitrary parameters in a secure channel
      Optimized re-authentication

   In addition, some EAP methods lack the following features:

      Mutual authentication
      Resistance to dictionary attacks
      Adequate key generation

   By wrapping the EAP protocol within TLS, TEAM addresses deficiencies
   in EAP or EAP methods.  Benefits of TEAM include:

   Identity protection
      By encrypting the identity exchange, and allowing client identity
      to be provided after negotiation of the TLS channel, TEAM provides
      for identity protection.

   Dictionary attack resistance
      By conducting the EAP conversation within a TLS channel, TEAM
      protects EAP methods that might be subject to an offline
      dictionary attack were they to be conducted in the clear.

   Protected negotiation
      Since within TEAM, the EAP conversation is authenticated,
      integrity and replay protected on a per-packet basis, the EAP
      method negotiation that occurs within TEAM is protected, as are
      error messages sent within the TLS channel (TLS alerts or EAP
      Notification packets).  EAP negotiation outside of TEAM is not
      protected.





Zorn, et al.            Expires September 9, 2011               [Page 4]


Internet-Draft                    TEAM                        March 2011


   Header protection
      Within TEAM, TLS provides per-packet encryption, authentication,
      integrity and replay protection for the EAP conversation.  As a
      result, the Type-Data field within TEAM (including the EAP header
      of the EAP method within TEAM) is protected against modification.
      However, the EAP header of TEAM itself is not protected against
      modification, including the Code, Identifier and Type fields.

   Protected termination
      By sending success/failure indications within the TLS channel,
      TEAM provides support for protected termination of the EAP
      conversation.  This prevents an attacker from carrying out denial
      of service attacks by spoofing EAP Failure messages, or fooling
      the EAP peer into accepting a rogue NAS, by spoofing EAP Success
      messages.

   Fragmentation and Reassembly
      Since EAP does not include support for fragmentation and
      reassembly, individual methods need to include this capability.
      By including support for fragmentation and reassembly within TEAM,
      methods leveraging TEAM do not need to support this on their own.

   Fast reconnect
      Where EAP is used for authentication in wireless networks, the
      authentication latency is a concern.  As a result, it is valuable
      to be able to do a quick re-authentication on roaming between
      access points.  TEAM supports this capability by leveraging the
      TLS session resumption facility, and any EAP method running under
      TEAM can take advantage of it.

   Standard key establishment
      In order to provide keying material for a wide range of link layer
      ciphersuites, EAP methods need to provide keying material.  Key
      derivation is complex.  TEAM provides for key establishment by
      relying on the widely implemented and well-reviewed TLS [RFC5246]
      key derivation mechanism.  TEAM provides keying material for any
      EAP method running within it.

   Sequencing of multiple EAP methods
      In order to enhance security, TEAM implementations may choose to
      provide multi-factor authentication that validates different
      identities (for example user and machine identities) and/or uses
      different credentials of the same or different identities of the
      peer (e.g. user password and machine cert).  TEAM provides a
      standard way to chain different types of authentication mechanisms
      supporting different types of credentials.





Zorn, et al.            Expires September 9, 2011               [Page 5]


Internet-Draft                    TEAM                        March 2011


   Protected exchange of arbitrary parameters
      Type-Length-Value (TLV) tuples provide a way to exchange arbitrary
      information between peer and EAP server within a secure channel.
      This information can include signaling parameters for the EAP
      protocol, provisioning parameters, media specific and environment
      specific data, and authorization parameters.  The advantage of
      using TEAM TLVs is that every EAP method does not have to be
      modified.

   Credential provisioning
      TEAM supports provisioning of certificate trust anchors by the
      server using TLVs and can be extended to support provisioning of
      other peer credentials.

   Optimized for light weight devices
      In order to support peers that may not support certificate
      ciphersuites, and may not support provisioning of certificate
      trust anchors, TEAM enables negotiation of other TLS ciphersuites.

   Server unauthenticated tunnel provisioning mode
      In some cases, the peer may only support password credentials and
      may not be provisioned with a certificate trust anchor.

      In server unauthenticated tunnel provisioning mode, a TEAM peer
      can authenticate using a password, in order to be provisioned with
      a pre-shared key and other credentials that can be used for
      subsequent authentication.  In server unauthenticated tunnel
      provisioning mode the TEAM peer does not authenticate the server.
      As a result, it is possible for an attacker to act as a man-in-
      the-middle during the initial exchange in order to attack the
      inner exchange.  For this reason, when performing server
      unauthenticated tunnel provisioning mode the inner method MUST be
      resistant to dictionary attack.

2.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

3.  Terminology

   This document frequently uses the following terms:








Zorn, et al.            Expires September 9, 2011               [Page 6]


Internet-Draft                    TEAM                        March 2011


   Access Point
      A Network Access Server implementing 802.11.

   Authenticator
      The end of the link initiating EAP authentication.  This term is
      also used in [IEEE.802-1X.2004]. and has the same meaning in this
      document.

   Backend Authentication Server
      A backend authentication server is an entity that provides an
      authentication service to an Authenticator.  When used, this
      server typically executes EAP methods for the Authenticator.  This
      terminology is also used in [IEEE.802-1X.2004].

   EAP server
      The entity that terminates the EAP authentication method with the
      peer.  In the case where no backend authentication server is used,
      the EAP server is part of the Authenticator.  In the case where
      the authenticator operates in pass-through mode, the EAP server is
      located on the backend authentication server.

   Link layer ciphersuite
      The ciphersuite negotiated for use at the link layer.

   NAS
      Short for "Network Access Server".

   Peer
      The end of the link that responds to the authenticator.  In
      [IEEE.802-1X.2004], this end is known as the Supplicant.

   TLS Ciphersuite
      The ciphersuite negotiated for protection of Phase 2 of the TEAM
      conversation Section 4.4.

   EAP Master key (MK)
      A key derived between the TEAM client and server during the
      authentication conversation, and that is kept local to TEAM and
      not exported or made available to a third party.

   Master Session Key (MSK)
      Keying material that is derived between the EAP peer and server
      and exported by the EAP method.  The MSK is at least 64 octets in
      length.  In existing implementations, a AAA server acting as an
      EAP server transports the MSK to the authenticator.






Zorn, et al.            Expires September 9, 2011               [Page 7]


Internet-Draft                    TEAM                        March 2011


   Extended Master Session Key (EMSK)
      Additional keying material derived between the EAP client and
      server that is exported by the EAP method.  The EMSK is at least
      64 octets in length.  The EMSK is not shared with the
      authenticator or any other third party.  The EMSK is reserved for
      future uses that are not defined yet.

   Type Length Value (TLV)
      The TEAM protocol utilizes objects in Type Length Value (TLV)
      format.  The TLV format is defined in Section 6.1 of this
      document.


4.  Protocol Overview

   TEAM is comprised of a two-part conversation:

   1.  In Phase 1 a TLS session is negotiated, with the server
       authenticating to the client and (optionally) the client to the
       server.  The negotiated key is then used to protect Phase 2 of
       the conversation.

   2.  In Phase 2, within the TLS session, zero or more EAP methods are
       carried out.  Phase 2 completes with a success/failure indication
       protected by the TLS session or a protected error (TLS alert).

   In the following sections, we discuss the TEAM operational model, its
   support for EAP method sequencing and provide an overview of each of
   the parts of the TEAM conversation.

4.1.  Operational Model

   In EAP, the EAP server may be implemented either within a Network
   Access Server (NAS) or on a backend authentication server.  Where the
   EAP server resides on a NAS, the NAS is required to implement the
   desired EAP methods, and therefore needs to be upgraded to support
   each new EAP method.

   One of the goals of EAP is to enable development of new
   authentication methods without requiring deployment of new code on
   the Network Access Server (NAS).  Where a backend authentication
   server is deployed, the NAS acts as a "passthrough" and need not
   understand specific EAP methods.

   This allows new EAP methods to be deployed on the EAP peer and
   backend authentication server, without the need to upgrade code
   residing on the NAS.




Zorn, et al.            Expires September 9, 2011               [Page 8]


Internet-Draft                    TEAM                        March 2011


   Figure 1 illustrates the relationship between the EAP peer, NAS and
   EAP server.  As shown in the figure, the EAP conversation occurs
   between the EAP peer and EAP server, "passing through" the NAS.  In
   order for the conversation to proceed in the case where the NAS and
   EAP server reside on separate machines, the NAS and EAP server need
   to establish trust beforehand.

         +-+-+-+-+-+               +-+-+-+-+-+
         |         |               |         |
         | Link    |               | Link    |
         | Layer   |               | Layer   |
         | Cipher- |               | Cipher- |
         | Suite   |               | Suite   |
         |         |               |         |
         +-+-+-+-+-+               +-+-+-+-+-+
             ^                         ^
             |                         |
             |                         |
             |                         |
             V                         V
         +-+-+-+-+-+               +-+-+-+-+-+  Trust +-+-+-+-+-+
         |         |  EAP          |         |<======>|         |
         |         |  Conversation |         |        |         |
         | EAP     |<================================>|  EAP    |
         | Peer    |  (over PPP,   |   NAS   |        |  Server |
         |         |  802.11,etc.) |         |<=======|         |
         |         |               |         |  Keys  |         |
         |         |               |         |        |         |
         +-+-+-+-+-+               +-+-+-+-+-+        +-+-+-+-+-+
             ^                                            ^
             |                                            |
             | EAP API                                    | EAP API
             |                                            |
             V                                            V
         +-+-+-+-+-+                                  +-+-+-+-+-+
         |         |                                  |         |
         |         |                                  |         |
         |  EAP    |                                  |  EAP    |
         |  Method |                                  |  Method |
         |         |                                  |         |
         +-+-+-+-+-+                                  +-+-+-+-+-+

     Figure 1: Relationship between EAP client, backend authentication
                              server and NAS

   In TEAM, the conversation between the EAP peer and the EAP server is
   encrypted, authenticated, integrity and replay protected within a TLS
   channel.



Zorn, et al.            Expires September 9, 2011               [Page 9]


Internet-Draft                    TEAM                        March 2011


   As a result, where the NAS acts as a "passthrough" it does not have
   knowledge of the TLS master secret derived between the peer and the
   EAP server.  In order to provide keying material for link-layer
   ciphersuites, the NAS obtains the master session key, which is
   derived from a one-way function of the TLS master secret as well as
   keying material provided by EAP methods protected within a TLS
   channel.  This enables the NAS and EAP peer to subsequently derive
   transient session keys suitable for encrypting, authenticating and
   integrity protecting session data.  However, the NAS cannot decrypt
   the TEAM conversation or spoof session resumption, since this
   requires knowledge of the TLS master secret.

4.2.  Sequences

   EAP [RFC3748] prohibits use of multiple authentication methods within
   a single EAP conversation, except when tunneled methods such as TEAM
   are used.  This restriction was imposed in order to limit
   vulnerabilities to man-in-the-middle attacks as well as to ensure
   compatibility with existing EAP implementations.

   Within TEAM these concerns are addressed since TEAM includes support
   for cryptographic binding to address man-in-the-middle attacks, as
   well as version negotiation so as to enable backward compatibility
   with future versions of the protocol.

   Within this document, the term "sequence" refers to a series of EAP
   authentication methods run in sequence or TLV exchanges before or
   after EAP methods.  The methods need not be distinct - for example,
   EAP-TLS could be run initially with machine credentials followed by
   the same protocol authenticating with user credentials.

   TEAM supports initiating additional EAP method(s) after a successful
   or a failed EAP method.  The result of failure of a EAP method does
   not always imply a failure of the overall authentication.  The
   overall result of authentication depends on the policy at EAP server
   and the peer.  For example, successful authentication might require a
   successful machine authentication followed by a successful user
   authentication.  Alternatively, if machine authentication fails, then
   user authentication can be attempted.  TEAM does not support
   initiating multiple EAP methods simultaneously.

4.3.  TEAM Phase 1

4.3.1.  Initial identity exchange

   The TEAM conversation typically begins with an optional identity
   exchange.  The authenticator will typically send an EAP-Request/
   Identity packet to the peer, and the peer will respond with an EAP-



Zorn, et al.            Expires September 9, 2011              [Page 10]


Internet-Draft                    TEAM                        March 2011


   Response/Identity packet to the authenticator.

   The initial identity exchange is used primarily to route the EAP
   conversation to the EAP server.  Since the initial identity exchange
   is in the clear, the peer MAY decide to place a routing realm instead
   of its real name in the EAP-Response/Identity.  The real identity of
   the peer can be established later, during Phase 2.

   If the EAP server is known in advance (such as when all users
   authenticate against the same backend server infrastructure and
   roaming is not supported), or if the identity is otherwise determined
   (such as from the dialing phone number or client MAC address), then
   the Identity exchange MAY be omitted.

   Once the optional initial Identity Request/Response exchange is
   completed, while nominally the EAP conversation occurs between the
   authenticator and the peer, the authenticator MAY act as a
   passthrough device, with the EAP packets received from the peer being
   encapsulated for transmission to a backend authentication server.
   However, TEAM does not require a backend authentication server; if
   the authenticator implements TEAM, then it can authenticate local
   users.

   In the discussion that follows, we will use the term "EAP server" to
   denote the ultimate endpoint conversing with the peer.

4.3.2.  TLS Session Establishment

   In this section, the protocol is described.  While this section will
   often describe negotiation of a certificate-based ciphersuite within
   TLS, TEAM supports negotiation of other ciphersuites (for example,
   ciphersuites that do not use certificates) or extensions.  However,
   the conversation may slightly differ if other TLS ciphersuites or
   extensions are used.

   Once having received the peer's identity, and determined that TEAM
   authentication is to occur, the EAP server MUST respond with a TEAM/
   Start packet, which is an EAP-Request packet with EAP-Type=TEAM, the
   Start (S) bit set, the TEAM version as specified in Section 4.3.4,
   and optionally, the Server-Identifier TLV (Section 6.14).

   Assuming that the peer supports TEAM, the TEAM conversation will then
   begin, with the peer sending an EAP-Response packet with EAP-
   Type=TEAM.  The Type-Data field of the EAP-Response Packet will
   encapsulate one or more TLS records containing the TLS handshake
   messages.  As defined in [RFC5246], the TLS handshake is used to
   negotiate parameters and cryptographic keys and may take several
   roundtrips between the TLS client and server.



Zorn, et al.            Expires September 9, 2011              [Page 11]


Internet-Draft                    TEAM                        March 2011


   The version offered by the TLS client and server MUST be TLS v1.0 or
   later.  TEAM implementations need not necessarily support all TLS
   ciphersuites listed in [RFC5246].  Not all TLS ciphersuites are
   supported by available TLS tool kits and licenses may be required in
   some cases.

   To ensure interoperability, TEAM peers and servers MUST support the
   TLS v1.1 [RFC5246] mandatory-to-implement ciphersuite:

      TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA

   In addition, TEAM servers SHOULD support and be able to negotiate all
   of the following TLS ciphersuites:

      TLS_RSA_WITH_3DES_EDE_CBC_SHA
      TLS_RSA_WITH_RC4_128_MD5
      TLS_RSA_WITH_RC4_128_SHA
      TLS_RSA_WITH_AES_128_CBC_SHA

   In addition, TEAM peers SHOULD support at least one of the following
   TLS ciphersuites:

      TLS_RSA_WITH_3DES_EDE_CBC_SHA
      TLS_RSA_WITH_RC4_128_MD5
      TLS_RSA_WITH_RC4_128_SHA
      TLS_RSA_WITH_AES_128_CBC_SHA

   TLS as described in [RFC5246] supports compression as well as
   ciphersuite negotiation.  Therefore during the TEAM Phase 1
   conversation the TEAM endpoints MAY request or negotiate TLS
   compression.

   If the full TLS handshake is performed, then the first payload of
   TEAM Phase 2 MAY be sent along with finished handshake message to
   reduce number of round trips.

   Since after the TLS session is established, another complete EAP
   negotiation will occur and the peer will authenticate using a
   secondary mechanism, with TEAM the client need not authenticate as
   part of TLS session establishment.

   Note that since TLS client certificates are sent in the clear, if
   identity protection is required, then it is possible for the TLS
   authentication to be re-negotiated after the first server
   authentication.  Alternatively, if identity protection is required,
   then it is possible to perform certificate authentication using a EAP
   method (for example: EAP-TLS [RFC5216]) within the TLS session during
   TEAM Phase 2.



Zorn, et al.            Expires September 9, 2011              [Page 12]


Internet-Draft                    TEAM                        March 2011


   To accomplish this, the server will typically not request a
   certificate in the server_hello, then after the server_finished
   message is sent, and before TEAM Phase 2 begins, the server MAY send
   a TLS hello_request.  This allows the client to perform client
   authentication by sending a client_hello if it wants to, or send a
   no_renegotiation alert to the server indicating that it wants to
   continue with TEAM Phase 2 instead.  Assuming that the client permits
   renegotiation by sending a client_hello, then the server will respond
   with server_hello, a certificate and certificate_request messages.
   The client replies with certificate, client_key_exchange and
   certificate_verify messages.  Since this re-negotiation occurs within
   the encrypted TLS channel, it does not reveal client certificate
   details.

4.3.3.  Session Resumption

   The purpose of the sessionId within the TLS protocol and the Server-
   Identifier TLV in TEAM is to allow for improved efficiency in the
   case where a client repeatedly attempts to authenticate to an EAP
   server within a short period of time.  This capability is
   particularly useful for support of wireless roaming.

   In order to help the peer choose a sessionID that belongs to the
   specific server, the EAP server MAY send an identifier (Server-
   Identifier TLV) that the peer can use as a hint.  The Server-
   Identifier TLV MAY be sent in the first TEAM packet from the EAP
   server to the peer.  In order to detect modification of the Server-
   Identifier TLV, the Server-Identifier TLV is included in calculation
   of the compound MAC.

   It is left up to the peer whether to attempt to continue a previous
   session, thus shortening the TEAM Phase 1 conversation.  Typically
   the peer's decision will be made based on the time elapsed since the
   previous authentication attempt to that EAP server.

   Based on the sessionId chosen by the peer, and the time elapsed since
   the previous authentication, the EAP server will decide whether to
   allow the continuation, or whether to choose a new session.

   If the EAP server is resuming a previously established session, then
   it MUST include only a TLS change_cipher_spec message and a TLS
   finished handshake message after the server_hello message.  The
   finished message contains the EAP server's authentication response to
   the peer.

   If the preceding server_hello message sent by the EAP server in the
   preceding EAP-Request packet indicated the resumption of a previous
   session, then the peer MUST send only the change_cipher_spec and



Zorn, et al.            Expires September 9, 2011              [Page 13]


Internet-Draft                    TEAM                        March 2011


   finished handshake messages.  The finished message contains the
   peer's authentication response to the EAP server.  The latter
   contains the EAP server's authentication response to the peer.  The
   peer will verify the hash in order to authenticate the EAP server.

   If authentication fails, then the peer and EAP server MUST follow the
   error handling behavior specified in Section 4.5

   Even if the session is successfully resumed with the same EAP server,
   the peer and EAP server MUST NOT assume that either will skip inner
   EAP methods.  The peer may have roamed to a network which may use the
   same EAP server, but may require conformance with a different
   authentication policy, and therefore may require inner EAP
   authentication methods.

4.3.4.  Version Negotiation

   TEAM packets contain a three bit version field, which enables TEAM
   implementations to be backward compatible with previous versions of
   the protocol.  This specification documents version1 of the TEAM
   protocol; implementations of this specification MUST use a version
   field set to 1.  Version negotiation proceeds as follows:

   1.  In the first EAP-Request sent with EAP-Type=TEAM, the EAP server
       MUST set the version field to the highest supported version
       number.

   2.  If the EAP peer supports that version of the protocol, it MUST
       respond with an EAP-Response of EAP-Type=TEAM, and the version
       number proposed by the EAP server.

   3.  If the EAP peer does not support that version, it responds with
       an EAP-Response of EAP-Type=TEAM and the highest supported
       version number.

   4.  If the TEAM server does not support the version number proposed
       by the TEAM peer, it either starts a different EAP type or
       terminates the conversation by sending an EAP-Failure, depending
       on the server policy.

   The version negotiation procedure guarantees that the EAP peer and
   server will agree to the latest version supported by both parties.
   If version negotiation fails, then use of TEAM will not be possible,
   and another mutually acceptable EAP method will need to be negotiated
   if authentication is to proceed.

   The TEAM version field is not protected by TLS and therefore can be
   modified in transit.  In order to detect modification of the TEAM



Zorn, et al.            Expires September 9, 2011              [Page 14]


Internet-Draft                    TEAM                        March 2011


   version which could occur as part of a "downgrade" attack, the peer
   and EAP server check if the version it sent during negotiation is
   same as the version claimed to be received by the other party.  Each
   party uses the Crypto-Binding TLV (Section 6.5) to inform the other
   party of the version number it received during the TEAM version
   negotiation.  The receiver of the Crypto-Binding TLV must verify that
   the version in the Crypto-Binding TLV matches the version it sent
   during TEAM version negotiation.

4.4.  TEAM Phase 2

   The second part of the TEAM conversation typically consists of a
   complete EAP conversation occurring within the TLS session negotiated
   in TEAM Phase 1, ending with protected termination using the Result
   TLV.  TEAM Phase 2 will occur only if establishment of a new TLS
   session in Phase 1 is successful or a TLS session is successfully
   resumed in Phase 1.  In cases where a new TLS session is established
   in TEAM Phase 1, the first payload of the Phase 2 conversation MAY be
   sent by the EAP server along with the finished message to save a
   round-trip.

   Phase 2 SHOULD NOT occur if the EAP Server authenticates
   unsuccessfully, and MUST NOT occur if establishment of the TLS
   session in Phase 1 was not successful or a TLS fatal error has been
   sent terminating the conversation.

   Since all packets sent within the TEAM Phase 2 conversation occur
   after TLS session establishment, they are protected using the
   negotiated TLS ciphersuite.  All EAP packets of the EAP conversation
   in Phase 2 including the EAP header of the inner EAP method are
   protected using the negotiated TLS ciphersuite.

   Phase 2 may not always include a EAP conversation within the TLS
   session, referred to in this document as inner EAP methods.  However,
   Phase 2 MUST always end with either protected termination or
   protected error termination (e.g.  TLS alert).

   Within Phase 2, protected EAP conversation and protected termination
   packets are always carried within TLVs.  There are TLVs defined for
   specific purposes such as carrying EAP-authentication messages and
   carrying cryptographic binding information.  New TLVs may be
   developed for other purposes.

4.4.1.  Protected Conversation

   Phase 2 of the TEAM conversation typically begins with the EAP server
   sending an optional EAP-Request/Identity packet to the peer,
   protected by the TLS ciphersuite negotiated in Phase 1 of TEAM.  The



Zorn, et al.            Expires September 9, 2011              [Page 15]


Internet-Draft                    TEAM                        March 2011


   peer responds with an EAP-Response/Identity packet to the EAP server,
   containing the peer's userId.  Since this Identity Request/Response
   exchange is protected by the ciphersuite negotiated in TLS, it is not
   vulnerable to snooping or packet modification attacks.

   After the TLS session-protected Identity exchange, the EAP server
   will then select authentication method(s) for the peer, and will send
   an EAP-Request with the Type field set to the initial method.  As
   described in [RFC3748], the peer can NAK the suggested EAP method,
   suggesting an alternative.  Since the NAK will be sent within the TLS
   channel, it is protected from snooping or packet modification.  As a
   result, an attacker snooping on the exchange will be unable to inject
   NAKs in order to "negotiate down" the authentication method.  An
   attacker will also not be able to determine which EAP method was
   negotiated.

   The EAP conversation within the TLS protected session may involve a
   sequence of zero or more EAP authentication methods; it completes
   with the protected termination described in Section 4.4.2 Several
   TLVs may be included in each Request and Response.  EAP packets are
   always encapsulated within EAP Payload TLVs.

   In a typical EAP conversation, the result of the conversation is
   communicated by sending EAP Success or EAP Failure packets after the
   EAP method is complete.  The EAP Success or Failure packet is
   considered the last packet of the EAP conversation; and therefore
   cannot be used when sequences need to be supported.  Hence, instead
   of using the EAP Success or EAP Failure packet, both peer and EAP
   server MUST use the Intermediate-Result TLV (Section 6.10) to
   communicate the result.

   In a typical EAP conversation, the EAP Success or EAP Failure is
   considered the last packet of the EAP conversation.  Within TEAM, the
   EAP server can start another EAP method after success or failure of
   the previous EAP method inside the protected session.

   In a sequence of more than one EAP authentication method, to make
   sure the same parties are involved in tunnel establishment and
   successful completion of previous inner EAP methods, before
   completing negotiation of the next EAP method, both peer and EAP
   server MUST use cryptographic binding (Crypto-Binding TLV
   Section 6.5).

   The Intermediate-Result TLV is used to indicate the result of a
   individual successful EAP method, and the Result TLV (Section 6.2) is
   used to indicate result of the entire TEAM conversation.

   The Intermediate-Result and Crypto-Binding TLVs MUST be sent after



Zorn, et al.            Expires September 9, 2011              [Page 16]


Internet-Draft                    TEAM                        March 2011


   each EAP method that was successful.  If the EAP method failed, or if
   the EAP method negotiation did not complete, then an Intermediate-
   Result TLV MAY be included, and the Crypto-Binding TLV MUST NOT be
   included.  An exception is that the Crypto-Binding TLV MUST be sent
   along with a protected success/failure indication (see
   Section 4.4.2).

   If these TLVs are not sent after a successful EAP method, it should
   be considered a tunnel compromise error by peer and EAP server,
   resulting in the termination of the conversation (as described in
   Section 4.5).

   A subsequent EAP conversation can be started after both TLVs are
   exchanged in a TLV packet.  Alternatively, if a subsequent EAP
   conversation is being attempted, then in order to reduce round trips,
   both TLVs SHOULD be sent with the EAP-Payload of the first EAP packet
   of the next EAP conversation (for example, EAP-Identity or EAP packet
   of the EAP method).  Alternatively, if the next packet is the
   protected success/failure packet, then in order to reduce round
   trips, both TLVs MUST be sent with the protected success/failure
   packet.

   If the EAP server sends a valid Crypto-Binding TLV to the peer, the
   peer MUST respond with a Crypto-Binding TLV.  If the Crypto-Binding
   TLV is invalid, it should be considered a tunnel compromise error by
   the peer.  If the peer does not respond with a TLV packet containing
   the Crypto-Binding TLV, it MUST be considered a tunnel compromise
   error by the EAP server.

   Within a TEAM part 2 conversation, a peer MAY request the trusted
   root of a server certificate using a Server-Trusted-Root TLV
   (Section 6.16), and the EAP server MAY respond with a Server-Trusted-
   Root TLV to the peer.  The Server-Trusted-Root TLV can be exchanged
   in regular authentication mode or server unauthenticated tunnel
   provisioning mode.

   After the peer has determined that it has successfully authenticated
   the EAP server and determined that the tunnel and inner EAP methods
   were between the same peer and EAP server by validating the Crypto-
   Binding TLV, it MAY send one or more Server-Trusted-Root TLVs (marked
   as optional) to request the trusted root of server certificate from
   the EAP server.  The peer may receive a response, but is not required
   to use the trusted root received from the EAP server.

   If the EAP server has determined that it has successfully
   authenticated the peer and determined that the tunnel and inner EAP
   methods were between the same peer and EAP server by validating the
   Crypto-Binding TLV, then it MAY respond with the the server-trusted-



Zorn, et al.            Expires September 9, 2011              [Page 17]


Internet-Draft                    TEAM                        March 2011


   root containing the PCKS#7 TLV (Section 6.17).

4.4.2.  Protected Termination

   Phase 2 of the TEAM conversation is completed by the exchange of
   success/failure indications (Result TLV) within a TLV packet
   protected by the TLS session.

   Even if Crypto-Binding TLVs have been exchanged in previous
   conversations, the Crypto-Binding TLV MUST be included in both
   protected success/failure (Result TLV) indications.  If the TLVs are
   not included, or if the TLVs are invalid, it should be considered a
   tunnel compromise error, and the peer and EAP server MUST follow the
   rules described in Section 4.5 to abort the conversation.

   The Result TLV is sent within the TLS channel.  The TEAM client then
   replies with a Result TLV.  The conversation concludes with the TEAM
   server sending a cleartext success/failure indication.

   The only outcome which should be considered as successful
   authentication is when a Result TLV of Status=Success is answered by
   the peer with a Result TLV of Status=Success.

   The combinations (Result TLV=Failure, Result TLV=Success), (Result
   TLV=Failure, Result TLV=Failure), (no TLVs exchange or no protected
   success or failure) should be considered an authentication failure by
   both the peer and EAP server.  Once the peer and EAP server consider
   that authentiation has failed, these are the last packets inside the
   protected tunnel.  These combinations are considered an
   authentication failure regardless of whether a cleartext EAP Success
   or EAP Failure packet is subsequently sent.

   If the EAP server wants authentication to fail, it sends the TLV
   response with Result TLV=Failure.  If the EAP server sends a failure,
   the peer MUST respond with Result TLV=Failure and the Crypto-Binding
   TLV, without any other mandatory TLVs.  The Crypto-Binding TLV is
   calculated using the key derivation formula in Section 2.5; if for
   some reason one or more inner EAP method MSKs were not derived, then
   these MSKs are assumed to be null.

   If the EAP server has sent the success indication (Result
   TLV=Success), the peer is allowed to refuse to accept a Success
   message from the EAP server since the client's policy may require
   completion of certain EAP methods or the client may require
   credentials.

   If the EAP server has sent a success indication (Result TLV=success),
   and the peer wants authentication to fail, it sends the TLV response



Zorn, et al.            Expires September 9, 2011              [Page 18]


Internet-Draft                    TEAM                        March 2011


   with Result TLV=Failure and Crypto-Binding TLV.

   After the EAP server returns success, if the peer wants to request
   the EAP server to continue conversation, it sends a Result
   TLV=Success along with a Request-Action TLV with the appropriate
   action (e.g.  Negotiate-EAP, or Process-TLV).  If the Request-Action
   TLV is set to mandatory, then the EAP server MUST process the action,
   or return status=failure, closing the conversation inside the tunnel.
   If the Request-Action TLV is set to optional, then the EAP server can
   ignore the TLV and return Result TLV=Success again, closing the
   conversation inside the tunnel.

4.4.3.  Provisioning of Credentials

   TEAM supports built-in provisioning of certificate trust anchors and
   can be extended to provisioning of other types of credentials.  The
   following two provisioning modes are suported:

   1.  Provisioning inside a server authenticated TLS tunnel
   2.  Provisioning inside a server unauthenticated TLS tunnel

4.4.3.1.  Provisioning Inside a Server Authenticated TLS Tunnel

   After regular authentication in TEAM Phase 2, the peer and EAP server
   can use the Server-Trusted-Root TLV to request and provision peer
   credentials.  The provisioning payload is exchanged after the peer
   and EAP server have determined that both have successfully
   authenticated each other (either thru TLS handshake and/or inner EAP
   method), and the tunnel and inner EAP methods are between the same
   peers.

   After the peer has determined that it has successfully authenticated
   the EAP server and determined that the tunnel and inner EAP methods
   were between the same peer and EAP server by validating the Crypto-
   Binding TLV, it MAY send one or more Server- Trusted-Root TLVs
   (marked as optional) to request credentials from the EAP server.  The
   EAP server will send corresponding credentials in the Server-Trusted-
   Root TLVs if its internal policy has been satisfied.  It may ignore
   the credential provisioning request or request additional
   authentication methods if its policy so dictates.  The peer may
   receive a credential, but is not required to use the credentials
   received from the EAP server.

4.4.3.2.  Provisioning Inside a Server Unauthenticated TLS Tunnel

   In some cases, the peer may lack the credentials necessary to
   authenticate the server in the TLS handshake.  At the same time,
   bootstrapping the information to the peer out of band may be



Zorn, et al.            Expires September 9, 2011              [Page 19]


Internet-Draft                    TEAM                        March 2011


   prohibitive from a deployment cost perspective.  It can rely on the
   inner EAP method using existing credentials to authenticate the
   server.

   In this provisioning mode, as part of TEAM Phase 1, if the peer does
   not authenticate, or does not successfully authenticate the EAP
   server during TLS negotiation, it can decide to go into server
   unauthenticated tunnel provisioning mode.  In a certificate-based TLS
   handshake, the peer verifies that the EAP server possesses the
   private key corresponding to the public key contained in the
   certificate presented by the EAP server.  However, the peer does not
   verify whether the certificate presented by the server chains to a
   provisioned trust anchor, as the peer may not be configured with a
   certificate trust anchor required to validate the server certificate.
   If the peer cannot verify that the server possesses the corresponding
   private key, or if the certificate presented by the server is
   unacceptable for any reason other than the lack of an appropriate
   trust anchor, the peer MUST NOT use this provisioning mode.  Assuming
   that the server demonstrates possession of the private key, the peer
   continues with establishment of the tunnel (TEAM Phase 2).  In a
   certificate-less TLS handshake the peer and server perform an
   anonymous exchange.  There is no attempt by the peer to verify the
   server's identity.  In both the certificate-based and certificate-
   less TEAM Phase 1 exchange for the Server Unauthenticated mode, it is
   possible that the TLS channel (TEAM Phase 2) may be terminated by an
   attacker.  For this reason the TEAM Phase 2 exchange MUST be
   resistant to dictionary attack.

   The TEAM Phase 2 conversation is unchanged in this mode, except that
   the peer will only accept an EAP method supporting mutual
   authentication, key derivation and resistance to dictionary attack
   that is compatible with its initial credentials (such as EAP-pwd
   [RFC5931]).  The peer then uses the Crypto-Binding TLV to validate
   that the same server terminates both the TLS channel and the
   successfully completed EAP method, thereby verifying that the
   exchange was not subject to a man-in-the-middle attack.  Assuming
   that the Crypto- Binding TLV exchange is successful, the peer will
   request and the server will subsequently provide a trusted root,
   using the Server-Trusted-Root TLV.

   Once the initial provisioning exchange completes, the peer is
   expected to use the provisioned credentials in subsequent TEAM
   authentications, and SHOULD NOT continue to use this provisioning
   mode.

   TEAM servers and peers implementing this provisioning mode MUST
   support EAP-pwd [RFC5931] as a TEAM Phase 2 conversation.




Zorn, et al.            Expires September 9, 2011              [Page 20]


Internet-Draft                    TEAM                        March 2011


   TEAM servers implementing this provisioning mode MUST support the
   following additional ciphersuites, beyond those specified in
   Section 4.3.2:

      TLS_DH_anon_WITH_AES_128_CBC_SHA

   TEAM peers implementing this provisioning mode MAY support the
   following additional ciphersuites, beyond those specified in
   Section 4.3.2:

      TLS_DH_anon_WITH_AES_128_CBC_SHA

4.5.  Error Handling

   TEAM does not have its own error message capabilities since:

   1.  TLS errors are communicated via TLS alert messages.
   2.  Errors within the EAP conversation in TEAM Phase 2 are expected
       to be handled by individual EAP methods.
   3.  Violation of the TLV rules (Section 6.19) for inner-TLVs are
       handled using Result-TLVs together with the Error-Code TLV.

   If an error occurs at any point in the TLS layer, the EAP server
   SHOULD send a TLS alert message instead of the next EAP-request
   packet to the peer.  The EAP server SHOULD send an EAP-Request packet
   with EAP-Type=TEAM, encapsulating a TLS record containing the
   appropriate TLS alert message.  The EAP server SHOULD send a TLS
   alert message rather than immediately terminating the conversation so
   as to allow the peer to inform the user of the cause of the failure
   and possibly allow for a restart of the conversation.  To ensure that
   the peer receives the TLS alert message, the EAP server MUST wait for
   the peer to reply with an EAP-Response packet.

   The EAP-Response packet sent by the peer MAY encapsulate a TLS
   client_hello handshake message, in which case the EAP server MAY
   allow the TEAM conversation to be restarted, or it MAY contain an
   EAP-Response packet with EAP-Type=TEAM and no data, in which case the
   TEAM server MUST send an EAP-Failure packet, and terminate the
   conversation.

   It is up to the EAP server whether to allow restarts, and if so, how
   many times the conversation can be restarted.  An EAP server
   implementing restart capability SHOULD impose a limit on the number
   of restarts, so as to protect against denial of service attacks.

   If an error occurs at any point in the TLS layer, the peer SHOULD
   send a TLS alert message instead of the next EAP-response packet to
   the EAP server.  The peer SHOULD send an EAP-Response packet with



Zorn, et al.            Expires September 9, 2011              [Page 21]


Internet-Draft                    TEAM                        March 2011


   EAP-Type=TEAM, encapsulating a TLS record containing the appropriate
   TLS alert message.  The EAP server may restart the conversation by
   sending a EAP-Request packet encapsulating the TLS
   hello_request_handshake message, in which case the peer MAY allow the
   TEAM conversation to be restarted; or the EAP server can response
   with EAP Failure.

   Any time the peer or the EAP server finds an error when processing
   the sequence of exchanges, such as a violation of the TLV rules
   Section 6.19, it should send a Result TLV of failure and Error-Code
   TLV=Unexpected_TLVs_Exchanged (a Fatal error), and terminate the
   tunnel.  This is usually due to an implementation problem and is
   considered an fatal error.  The party that receives the Error-Code
   TLV=Unexpected_TLVs_Exchanged should terminate the tunnel.

   If a tunnel compromise error (see (Section 4.4)) is detected by the
   Peer or EAP server, the party SHOULD send a Result TLV of failure
   without a Crypto-Binding TLV, and Error-Code TLV=Tunnel-compromise-
   error (a Fatal error), and terminate the tunnel.  The party that
   receives the Error-Code TLV=Tunnel-compromise error should terminate
   the tunnel.

4.6.  Fragmentation and Reassembly

   A single TLS record may be up to 16384 octets in length, but a TLS
   message may span multiple TLS records, and a TLS certificate message
   may in principle be as long as 16MB.

   The group of TEAM messages sent in a single round may thus be larger
   than the PPP MTU size, the maximum RADIUS packet size of 4096 octets,
   or even the Multilink Maximum Received Reconstructed Unit (MRRU).

   As described in [RFC1990], the multilink MRRU is negotiated via the
   Multilink MRRU LCP option, which includes an MRRU length field of two
   octets, and thus can support MRRUs as large as 64 KB.

   However, note that in order to protect against reassembly lockup and
   denial of service attacks, it may be desirable for an implementation
   to set a maximum size for one such group of TLS messages.  Since a
   typical certificate chain is rarely longer than a few thousand
   octets, and no other field is likely to be anywhere near as long, a
   reasonable choice of maximum acceptable message length might be 64
   KB.

   If this value is chosen, then fragmentation can be handled via the
   multilink PPP fragmentation mechanisms described in [RFC1990]. this
   is desirable, EAP methods are used in other applications such as
   [IEEE.802-11.2007] and there may be cases in which multilink or the



Zorn, et al.            Expires September 9, 2011              [Page 22]


Internet-Draft                    TEAM                        March 2011


   MRRU LCP option cannot be negotiated.  As a result, a TEAM
   implementation MUST provide its own support for fragmentation and
   reassembly.

   Since EAP is an ACK-NAK protocol, fragmentation support can be added
   in a simple manner.  In EAP, fragments that are lost or damaged in
   transit will be retransmitted, and since sequencing information is
   provided by the Identifier field in EAP, there is no need for a
   fragment offset field as is provided in IPv4.

   TEAM fragmentation support is provided through addition of flag bits
   within the EAP-Response and EAP-Request packets, as well as a TLV
   Message Length field of four octets.  Flags include the Length
   included (L), More fragments (M), and TEAM Start (S) bits.  The L
   flag is set to indicate the presence of the four octet TLV Message
   Length field, and MUST be set only for the first fragment of a
   fragmented TLV message or set of messages.

   The TLV Message Length field in the TEAM header is not protected, and
   hence can be modified by a attacker.  The TLS record length in the
   TLS data is protected.  Hence, if the TLV Message length received in
   the first packet (with L bit set) is greater or less than the total
   size of TLS messages received including multiple fragments, then the
   TLV message length should be ignored.

   In order to protect against reassembly lockup and denial of service
   attacks, it may be desirable for an implementation to set a maximum
   size for a single group of Outer-TLV messages.  Since a typical
   certificate chain is rarely longer than a few thousand octets, and no
   other field is likely to be anywhere near as long, a reasonable
   choice of maximum acceptable message length for all the Outer-TLVs in
   a group of messages might be 64 KB.

   The M flag is set on all but the last fragment.  The S flag is set
   only within the TEAM start message sent from the EAP server to the
   peer.  The TLV Message Length field is four octets, and provides the
   total length of the TLV message or set of messages that is being
   fragmented; this simplifies buffer allocation.

   When a peer receives an EAP-Request packet with the M bit set, it
   MUST respond with an EAP-Response with EAP-Type=TEAM and no data.
   This serves as a fragment ACK.  The EAP server MUST wait until it
   receives the EAP-Response before sending another fragment.  In order
   to prevent errors in processing of fragments, the EAP server MUST
   increment the Identifier field for each fragment contained within an
   EAP-Request, and the peer MUST include this Identifier value in the
   fragment ACK contained within the EAP-Response.  Retransmitted
   fragments will contain the same Identifier value.



Zorn, et al.            Expires September 9, 2011              [Page 23]


Internet-Draft                    TEAM                        March 2011


   Similarly, when the EAP server receives an EAP-Response with the M
   bit set, it MUST respond with an EAP-Request with EAP-Type=TEAM and
   no TLS data.  This serves as a fragment ACK.  The EAP peer MUST wait
   until it receives the EAP-Request before sending another fragment.
   In order to prevent errors in the processing of fragments, the EAP
   server MUST increment the Identifier value for each fragment ACK
   contained within an EAP-Request, and the peer MUST include this
   Identifier value in the subsequent fragment contained within an EAP-
   Response.

4.7.  Key Derivation

   Since the normal TLS keys are used in the handshake, and therefore
   should not be used in a different context, new keys must be derived
   from the TLS master secret to protect the conversation within the
   TEAM tunnel.

   Instead of deriving keys specific to link layer ciphersuites, EAP
   methods provide a Master Session Key (MSK) used to derive keys in a
   link layer specific manner.  The method used to extract ciphering
   keys from the MSK is beyond the scope of this document.

   TEAM also derives an Extended Master Session Key (EMSK) which is
   reserved for use in deriving keys in other ciphering applications.
   This draft also does not discuss the format of the attributes used to
   communicate the master session keys from the backend authentication
   server to the NAS; examples of such attributes are provided in
   [RFC2548].

   TEAM combines key material from the TLS exchange with key material
   from inner key generating EAP methods to provide stronger keys and to
   bind inner authentication mechanisms to the TLS tunnel.  Both the
   peer and EAP server MUST derive compound MAC and compound session
   keys using the procedure described below.

   The input for the cryptographic binding includes the following:

   1.  The TEAM tunnel key (TK) is calculated using the first 40 octets
       of the (secret) key material generated as described in the EAP-
       TLS algorithm (see Section 2.3 of [RFC5216]) More explicitly, the
       TK is the first 40 octets of the PRF as defined in RFC 5216:

       Key_Material = TLS-PRF-128(  master_secret, "client EAP
                                    encryption", client.random ||
                                    server.random )






Zorn, et al.            Expires September 9, 2011              [Page 24]


Internet-Draft                    TEAM                        March 2011


   2.  The first 32 octets of the MSK provided by each successful inner
       EAP method for each successful EAP method completed within the
       tunnel.

       ISK1..ISKn are the MSK portion of the EAP keying material
       obtained from methods 1 to n.  The ISKj SHALL be the first 32
       octets of the generated MSK of the jth EAP method.  If the MSK
       length is less than 32 octets, it SHALL be padded with 0x00's to
       ensure the MSK is 32 octets.  Similarly, if no keying material is
       provided for the EAP method, then ISKj SHALL be set to zero (e.g.
       32 octets of 0x00).

   The key derivation process is based on "extract-then-expand"
   technique of HKDF [RFC5869].  Entropy from the TEAM Tunnel Key, TK,
   is first extracted into a pseudo-random key and then expanded into a
   series of intermediate combined keys, IPMK1..IPMKn, and Compound MAC
   keys, CMK1..CMKn.


     IPMK0 = HKDF-Extract(salt, TK)
     for j = 1 to n do
       IPMKj | CMKj = HKDF-Expand(IPMK(j-1),
                                  "Inner Methods Compound Keys" | ISKj,
                                  60)
     done


   Where:
   o  salt is 32 octets of 0x00
   o  IPMKj are 40 octets in length
   o  CMKj are 20 octets in length used to generate the intermediate
      Compound MACs
   and
   o  n = the last successful EAP method inside the tunnel at the point
      where the Compound Session Key is derived

4.7.1.  Compound Session Key Derivation

   The compound session key (CSK) is derived on both the peer and EAP
   server:

      CSK = HKDF-Expand(IPMKn, "Session Key Generating Function", 128)

   The length of the CSK MUST be 128 octets.  The first 64 octets SHALL
   be taken as the MSK and the second 64 octets SHALL be taken as the
   EMSK.  The MSK and EMSK are described in [RFC3748].





Zorn, et al.            Expires September 9, 2011              [Page 25]


Internet-Draft                    TEAM                        March 2011


4.8.  Ciphersuite Negotiation

   Since TLS supports TLS ciphersuite negotiation, peers completing the
   TLS negotiation will also have selected a TLS ciphersuite, which
   includes key strength, encryption and hashing methods.  However,
   unlike in [RFC5216], within TEAM, the negotiated TLS ciphersuite
   relates only to the mechanism by which the TEAM Phase 2 conversation
   will be protected, and has no relationship to link layer security
   mechanisms negotiated within the PPP Encryption Control Protocol
   (ECP) [RFC1968] or within IEEE 802.11 [IEEE.802-11.2007].

   As a result, this specification currently does not support secure
   negotiation of link layer ciphersuites.

5.  TEAM Protocol Description

5.1.  TEAM Protocol Layers

   TEAM packets may include TLVs both inside and outside the TLS tunnel.
   The term "Outer TLVs" is used to refer to optional TLVs outside the
   TLS tunnel, which are only allowed in the first two messages in the
   TEAM protocol, i.e., the first EAP server to peer message and first
   peer to EAP server message.  If the message is fragmented, the whole
   set of messages is counted as one message.  The term "Inner TLVs" is
   used to refer to TLVs sent within the TLS tunnel.

   In TEAM Phase 1, Outer TLVs are used to help establishing the TLS
   tunnel, but no Inner TLVs are used.  Therefore the layering of TEAM
   Phase 1 is as follows:

              +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
              |            TLS        |  Optional Outer TLVs    |
              +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
              |                    TEAM                         |
              +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
              |                     EAP                         |
              +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   In Phase 2 of the TEAM conversation, TLS records may encapsulate zero
   or more Inner TLVs, but no Outer TLVs.  EAP packets (including EAP
   header fields) used within tunneled EAP authentication methods are
   carried within Inner TLVs.  Therefore the layering of TEAM Phase 2 is
   as follows:








Zorn, et al.            Expires September 9, 2011              [Page 26]


Internet-Draft                    TEAM                        March 2011


              +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
              |                     EAP                         |
              +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
              |          Inner-TLVs (EAP-Payload TLV)           |
              +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
              |                     TLS                         |
              +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
              |                    TEAM                         |
              +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
              |                     EAP                         |
              +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

5.2.  TEAM Packet Format

   A summary of the TEAM packet format is shown below.  The fields are
   transmitted from left to right.

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |     Code      |   Identifier  |            Length             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |     Type      |   Flags | Ver |    Fragment Message Length
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Fragment Message Length     |    TLS Message Length
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |     TLS Message Length        |      TLS Data...
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |             Outer TLVs...
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Code

      1 -  Request
      2 -  Response

   Identifier

      The Identifier field is one octet and aids in matching responses
      with requests.  The Identifier field MUST be changed on each
      Request packet.  The Identifier field in a Response packet MUST
      match the Identifier field from the corresponding Request.

   Length

      The Length field is two octets and indicates the length of the EAP
      packet including the Code, Identifier, Length, Type, Flags,
      Version, Fragmented Length, TLS Message Length, TLS Data, and



Zorn, et al.            Expires September 9, 2011              [Page 27]


Internet-Draft                    TEAM                        March 2011


      Outer-TLV fields.  Octets outside the range of the Length field
      should be treated as Data Link Layer padding and should be ignored
      on reception.

   Type

      <TBD> - TEAM

   Flags

       0 1 2 3 4
      +-+-+-+-+-+
      |L M S T R|
      +-+-+-+-+-+

      L =  Length included
      M =  More fragments
      S =  TEAM start
      T =  TLS length included
      R =  Reserved (must be zero)

      The L bit (Fragmented Message Length included) is set to indicate
      the presence of the four octet Fragmented Message Length field,
      and MUST be set for the first fragment of a fragmented TEAM
      message or set of messages.  The M bit (more fragments) is set on
      all but the last fragment.  The S bit (TEAM start) is set in a
      TEAM Start message.  This differentiates the TEAM Start message
      from a fragment acknowledgment.  The T bit (TLS Message Length
      included) is set to indicate the presence of the four octet TLS
      Message Length field, and MUST only be set for packet that
      contains Outer-TLVs.  It can be used to calculate the start of the
      Outer-TLVs.

   Version

       0 1 2
      +-+-+-+
      |R|0|1|
      +-+-+-+

      R = Reserved (must be zero)

   Fragmented Message Length

      The Fragmented Message Length field is four octets, and is present
      only if the L bit is set.  This field provides the total length of
      the data after the Fragmented Message Length field in the TEAM
      message or set of messages that is being fragmented.



Zorn, et al.            Expires September 9, 2011              [Page 28]


Internet-Draft                    TEAM                        March 2011


   TLS Message Length

      The TLS Message Length field is four octets, and is present only
      if the T bit is set.  This field provides the total length of the
      TLS Data in the TEAM message.  Data after this length of TLS data
      are the Outer TLVs.

   TLS Data

      The TLS data consists of the encapsulated packet in TLS record
      format.

   Outer TLVs

      The Outer TLVs consist of the optional data used to help
      establishing the TLS tunnel in TLV format.  The start of the
      Outer-TLVs can be derived from the EAP Length field and TLS Length
      field.

6.  Type-Length-Value Tuples

   The TLVs used within TEAM are standard Type-Length-Value (TLV)
   objects.  The TLV objects could be used to carry arbitrary parameters
   between EAP peer and EAP server.  Possible uses for TLV objects
   include: language and character set for Notification messages and
   cryptographic binding.

   The EAP peer may not necessarily implement all the TLVs supported by
   the EAP server; and hence to allow for interoperability, TLVs allow
   an EAP server to discover if a TLV is supported by the EAP peer,
   using the NAK TLV.  The TEAM packet does not have to contain any
   TLVs, nor need it contain any mandatory TLVs.

   The mandatory bit in a TLV indicates whether support of the TLV is
   required.  If the peer or server does not support the TLV, it MUST
   send a NAK TLV in response, and all the other TLVs in the message
   MUST be ignored.  If an EAP peer or server finds an unsupported TLV
   which is marked as optional, it can ignore the unsupported TLV.  It
   MUST NOT send an NAK TLV.

   Note that a peer or server may support a TLV with the mandatory bit
   set, but may not understand the contents.  The appropriate response
   to a supported TLV with content that is not understood is defined by
   the TLV specification.

   Outer-TLVs SHOULD NOT be included in messages after the first two
   Outer-TLV messages sent by the peer and EAP server respectively.  A
   single Outer-TLV message may be fragmented in multiple TEAM packets.



Zorn, et al.            Expires September 9, 2011              [Page 29]


Internet-Draft                    TEAM                        March 2011


   All Outer-TLVs MUST NOT have the mandatory bit set.  If an Outer-TLV
   has the mandatory bit set, then the packet MUST be ignored.

   TEAM implementations MUST support TLVs, as well as processing of
   mandatory/optional settings on the TLV.

6.1.  TLV Format

   TLVs are defined as described below.  The fields are transmitted from
   left to right.

       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             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                              Value...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   M

      0 -  Optional TLV
      1 -  Mandatory TLV

   R

      Reserved, set to zero (0)

   TLV Type

      A 14-bit field, denoting the TLV type.  Allocated types include:

      1  -  Result
      2  -  NAK
      3  -  Error-Code
      4  -  Connection-Binding
      5  -  Vendor-Specific
      6  -  URI
      7  -  EAP-Payload
      8  -  Intermediate-Result
      9  -  Crypto-Binding
      10 -  Calling-Station-Id
      11 -  Called-Station-Id
      12 -  NAS-Port-Type







Zorn, et al.            Expires September 9, 2011              [Page 30]


Internet-Draft                    TEAM                        March 2011


      13 -  Server-Identifier
      14 -  Identity-Type
      15 -  Server-Trusted-Root
      16 -  Request-Action
      17 -  PKCS#7

   Length

      The length of the Value field in octets

   Value

      The value of the TLV


6.2.  Result TLV

   The Result TLV provides support for acknowledged success and failure
   messages within TEAM.  TEAM implementations MUST support this TLV,
   which cannot be responded to with a NAK TLV.  If the Status field
   does not contain one of the known values, then the peer or EAP server
   MUST drop the connection.  The Result 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             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |             Status            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   M

      1 (Mandatory)

   R

      0

   TLV Type

      1 for Result








Zorn, et al.            Expires September 9, 2011              [Page 31]


Internet-Draft                    TEAM                        March 2011


   Length

      2

   Status

      The Status field is two octets.  Values include:

      1 -  Success
      2 -  Failure


6.3.  NAK TLV

   The NAK TLV allows a peer to detect TLVs that are not supported by
   the other peer.  A TLV packet can contain 0 or more NAK TLVs.  TEAM
   implementations MUST support the NAK TLV, which cannot be responded
   to with a NAK TLV.  The NAK 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             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                          Vendor-Id                            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |            NAK-Type           |           TLVs....
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   M

      1 (Mandatory)

   R

      0

   TLV Type

      2 for NAK

   Length

      >= 6







Zorn, et al.            Expires September 9, 2011              [Page 32]


Internet-Draft                    TEAM                        March 2011


   Vendor-ID

      The Vendor-Id field is four octets, and contains the Vendor-Id of
      the TLV that was not supported.  The high-order octet is 0 and the
      low-order 3 octets are the SMI Network Management Private
      Enterprise Code of the Vendor in network byte order.  The Vendor-
      Id field MUST be zero for TLVs that are not Vendor-Specific TLVs.
      For Vendor-Specific TLVs, the Vendor-ID MUST be set to the SMI
      code.

   NAK-Type

      The NAK-Type field is two octets.  The field contains the Type of
      the TLV that was not supported.  A TLV of this Type MUST have been
      included in the previous packet.

   TLVs

      This field contains a list of TLVs, each of which MUST NOT have
      the mandatory bit set.  These optional TLVs can be used in the
      future to communicate why the offending TLV was determined to be
      unsupported.


6.4.  Error-Code TLV

   The Error-Code TLV allows a TEAM peer or server to indicate errors to
   the other party.  A TLV packet can contain 0 or more Error TLVs.
   Error-Code TLVs MUST be marked as Mandatory.  TEAM implementations
   MUST support the Error-Code TLV, which cannot be responded to with a
   NAK TLV.  The Error-Code 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             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                           Error-Code                          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   M

      1 (Mandatory)








Zorn, et al.            Expires September 9, 2011              [Page 33]


Internet-Draft                    TEAM                        March 2011


   R

      0

   TLV Type

      3 for Error-Code

   Length

      4

   Error-Code

      The Error-Code field is four octets.  Error Codes 1-999 represent
      successful outcomes (informative messages), 1000-1999 represent
      warnings, and codes 2000-2999 represent fatal errors.  If an
      Error- Code TLV with a fatal error has been sent, then the
      conversation must be terminated.

      Currently defined values for Error-Code include:

      2001 -  Tunnel_Compromise_Error
      2002 -  Unexpected_TLVs_Exchanged


6.5.  Crypto-Binding TLV

   The Crypto-Binding TLV is used prove that both peers participated in
   the sequence of authentications (specifically the TLS session and
   inner EAP methods that generate keys).

   Both the Binding Request (B1) and Binding Response (B2) use the same
   packet format.  However the Sub-Type indicates whether it is B1 or
   B2.

   The Crypto-Binding TLV MUST be used to perform Cryptographic Binding
   after each successful EAP method in a sequence of EAP methods is
   complete in TEAM Phase 2.  The Crypto-Binding TLV can also be used
   during Protected Termination.

   The Crypto-Binding TLV must have the version number received during
   the TEAM version negotiation.  The receiver of the Crypto-Binding TLV
   must verify that the version in the Crypto-Binding TLV matches the
   version it sent during the TEAM version negotiation.  If this check
   fails then the TLV is invalid.

   The receiver of the Crypto-Binding TLV must verify that the subtype



Zorn, et al.            Expires September 9, 2011              [Page 34]


Internet-Draft                    TEAM                        March 2011


   is not set to any value other than the ones allowed.  If this check
   fails then the TLV is invalid.

   This message format is used for the Binding Request (B1) and also the
   Binding Response.  This uses TLV type CRYPTO_BINDING_TLV.  TEAM
   implementations MUST support this TLV and this TLV cannot be
   responded to with a NAK TLV.  The Crypto-Binding 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             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Reserved   |    Version    |  Received Ver.    | Sub-Type  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     ~                             Nonce                             ~
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     ~                          Compound MAC                         ~
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   M

      1 (Mandatory)

   R

      0

   TLV Type

      9 for Crypto-Binding

   Length

      56

   Reserved

      Reserved, set to zero (0)






Zorn, et al.            Expires September 9, 2011              [Page 35]


Internet-Draft                    TEAM                        March 2011


   Version

      The Version field is a single octet, which is set to the version
      of Crypto-Binding TLV.  For the Crypto-Binding TLV defined in this
      specification, it is set to one (1).

   Sub-Type

      The Sub-Type field is two octets.  Possible values include:

      0 -  Binding Request
      1 -  Binding Response

   Nonce

      The Nonce field is 32 octets.  It contains a 256 bit nonce that is
      temporally unique, used for compound MAC key derivation at each
      end.  This is the S_NONCE for the B1 message and a C_NONCE for the
      B2 message.

   Compound MAC

      The Compound MAC field is 20 octets.  This can be the Server MAC
      (B1_MAC) or the Client MAC (B2_MAC).  It is computed using the
      HMAC-SHA1-160 keyed MAC that provides 160 bits of output using the
      CMK key.  The MAC is computed over the buffer created after
      concatenating these fields in the following order:

      1.  The entire Crypto-Binding TLV attribute with the MAC field
          zeroed out
      2.  The EAP Type sent by the other party in the first TEAM message
      3.  All the Outer-TLVs from the first TEAM message sent by EAP
          server to peer.  If a single TEAM message is fragmented into
          multiple TEAM packets; then the Outer-TLVs in all the
          fragments of that message MUST be included.
      4.  All the Outer-TLVs from the first TEAM message sent by the
          peer to the EAP server.  If a single TEAM message is
          fragmented into multiple TEAM packets, then the Outer-TLVs in
          all the fragments of that message MUST be included.

6.6.  Connection-Binding TLV

   The Connection-Binding TLV allows for connection specific information
   to be sent by the peer to the AAA server.  This TLV should be logged
   by the EAP or AAA server.  The AAA or EAP server should not deny
   access if there is a mismatch between the value sent through the AAA
   protocol and this TLV.




Zorn, et al.            Expires September 9, 2011              [Page 36]


Internet-Draft                    TEAM                        March 2011


   The format of this TLV is defined for the layer that defines the
   parameters.  The format of the value sent by the peer to the EAP
   server may be different from the format of the corresponding value
   sent through the AAA protocol.  For example, the connection binding
   TLV may contain the 802.11 MAC Address or SSID [IEEE.802-11.2007].

   TEAM implementations MAY support this TLV and this TLV MUST NOT be
   responded to with a NAK TLV.  The Connection-Binding 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             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                           TLVs...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   M

      0 (Optional)

   R

      0

   TLV Type

      4 for Connection-Binding

   Length

      >= 0

   TLVs

      The field contains a list of TLVs, each in the same format defined
      in Section 6.1, with the Mandatory flag bit cleared (0).  These
      TLVs contain information on the identity of the peer and
      authenticator (layer 2 or IP addresses); the media used to connect
      the peer and authenticator (NAS-Port-Type); and/or the service the
      client is trying to access on the gateway (SSID).  See
      Section 6.19.4 for further information.







Zorn, et al.            Expires September 9, 2011              [Page 37]


Internet-Draft                    TEAM                        March 2011


6.7.  Vendor-Specific TLV

   The Vendor-Specific TLV is available to allow vendors to support
   their own extended attributes not suitable for general usage.

   A Vendor-Specific-TLV can contain one or more TLVs, referred to as
   Vendor TLVs.  The TLV-type of the Vendor-TLV will be defined by the
   vendor.  All the Vendor TLVs inside a single Vendor- Specific TLV
   belong to the same vendor.

   TEAM implementations MUST support the Vendor-Specific TLV, and this
   TLV MUST NOT be responded to with a NAK TLV.  If a TEAM
   implementation does not support one or more of the Vendor TLVs inside
   in the Vendor-Specific TLV it SHOULD respond to the Vendor TLV(s)
   with NAK TLV(s) containing the appropriate Vendor-ID and Vendor-TLV
   type.

   Vendor TLVs may be optional or mandatory.  Vendor TLVs sent in the
   protected success and failure packets MUST be marked as optional.  If
   Vendor TLVs sent in protected success/failure packets are marked as
   Mandatory, then the peer or EAP server MUST drop the connection.

   The Vendor-Specific 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             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                          Vendor-Id                            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                         Vendor TLVs....
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   M

      1 (Mandatory)

   R

      0

   TLV Type

      5 for Vendor-Specific





Zorn, et al.            Expires September 9, 2011              [Page 38]


Internet-Draft                    TEAM                        March 2011


   Length

      >= 4

   Vendor-ID

      The Vendor-Id field is four octets, and contains the Vendor-Id of
      the TLV that was not supported.  The high-order octet is 0 and the
      low-order 3 octets are the SMI Network Management Private
      Enterprise Code of the Vendor in network byte order.  The Vendor-
      Id field MUST be zero for TLVs that are not Vendor-Specific TLVs.
      For Vendor-Specific TLVs, the Vendor-ID MUST be set to the SMI
      code.

   Vendor TLVs

      This field is of indefinite length.  It contains vendor-
      specificTLVs, in a format defined by the vendor.


6.8.  URI TLV

   The URI TLV allows a server to send a URI to the client to refer it
   to a resource.  The TLV contains a URI in the format specified in RFC
   3986 [RFC3986] with UTF-8 encoding.  Interpretation of the value of
   the URI is outside the scope of this document.

   If a packet contains multiple URI TLVs, then the client SHOULD select
   the first TLV it can implement, and ignore the others.  If the client
   is unable to implement any of the URI TLVs, then it MAY ignore the
   error.  TEAM implementations MAY support this TLV; and this TLV
   cannot be responded to with a NAK TLV.  The URI 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             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                              URI
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   M

      0 (Optional)






Zorn, et al.            Expires September 9, 2011              [Page 39]


Internet-Draft                    TEAM                        March 2011


   R

      0

   TLV Type

      6 for URI

   Length

      >= 0

   URI

      This field is of indefinite length, and conforms to the format
      specified in RFC 3986.


6.9.  EAP-Payload TLV

   To allow piggybacking EAP request and response with other TLVs, the
   EAP Payload TLV is defined, which includes an encapsulated EAP packet
   and 0 or more TLVs.  TEAM implementations MUST support this TLV,
   which cannot be responded to with a NAK TLV.  The EAP-Payload 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             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                          EAP-Packet...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                             TLVs...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   M

      1 (Mandatory)

   R

      0








Zorn, et al.            Expires September 9, 2011              [Page 40]


Internet-Draft                    TEAM                        March 2011


   TLV Type

      7 for EAP-Payload

   Length

      >= 0

   EAP-Packet

      This field contains a complete EAP packet, including the EAP
      header (Code, Identifier, Length, Type) fields.  The length of
      this field is determined by the Length field of the encapsulated
      EAP packet.

   TLVs

      This (optional) field contains a list of TLVs associated with the
      EAP-Packet field (see Section 6.19.3).  The TLVs utilize the same
      format described Section 6.1, and MUST NOT have the mandatory bit
      set.  The total length of this field is equal to the Length field
      of the EAP- Payload-TLV, minus the Length field in the EAP header
      of the EAP packet field.


6.10.  Intermediate-Result TLV

   The Intermediate-Result TLV provides support for acknowledged
   intermediate Success and Failure messages within EAP.  TEAM
   implementations MUST support this TLV, which cannot be responded to
   with a NAK TLV.  The Intermediate-Result 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             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |             Status            |        TLVs...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   M

      1 (Mandatory)








Zorn, et al.            Expires September 9, 2011              [Page 41]


Internet-Draft                    TEAM                        March 2011


   R

      0

   TLV Type

      8 for Intermediate-Result

   Length

      >= 2

   Status

      The Status field is two octets.  Values include:

         1 - Success
         2 - Failure

   TLVs

      This (optional) field contains a list of TLVs associated with the
      Intermediate-Result TLV.  The TLVs utilize the same format
      described Section 6.1, and MUST NOT have the mandatory bit set.


6.11.  Calling-Station-Id TLV

   This TLV allows a peer to send information to EAP server about the
   call originator.  This TLV MAY be included in the Connection-Binding-
   TLV.

   For dial-up, the Called-Station-ID TLV contains the phone number of
   the peer.  For use with IEEE 802.1X, the MAC address of the peer is
   included [RFC3580].

   For VPN, this attribute is used to send the IPv4 or IPV6 address of
   the interface of the peer used to initiate the VPN in ASCII format.
   Where the Fully Qualified Domain Name (FQDN) of the VPN client is
   known, it SHOULD be appended, separated from the address with a " "
   (space).  Example: "12.20.2.3 vpnserver.example.com".

   As described in Section 7.15 of [RFC3748], this TLV SHOULD be logged
   by the EAP or AAA server, and MAY be used for comparison with
   information gathered by other means.

   However, since the format of this TLV may not match the format of the
   information gathered by other means, if an EAP server or AAA server



Zorn, et al.            Expires September 9, 2011              [Page 42]


Internet-Draft                    TEAM                        March 2011


   supports the capability to deny access based on a mismatch, spurious
   authentication failures may occur.  As a result, implementations
   SHOULD allow the administrator to disable this check.

   TEAM implementations MAY support this TLV and this TLV MUST NOT be
   responded to with a NAK TLV.  The Calling-Station-ID 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             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                           String...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   M

      0 (Optional)

   R

      0

   TLV Type

      10 for Calling-Station-Id

   Length

      >= 0

   String

      The field should be the same as the value of the
      Calling-Station-ID attribute in [RFC2865].


6.12.  Called-Station-Id TLV

   This TLV allows a peer to send information to EAP server about the
   NAS it called.  This TLV MAY be included in the Connection-Binding
   TLV.

   For dial-up, the Calling-Station-ID TLV contains the phone number
   called by the peer.  For use with IEEE 802.1X, the MAC address of the
   NAS is included, as specified in [RFC3580].



Zorn, et al.            Expires September 9, 2011              [Page 43]


Internet-Draft                    TEAM                        March 2011


   For VPN, this attribute is used to send the IPv4 or IPv6 address of
   VPN server in ASCII format.  Where the Fully Qualified Domain Name
   (FQDN) of the VPN server is known, it SHOULD be appended, separated
   from the address with a " " (space).  Example: "12.20.2.3
   vpnserver.example.com".

   This TLV SHOULD be logged by the EAP or AAA server, and MAY be used
   for comparison with information gathered by other means.  However,
   since the format of this TLV may not match the format of the
   information gathered by other means, if an EAP server or AAA server
   supports the capability to deny access based on a mismatch, spurious
   authentication failures may occur.  As a result, implementations
   SHOULD allow the administrator to disable this check.

   TEAM implementations MAY support this TLV, and this TLV MUST NOT be
   responded to with a NAK TLV.  The Called-Station-ID 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             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                     String...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   M

      0 (Optional)

   R

      0

   TLV Type

      11 for Called-Station-Id

   Length

      >= 0

   String

      The field should be the same as the value of the Called-Station-ID
      attribute in [RFC2865].




Zorn, et al.            Expires September 9, 2011              [Page 44]


Internet-Draft                    TEAM                        March 2011


6.13.  NAS-Port-Type TLV

   This TLV allows a peer to send information to EAP server about the
   type of physical connection used by the peer to connect to NAS.  This
   TLV MAY be included in the Connection-Binding-TLV.

   The value of this field is the same as the value of NAS-Port-Type
   attribute in [RFC2865].

   This TLV SHOULD be logged by the EAP or AAA server and MAY be used
   for comparison with information gathered by other means.  However,
   since the format of this TLV may not match the format of the
   information gathered by other means, if an EAP server or AAA server
   supports the capability to deny access based on a mismatch, spurious
   authentication failures may occur.  As a result, implementations
   SHOULD allow the administrator to disable this check.

   TEAM implementations MAY support this TLV; and this TLV MUST NOT be
   responded to with a NAK TLV.  The NAS-Port-Type 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             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                            Value                              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   M

      0 (Optional)

   R

      0

   TLV Type

      12 for NAS-Port-Type

   Length

      4






Zorn, et al.            Expires September 9, 2011              [Page 45]


Internet-Draft                    TEAM                        March 2011


   String

      The String field is four octets.  Values are the same as for the
      NAS-Port-Type attribute defined in [RFC2865].


6.14.  Server-Identifier TLV

   This TLV allows a EAP server to send a hint to the EAP peer to help
   the EAP peer select the appropriate sessionID for session resumption.
   The field is a string sent by the EAP server, and the field should be
   treated as a opaque string by the peer.  During a full-tls-handshake,
   the EAP peer MAY keep track of this field and the corresponding
   sessionID, and use it as a hint to select the appropriate sessionID
   during session resumption.

   TEAM implementations MAY support this TLV and this TLV MUST NOT be
   responded to with a NAK TLV.  The Server-Identifier 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             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                            String...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   M

      0 (Optional)

   R

      0

   TLV Type

      13 for Server-Identifier

   Length

      >= 0







Zorn, et al.            Expires September 9, 2011              [Page 46]


Internet-Draft                    TEAM                        March 2011


   String

      Contains an identifier sent by the EAP server.


6.15.  Identity-Type TLV

   The Identity-Type TLV allows an EAP server to send a hint to help the
   EAP-peer select the right type of identity; for example; user or
   machine.

   TEAM implementations MAY support this TLV, which cannot be responded
   to with a NAK TLV.

   If the Identity Type field does not contain one of the known values
   or if the EAP peer does not have an identity corresponding to the
   identity-type, then the peer MUST ignore the value.  The Identity-
   Type 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             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |             Identity Type     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   M

      0 (Optional)

   R

      0

   TLV Type

      14 for Identity-Type

   Length

      2








Zorn, et al.            Expires September 9, 2011              [Page 47]


Internet-Draft                    TEAM                        March 2011


   Identity Type

      The Identity Type field is two octets.  Values include:
         1 - Human
         2 - Machine


6.16.  Server-Trusted-Root TLV

   The Server-Trusted-Root TLV allows the peer to send a request to the
   EAP server for a trusted root in PKCS #7 format.

   The Server-Trusted-Root TLV is always marked as optional, and cannot
   be responded to with a NAK TLV.  TEAM server implementations that
   claim to support provisioning MUST support Server-Trusted-Root TLV,
   PKCS#7 TLV, and the PKCS#7-Server-Certificate-Root credential format
   defined in this TLV.  TEAM peer implementations may not support this
   TLV.

   The Server-Trusted-Root TLV can only be sent as an inner TLV (inside
   the TEAM Phase 2 conversation), in both server unauthenticated tunnel
   provisioning mode, and the regular authentication process.

   The peer MUST NOT request, or accept the trusted root sent inside the
   Server-Root credential TLV by the EAP server until it has completed
   authentication of the EAP server, and validated the Crypto-Binding
   TLV.  The peer may receive a trusted root, but is not required to use
   the trusted root received from the EAP server.

   If the EAP server sets credential-format to PKCS#7-Server-
   Certificate-Root, then the Server-Trusted-Root TLV MUST contain the
   root of the certificate chain of the certificate issued to the EAP
   server packages in a PKCS#7 TLV.  If the Server certificate is a
   self-signed certificate, then the root is the self-signed
   certificate.  In this case, the EAP server does not have to sign the
   certificate inside the PCKS#7 TLV since it does not necessarily have
   access to the private key for it.

   If the Server-Trusted-Root TLV credential format does not contain one
   of the known values, then the EAP server MUST ignore the value.

   The Server-Trusted-Root TLV is defined as follows:









Zorn, et al.            Expires September 9, 2011              [Page 48]


Internet-Draft                    TEAM                        March 2011


      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             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |         Credential Type       |     TLVs...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

   M

      0 (Optional)

   R

      0

   TLV Type

      15 for Server-Trusted-Root

   Length

      >= 2

   Credential Type

      The Credential Type field is two octets.  Values include:
         1 - PKCS#7-Server-Certificate-Root

   TLVs

      This (optional) field contains a list of TLVs associated with the
      Server-Trusted-Root TLV.  The TLVs utilize the same format
      described Section 6.1 and MUST NOT have the mandatory bit set.
      See Section 6.19.5 for further information.


6.17.  PKCS#7 TLV

   This TLV contains a certificate or certificate chain requested by the
   peer in PKCS#7 format [RFC2315].

   The PKCS#7 TLV is always marked as optional, and cannot be responded
   to with a NAK TLV.  TEAM server implementations that claim to support
   provisioning MUST support this TLV.  TEAM peer implementations may
   not support this TLV.

   If the PKCS#7 TLV contains a certificate or certificate chain that is



Zorn, et al.            Expires September 9, 2011              [Page 49]


Internet-Draft                    TEAM                        March 2011


   not acceptable to the peer, then peer MUST ignore the value.

   The PKCS#7 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             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |           PKCS#7 data...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   M

      0 (Optional)

   R

      0

   TLV Type

      17 for PKCS#7

   Length

      >= 0

   PKCS#7 Data

      This field contains a certificate or certificate chain in PKCS#7
      format.


6.18.  Request-Action-TLV

   The Request-Action TLV MAY be sent by the peer along with
   acknowledged failure.  It allows the peer to request the EAP server
   to negotiate EAP methods or process TLVs specified in the failure
   packet.  The server MAY ignore this TLV.

   TEAM implementations MUST support this TLV, which cannot be responded
   to with a NAK TLV.

   The Request-Action TLV is defined as follows:





Zorn, et al.            Expires September 9, 2011              [Page 50]


Internet-Draft                    TEAM                        March 2011


      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             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |             Action            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   M

      1 (Mandatory)

   R

      0

   TLV Type

      16 for Request-Action

   Length

      2

   Action

      The Action field is two octets.  Values include:

         0 - Reserved
         1 - Process-TLV
         2 - Negotiate-EAP


6.19.  TLV Rules

   To save round trips, multiple TLVs can be sent in the single TEAM
   packet.  However, the encapsulation of multiple EAP Payload TLVs
   within a single TEAM packet is not supported in this version and MUST
   NOT be sent.  If the peer or EAP server receives multiple EAP Payload
   TLVs, then it MUST drop the connection.











Zorn, et al.            Expires September 9, 2011              [Page 51]


Internet-Draft                    TEAM                        March 2011


   The following table defines the meaning of the table entries in the
   sections below:

   0    This TLV MUST NOT be present in the packet
   0+   Zero or more instances of this TLV MAY be present in packet
   0-1  Zero or one instances of this TLV MAY be present in packet
   1    Exactly one instance of this TLV MUST be present in packet

6.19.1.  Outer TLVs

   The following table provides a guide to which TLVs may be included in
   the TEAM packet outside the TLS channel, which kind of packets, and
   in what quantity:

   +---------+----------+---------+---------+--------------------------+
   | Request | Response | Success | Failure | TLV in unencrypted-TLVs  |
   |         |          |         |         | field                    |
   +---------+----------+---------+---------+--------------------------+
   | 0-1     | 0        | 0       | 0       | Server-Identifier TLV    |
   | 0+      | 0+       | 0       | 0       | Vendor-Specific TLV      |
   +---------+----------+---------+---------+--------------------------+

   Outer-TLVs MUST be marked as optional.  Vendor-TLVs inside a Vendor-
   Specific TLV MUST be marked as optional when included in Outer TLVs.
   Outer-TLVs MUST NOT be included in messages after the first two TEAM
   messages sent by peer and EAP server respectively, i.e., the first
   EAP server to peer message and first peer to EAP server message.  If
   a message is fragmented, the whole set of fragments is counted as one
   message.  If Outer-TLVs are included in messages after the first two
   TEAM messages, they MUST be ignored.





















Zorn, et al.            Expires September 9, 2011              [Page 52]


Internet-Draft                    TEAM                        March 2011


6.19.2.  Inner TLVs

   The following table provides a guide to which Inner TLVs may be
   encapsulated in TLS in TEAM Phase 2, in which kind of packets, and in
   what quantity:

   +---------+----------+---------+---------+---------------------+
   | Request | Response | Success | Failure | Inner TLV           |
   +---------+----------+---------+---------+---------------------+
   | 0-1     | 0-1      | 0-1     | 0-1     | Intermediate-Result |
   | 0-1     | 0-1      | 0       | 0       | EAP-Payload         |
   | 0-1     | 0-1      | 1       | 1       | Result              |
   | 0-1     | 0-1      | 1       | 1       | Crypto-Binding      |
   | 0+      | 0+       | 0+      | 0+      | Error               |
   | 0+      | 0+       | 0       | 0       | NAK                 |
   | 0-1     | 0-1      | 0-1     | 0-1     | Connection-Binding  |
   | 0+      | 0+       | 0+      | 0+      | Vendor-Specific     |
   | 0+      | 0        | 0+      | 0-1     | URI                 |
   | 0+      | 0        | 0       | 0       | Identity-Type       |
   | 0+      | 0+       | 0+      | 0+      | Server-Trusted-Root |
   | 0       | 0-1      | 0       | 0-1     | Request-Action      |
   +---------+----------+---------+---------+---------------------+

   Vendor TLVs (included in Vendor-Specific TLVs) sent in the protected
   success and failure packets MUST be marked as optional.  If Vendor
   TLVs sent in protected success/failure packets are marked as
   Mandatory, then the peer or EAP server MUST drop the connection.

   +----------+--------------------------------------------------------+
   | Packet   | Description                                            |
   | Type     |                                                        |
   +----------+--------------------------------------------------------+
   | Request  | TLS packet sent by the EAP server to the peer          |
   | Response | TLS packet sent by the peer to the EAP server          |
   | Success  | TLS packet sent by the peer or EAP server as a         |
   |          | protected success indication                           |
   | Failure  | TLS packet sent by the peer or EAP server as a         |
   |          | protected failure indication                           |
   +----------+--------------------------------------------------------+












Zorn, et al.            Expires September 9, 2011              [Page 53]


Internet-Draft                    TEAM                        March 2011


6.19.3.  EAP-Payload TLV

   The EAP-Payload TLV can contain other TLVs.  The table below defines
   which TLVs can be contained inside the EAP-Payload TLV and how many
   such TLVs can be included.

   +---------+----------+-----------------+
   | Request | Response | TLV             |
   +---------+----------+-----------------+
   | 0+      | 0+       | Vendor-Specific |
   | 0+      | 0+       | Identity-Type   |
   +---------+----------+-----------------+

   Vendor TLVs encapsulated in a Vendor-Specific TLV MUST be marked as
   optional when included in an EAP-Payload TLV.

6.19.4.  Connection-Binding TLV

   The Connection-Binding TLV can contain other TLVs.  The table below
   defines which TLVs can be contained inside the Connection-Binding TLV
   and how many such TLVs can be included.

   +---------+----------+--------------------+
   | Request | Response | TLV                |
   +---------+----------+--------------------+
   | 0-1     | 0        | Calling-Station-ID |
   | 0-1     | 0        | Called-Station-ID  |
   | 0-1     | 0        | NAS-Port-Type      |
   | 0+      | 0+       | Vendor-Specific    |
   +---------+----------+--------------------+

   Vendor TLVs encapsulated in a Vendor-Specific TLV MUST be marked as
   optional when included in a Connection-Binding TLV.

6.19.5.  Server-Trusted-Root TLV

   The Server-Trusted-Root TLV can contain other TLVs.  The table below
   defines which TLVs can be contained inside the Server-Trusted-Root
   TLV and how many such TLVs can be included.

   +---------+----------+--------+
   | Request | Response | TLV    |
   +---------+----------+--------+
   | 0-1     | 0        | PKCS#7 |
   +---------+----------+--------+






Zorn, et al.            Expires September 9, 2011              [Page 54]


Internet-Draft                    TEAM                        March 2011


7.  Security Considerations

7.1.  Authentication and Integrity Protection

   TEAM provides a server authenticated, encrypted and integrity
   protected tunnel.  All data within the tunnel has these properties.
   Data outside the tunnel such as EAP Success and Failure, Outer-TLVs,
   authentication methods negotiated outside of TEAM and the TEAM
   headers themselves (including the EAP-Type in the header) are not
   protected by this tunnel.

   In addition, the Crypto-Binding TLV can reveal a man-in-the-middle
   attack described in Section 7.8, below.  Hence, the server should not
   reveal any sensitive data to the client until after the Crypto-
   Binding TLV has been properly verified.

   In order to detect the modification of Outer TLVs, the first two
   Outer TLV messages sent by both peer and EAP server are included in
   the calculation of the Crypto-Binding TLV.  Outer-TLVs SHOULD NOT be
   included in other TEAM packets since there is no mechanism to detect
   modification.

   In order to detect modification of EAP-Type sent in the clear (EAP-
   Type should be set to TEAM), the EAP-Type sent in the first two
   messages by both peer and EAP server is included in the calculation
   of Crypto-Binding TLV.  The EAP-Type in the clear could be modified
   in other TEAM packets and will likely result in failure, hence it is
   not included in the Crypto-Binding calculation.

7.2.  Method Negotiation

   If the peer does not support TEAM, or does not wish to utilize TEAM
   authentication, it MUST respond to the initial EAP- Request/
   TEAM-Start with a NAK, suggesting an alternate authentication method.
   Since the NAK is sent in cleartext with no integrity protection or
   authentication, it is subject to spoofing.  Inauthentic NAK packets
   can be used to trick the peer and authenticator into "negotiating
   down" to a weaker form of authentication, such as EAP- MD5 (which
   only provides one way authentication and does not derive a key).

   Since a subsequent protected EAP conversation can take place within
   the TLS session, selection of TEAM as an authentication method does
   not limit the potential secondary authentication methods.  As a
   result, the only legitimate reason for a peer to NAK TEAM as an
   authentication method is that it does not support it.  Where the
   additional security of TEAM is required, server implementations
   SHOULD respond to a NAK with an EAP-Failure, terminating the
   authentication conversation.



Zorn, et al.            Expires September 9, 2011              [Page 55]


Internet-Draft                    TEAM                        March 2011


   Since method negotiation outside of TEAM is not protected, if the
   peer is configured to allow TEAM and other EAP methods at the same
   time, the negotiation is subject to downgrade attacks.  Since method
   negotiation outside of TEAM is not protected, if the peer is
   configured to allow TEAM and previous TEAM versions at the same time,
   the negotiation is subject to negotiation downgrade attacks.
   However, peers configured to allow TEAM and later TEAM versions may
   not be subject to downgrade negotiation attack since the highest
   version supported by both peers is checked within the protected
   tunnel.

   If peer implementations select incorrect methods or credentials with
   EAP servers, then attacks are possible on the credentials.  Hence, a
   TEAM peer implementation should preferably be configured with a set
   of credentials and methods that may be used with a specific TEAM
   server.  The peer implementation may be configured to use different
   methods and/or credentials based on the TEAM server.

7.3.  TLS Session Cache Handling

   In cases where a TLS session has been successfully resumed, in some
   circumstances, it is possible for the EAP server to skip TEAM Phase
   2, and successfully conclude the conversation with a protected
   termination.

   TEAM "fast reconnect" is desirable in applications such as wireless
   roaming, since it minimizes interruptions in connectivity.  It is
   also desirable when the "inner" EAP mechanism used is such that it
   requires user interaction.  The user should not be required to re-
   authenticate herself, using biometrics, token cards or similar, every
   time the radio connectivity is handed over between access points in
   wireless environments.

   However, there are issues that need to be understood in order to
   avoid introducing security vulnerabilities.

   Since Phase 1 of TEAM may not provide client authentication,
   establishment of a TLS session (and an entry in the TLS session
   cache) does not by itself provide an indication of the peer's
   authenticity.

   Some TEAM implementations may not be capable of removing TLS session
   cache entries established in TEAM Phase 1 after an unsuccessful Phase
   2 authentication.  In such implementations, the existence of a TLS
   session cache entry provides no indication that the peer has
   previously been authenticated.  As a result, implementations that do
   not remove TLS session cache entries after a TEAM Phase 2
   authentication or failed protected termination MUST use other means



Zorn, et al.            Expires September 9, 2011              [Page 56]


Internet-Draft                    TEAM                        March 2011


   than successful TLS resumption as the indicator of whether the client
   is authenticated or not.  The implementation MUST determine that the
   client is authenticated only after the completion of protected
   termination.  Failing to do this would enable a peer to gain access
   by completing TEAM Phase 1, tearing down the connection, re-
   connecting and resuming TEAM Phase 2, thereby proving herself
   authenticated.  Thus, TLS resumption MUST only be enabled if the
   implementation supports TLS session cache removal.  If an EAP server
   implementing TEAM removes TLS session cache entries of peers failing
   TEAM Phase 2 authentication, then it MAY skip the TEAM Phase 2
   conversation entirely after a successful session resumption,
   successfully terminating the TEAM conversation as described in
   Section 4.4.2.

7.4.  Certificate Revocation

   Since the EAP server usually has network connectivity during the EAP
   conversation, the server is capable of following a certificate chain
   or verifying whether the peer's certificate has been revoked.  In
   contrast, the peer may or may not have network connectivity, and thus
   while it can validate the EAP server's certificate based on a pre-
   configured set of CAs, it may not be able to follow a certificate
   chain or verify whether the EAP server's certificate has been
   revoked.

   In the case where the peer is initiating a voluntary Layer 2 channel
   using PPTP [RFC2637] or L2TP [RFC3931], the peer will typically
   already have network connectivity established at the time of channel
   initiation.  As a result, during the EAP conversation it is capable
   of checking for certificate revocation.

   As part of the TLS negotiation, the server presents a certificate to
   the peer.  The peer SHOULD verify the validity of the EAP server
   certificate, and SHOULD also examine the EAP server name presented in
   the certificate, in order to determine whether the EAP server can be
   trusted.  Please note that in the case where the EAP authentication
   is remoted, the EAP server will not reside on the same machine as the
   authenticator, and therefore the name in the EAP server's certificate
   cannot be expected to match that of the intended destination.  In
   this case, a more appropriate test might be whether the EAP server's
   certificate is signed by a CA controlling the intended destination
   and whether the EAP server exists within a target sub-domain.

   In the case where the peer is attempting to obtain network access, it
   will not have network connectivity.  The TLS Extensions [RFC5246]
   support piggybacking of an Online Certificate Status Protocol
   [RFC2560] or a Server-based Certificate Validation Protocol [RFC5055]
   response within TLS, therefore can be utilized by the peer in order



Zorn, et al.            Expires September 9, 2011              [Page 57]


Internet-Draft                    TEAM                        March 2011


   to verify the validity of server certificate.  However, since not all
   TLS implementations implement the TLS extensions, it may be necessary
   for the peer to wait to check for certificate revocation until after
   network access has been obtained.  In this case, the peer SHOULD
   conduct the certificate status check immediately upon going online
   and SHOULD NOT send data until it has received a positive response to
   the status request.  If the server certificate is found to be invalid
   as per client policy, then the peer SHOULD disconnect.

   If the client has a policy to require checking certificate revocation
   and it cannot obtain revocation information then it may need to
   disallow the use of all or some of the inner methods since some
   methods may reveal some sensitive information.

7.5.  Separation of EAP Server and Authenticator

   As a result of a complete TEAM conversation, the EAP endpoints will
   mutually authenticate, and derive a session key for subsequent use in
   link layer security.  Since the peer and EAP client reside on the
   same machine, it is necessary for the EAP client module to pass the
   session key to the link layer encryption module.

   The situation may be more complex on the Authenticator, which may or
   may not reside on the same machine as the EAP server.  In the case
   where the EAP server and the Authenticator reside on different
   machines, there are several implications for security.  Firstly, the
   mutual authentication defined in TEAM will occur between the peer and
   the EAP server, not between the peer and the authenticator.  This
   means that as a result of the TEAM conversation, it is not possible
   for the peer to validate the identity of the NAS or channel server
   that it is speaking to.

   The second issue is that the session key negotiated between the peer
   and EAP server will need to be transmitted to the authenticator.
   Therefore a secure mechanism needs to be provided to transmit the
   session key from the EAP server to the authenticator or channel
   server that needs to use the key.  The specification of this transit
   mechanism is outside the scope of this document.

7.6.  Separation of TEAM Phase 1 and 2 Servers

   The EAP server involved in TEAM Phase 2 need not necessarily be the
   same as the EAP server involved in Phase 1.  For example, a local
   authentication server or proxy might serve as the endpoint for the
   Phase 1 conversation, establishing the TLS channel.  Subsequently,
   once the EAP-Response/Identity has been received within the TLS
   channel, it can be decrypted and forwarded in cleartext to the
   destination realm EAP server.  The rest of the conversation will



Zorn, et al.            Expires September 9, 2011              [Page 58]


Internet-Draft                    TEAM                        March 2011


   therefore occur between the destination realm EAP server and the
   peer, with the local authentication server or proxy acting as an
   encrypting/decrypting gateway.  This permits a non-TLS capable EAP
   server to participate in the TEAM conversation.

   Note however that such an approach introduces security
   vulnerabilities.  Since the EAP Response/Identity is sent in the
   clear between the proxy and the EAP server, this enables an attacker
   to snoop the user's identity.  It also enables a remote environments,
   which may be public hot spots or Internet coffee shops, to gain
   knowledge of the identity of their users.  Since one of the potential
   benefits of TEAM is identity protection, this is undesirable.

   If the EAP method negotiated during TEAM Phase 2 does not support
   mutual authentication, then if the Phase 2 conversation is proxied to
   another destination, the TEAM peer will not have the opportunity to
   verify the secondary EAP server's identity.  Only the initial EAP
   server's identity will have been verified as part of TLS session
   establishment.

   Similarly, if the EAP method negotiated during TEAM Phase 2 is
   vulnerable to dictionary attack, then an attacker capturing the
   cleartext exchange will be able to mount an offline dictionary attack
   on the password.

   Finally, when a Phase 2 conversation is terminated at a different
   location than the Phase 1 conversation, the Phase 2 destination is
   unaware that the EAP client has negotiated TEAM.  As a result, it is
   unable to enforce policies requiring TEAM.  Since some EAP methods
   require TEAM in order to generate keys or lessen security
   vulnerabilities, where such methods are in use, such a configuration
   may be unacceptable.

   In summary, TEAM encrypting/decrypting gateway configurations are
   vulnerable to attack and SHOULD NOT be used.  Instead, the entire
   TEAM connection SHOULD be proxied to the final destination, and the
   subsequently derived master session keys need to be transmitted back.
   This provides end-to-end protection of TEAM.  The specification of
   this transit mechanism is outside the scope of this document, but
   mechanisms similar to those described in [RFC2548] can be used.
   These steps protect the client from revealing her identity to the
   remote environment.

   In order to find the proper TEAM destination, the EAP client SHOULD
   place a Network Access Identifier (NAI) [RFC4282] in the Identity
   Response.

   There may be cases where a natural trust relationship exists between



Zorn, et al.            Expires September 9, 2011              [Page 59]


Internet-Draft                    TEAM                        March 2011


   the (foreign) authentication server and final EAP server, such as on
   a campus or between two offices within the same company, where there
   is no danger in revealing the identity of the station to the
   authentication server.  In these cases, a proxy solution without end
   to end protection of TEAM MAY be used.  If RADIUS [RFC2865] is used
   to communicate between gateway and EAP server, then the TEAM
   encrypting/decrypting gateway SHOULD provide support for IPsec
   protection of RADIUS in order to provide confidentiality for the
   portion of the conversation between the gateway and the EAP server,
   as described in [RFC3579].

7.7.  Identity Verification

   Since the TLS session has not yet been negotiated, the initial
   Identity request/response occurs in the clear without integrity
   protection or authentication.  It is therefore subject to snooping
   and packet modification.

   In configurations where all users are required to authenticate with
   TEAM and the first portion of the TEAM conversation is terminated at
   a local backend authentication server, without routing by proxies,
   the initial cleartext Identity Request/Response exchange is not
   needed in order to determine the required authentication method(s) or
   route the authentication conversation to its destination.  As a
   result, the initial Identity and Request/Response exchange may not be
   present, and a subsequent Identity Request/Response exchange MAY
   occur after the TLS session is established.

   If the initial cleartext Identity Request/Response has been tampered
   with, after the TLS session is established, it is conceivable that
   the EAP Server will discover that it cannot verify the peer's claim
   of identity.  For example, the peer's userID may not be valid or may
   not be within a realm handled by the EAP server.  Rather than
   attempting to proxy the authentication to the server within the
   correct realm, the EAP server SHOULD terminate the conversation.

   The TEAM peer can present the server with multiple identities.  This
   includes the claim of identity within the initial EAP- Response/
   Identity (MyID) packet, which is typically used to route the EAP
   conversation to the appropriate home backend authentication server.
   There may also be subsequent EAP-Response/Identity packets sent by
   the peer once the TLS channel has been established.

   Note that since the TEAM peer may not present a certificate, it is
   not always possible to check the initial EAP-Response/Identity
   against the identity presented in the certificate, as is done in
   [RFC5216].




Zorn, et al.            Expires September 9, 2011              [Page 60]


Internet-Draft                    TEAM                        March 2011


   Moreover, it cannot be assumed that the peer identities presented
   within multiple EAP-Response/Identity packets will be the same.  For
   example, the initial EAP-Response/Identity might correspond to a
   machine identity, while subsequent identities might be those of the
   user.  Thus, TEAM implementations SHOULD NOT abort the authentication
   just because the identities do not match.  However, since the initial
   EAP-Response/Identity will determine the EAP server handling the
   authentication, if this or any other identity is inappropriate for
   use with the destination EAP server, there is no alternative but to
   terminate the TEAM conversation.

   The protected identity or identities presented by the peer within
   TEAM Phase 2 may not be identical to the cleartext identity presented
   in TEAM Phase 1, for legitimate reasons.  In order to shield the
   userID from snooping, the cleartext Identity may only provide enough
   information to enable routing of the authentication request to the
   correct realm.  For example, the peer may initially claim the
   identity of "nouser@bigco.com" in order to route the authentication
   request to the bigco.com EAP server.  Subsequently, once the TLS
   session has been negotiated, in TEAM Phase 2, the peer may claim the
   identity of "fred@bigco.com".  Thus, TEAM can provide protection for
   the user's identity, though not necessarily the destination realm,
   unless the TEAM Phase 1 conversation terminates at the local
   authentication server.

   As a result, TEAM implementations SHOULD NOT attempt to compare the
   Identities claimed with Phases 1 and 2 of the TEAM conversation.
   Similarly, if multiple Identities are claimed within TEAM Phase 2,
   these SHOULD NOT be compared.  An EAP conversation may involve more
   than one EAP authentication method, and the identities claimed for
   each of these authentications could be different (e.g. a machine
   authentication, followed by a user authentication).

7.8.  Man-in-the-Middle Attack Protection

   TLS protection can address a number of weaknesses in the EAP method;
   as well as EAP protocol weaknesses listed in the abstract and
   introduction sections in this document.

   Hence, the recommended solution is to always deploy authentication
   methods with protection of TEAM.

   If a deployment chooses to allow a EAP method protected by TEAM
   without protection of TEAM or IPsec at the same time, then this opens
   up a possibility of a man-in-the-middle attack.

   A man-in-the-middle can spoof the client to authenticate to it
   instead of the real EAP server; and forward the authentication to the



Zorn, et al.            Expires September 9, 2011              [Page 61]


Internet-Draft                    TEAM                        March 2011


   real server over a protected tunnel.  Since the attacker has access
   to the keys derived from the tunnel, it can gain access to the
   network.

   TEAM prevents this attack by using the keys generated by the inner
   EAP method in the crypto-binding exchange described in protected
   termination section.  This attack is not prevented if the inner EAP
   method does not generate keys or if the keys generated by the inner
   EAP method can be compromised.  Hence, in cases where the inner EAP
   method does not generate keys, the recommended solution is to always
   deploy authentication methods protected by TEAM.

   Alternatively, the attack can also be thwarted if the inner EAP
   method can signal to the peer that the packets are being sent within
   the tunnel.  In most cases this may require modification to the inner
   EAP method.  In order to allow for these implementations, TEAM
   implementations should inform inner EAP methods that the EAP method
   is being protected by a TEAM tunnel.

   Since all sequence negotiations and exchanges are protected by TLS
   channel, they are immune to snooping and MITM attacks with the use of
   Crypto-Binding TLV.  To make sure the same parties are involved
   tunnel establishment and previous inner method, before engaging the
   next method to sent more sensitive information, both peer and server
   MUST use the Crypto-Binding TLV between methods to check the tunnel
   integrity.  If the Crypto-Binding TLV failed validation, they SHOULD
   stop the sequence and terminate the tunnel connection, to prevent
   more sensitive information being sent in subsequent methods.

7.9.  Cleartext Forgeries

   As described in [RFC3748], EAP Success and Failure packets are not
   authenticated, so that they may be forged by an attacker without fear
   of detection.  Forged EAP Failure packets can be used to convince an
   EAP peer to disconnect.  Forged EAP Success and Failure packets may
   be used to convince a peer to disconnect; or convince a peer to
   access the network even before authentication is complete, resulting
   in denial of service for the peer.

   By supporting encrypted, authenticated and integrity protected
   success/failure indications, TEAM provides protection against these
   attacks.

   Once the peer responds with the first TEAM packet; and the EAP server
   receives the first TEAM packet from the peer, both MUST silently
   discard all clear text EAP messages unless both the TEAM peer and
   server have indicated success or failure or error using a protected
   error or protected termination mechanism.  The success/failure



Zorn, et al.            Expires September 9, 2011              [Page 62]


Internet-Draft                    TEAM                        March 2011


   decisions sent by a protected mechanism indicate the final decision
   of the EAP authentication conversation.  After success/failure has
   been indicated by a protected mechanism, the TEAM client can process
   unprotected EAP success and EAP failure message; however MUST ignore
   any unprotected EAP success or failure messages where the decision
   does not match the decision of the protected mechanism.

   After a Fatal alert is received or after protected termination is
   complete, the peer or EAP server should accept clear text EAP
   messages.  If the TEAM tunnel is nested inside another tunnel, then
   the clear text EAP messages should only be accepted after protected
   termination of outer tunnels.

   RFC 3748 states that an EAP Success or EAP Failure packet terminates
   the EAP conversation, so that no response is possible.  Since EAP
   Success and EAP Failure packets are not retransmitted, if the final
   packet is lost, then authentication will fail.  As a result, where
   packet loss is expected to be non-negligible, unacknowledged success/
   failure indications lack robustness.

   As a result, a EAP server SHOULD send a clear text EAP Success or
   Failure packet after the protected success or failure packet or TLS
   alert.  The peer MUST NOT require the clear text EAP Success or EAP
   Failure if it has received the protected success or failure or TLS
   alert.  For more details, refer to Section 4.2 of RFC 3748.

7.10.  TLS Ciphersuites

   Anonymous ciphersuites are vulnerable to man-in-the-middle attacks,
   and SHOULD NOT be used with TEAM, unless the EAP methods inside TEAM
   can address the man-in-the-middle attack or unless the man-in- the-
   middle attack can be addressed by mechanisms external to TEAM.

7.11.  Denial of Service Attacks

   Denial of service attacks are possible if the attacker can insert or
   modify packets in the authentication channel.  The attacker can
   modify unprotected fields in the TEAM packet such as the EAP protocol
   or TEAM version number.  This can result in a denial of service
   attack.  It is also possible for the attacker to modify protected
   fields in a packet to cause decode errors resulting in a denial of
   service.  In these ways the attacker can prevent access for peers
   connecting to the network.

   Denial of service attacks with multiplier impacts are more
   interesting than the ones above.  It is possible to multiply the
   impact by creating a large number of TLS sessions with the EAP
   server.



Zorn, et al.            Expires September 9, 2011              [Page 63]


Internet-Draft                    TEAM                        March 2011


7.12.  Server Unauthenticated Tunnel Provisioning Mode

   This section describes the rationale and security risks behind server
   unauthenticated tunnel provisioning mode.  Server unauthenticated
   tunnel provisioning mode can result in potential security
   vulnerabilities.  Hence, this mode is optional in TEAM
   implementations.

   In order to achieve strong mutual authentication, it is best to use
   an out of band mechanism to pre-provision the device with strong
   symmetric or asymmetric keys.  In addition, if the device is not
   physically secure (mobile or devices at public places), then it is
   important to ensure that the device has secure storage.

   Server unauthenticated tunnel provisioning mode is not recommended
   for use in devices which already support secure provisioning and
   secure credential storage capabilities.

   If the provisioned credential is a shared key or asymmetric key
   issued to the peer, then the credential should only be issued to
   devices that can protect the provisioned credentials using secure
   storage, or use physical security.

   If the credentials are not protected, the attacker can compromise the
   provisioned credentials, and use them to get access to the network.
   Mobile light weight devices are typically not physically secure.
   Another concern is that credentials provisioned to a light weight
   mobile device that does not use secure storage could be transferred
   to a general operating system and used to get access to the network.

   If the provisioned credential is a certificate trusted root of the
   EAP server, this is public information and hence not susceptible to
   the same attacks as a shared key or asymmetric key.

   In server unauthenticated tunnel provisioning mode, an attacker may
   terminate the tunnel instead of the real server.  The attacker can be
   detected after the Crypto-Binding TLV is exchanged and validated.
   However, the EAP packets exchanged inside the tunnel until Crypto-
   Binding TLV is validated are available in unencrypted form to the
   attacker.  It is difficult to completely negate the security risk
   unless the EAP methods inside the tunnel are secure; or unless
   physical wire security is assumed.

   The standard credential request/response capability is designed to be
   independent of the server unauthenticated tunnel provisioning mode,
   and can be used in regular authentication mode to provision other
   credentials to the peer that can be used for authentication to the
   network, or for potentially authentications to other services.



Zorn, et al.            Expires September 9, 2011              [Page 64]


Internet-Draft                    TEAM                        March 2011


   The security risks vary depending on the type of credential
   exchanged, the scope of use of the credential, and the implementation
   of the device.

   These are a few guidelines to reduce the security risk:

   1.  Minimize the use of this mode only during initial authentication
       to the network to reduce the risk of attack

   2.  The password-based EAP method used in provisioned mode MUST be
       resistant to dictionary attacks

   3.  Disable this mode by default and require users to initiate
       provisioning mode explicitly rather than being prompted during
       initiation of regular authentication process

   4.  Provide appropriate policy capabilities to allow administrators
       to lockdown the device and prevent regular users from enabling
       the mode

   5.  Ensure that the EAP methods used support mutual authentication,
       key derivation and resistance to dictionary attack

   6.  Ensure that the keys generated by EAP methods are of sufficient
       strength to prevent compounding binding from being compromised

   7.  Minimize the information disclosed to the EAP server


7.13.  Security Claims

   Intended use:             Wireless or Wired networks, and over the
                             Internet, where physical security cannot be
                             assumed

   Authentication mechanism: Uses arbitrary EAP and TLS authentication
                             mechanisms for authentication of the client
                             and server.

   Ciphersuite negotiation:  Yes

   Mutual authentication:    Yes (depends on the type of EAP method used
                             within the tunnel and the type of
                             authentication used within TLS)







Zorn, et al.            Expires September 9, 2011              [Page 65]


Internet-Draft                    TEAM                        March 2011


   Integrity protection:     Yes

   Replay protection:        Yes

   Confidentiality:          Yes

   Key derivation:           Yes

   Key strength:             Variable

   Dict. attack protection:  Yes

   Fast reconnect:           Yes

   Cryptographic binding:    Yes

   Acknowledged S/F:         Yes

   Session independence:     Yes

   Fragmentation:            Yes

   State synchronization:    Yes

   The TEAM protocol is unconditionally compliant with the requirements
   for WLAN authentication mechanisms, as specified in [RFC4017].

   TEAM derives keys by combining keys from TLS and the inner EAP
   methods.  It should be noted that the use of TLS ciphersuites with a
   particular key lengths does not guarantee that the key strength of
   the keys will be equivalent to the length.  The key exchange
   mechanisms (e.g., RSA or Diffie-Hellman) used must provide sufficient
   security or they will be the weakest link.  For example, RSA key
   sizes with a modulus of 1024 bits provides less than 128 bits of
   security; this may provide sufficient key strength for some
   applications and not for others.  See BCP 86 [RFC3766] for a detailed
   analysis of the strength requirements on the public keys used to
   exchange symmetric keys.

8.  IANA Considerations

   This memo specifies new values and registries to be created and
   managed by IANA.  The policies used to allocate numbers are described
   in [RFC5226].







Zorn, et al.            Expires September 9, 2011              [Page 66]


Internet-Draft                    TEAM                        March 2011


8.1.  EAP Type

   This memo requires IANA to allocate a new EAP method type for TEAM.
   The placeholder indicated by <TBD> in section Section 5.2 above shall
   be replaced by the new EAP method type upon assignment by IANA.

8.2.  TLV Types

   IANA is requested to create a registry for TEAM TLV Types.

   TLV Types may assume a value between 0 and 16383 of which 0-20 are
   allocated in this document Section 6.  Additional TLV type codes may
   be allocated following the "Specification Required" policy [RFC5226].

8.3.  TLV Values

   IANA is requested to create a registry for TEAM TLV Values, populated
   initially with entries for the Identity-Type, Credential Type and
   Action fields.

   The Identity-Type field may assume a value between 0 and 65535, of
   which 0-2 are allocated in this document Section 6.15, Additional
   Identity-Type values may be allocated following the "Specification
   Required" policy [RFC5226].

   The Credential Type field of the Server-Trusted-Root TLV Section 6.16
   may assume a value between 0 and 65535, of which 1 is allocated in
   this document.  Additional Credential Type values may be allocated
   following the "Specification Required" policy [RFC5226].

   The Action field field of the Request-Action TLV may assume a value
   between 0 and 65535, of which 0-2 have already been allocated.
   Additional Action values may be allocated following the
   "Specification Required" policy [RFC5226].

9.  Contributors

   A great deal of the text in the first draft of this note was taken
   from a document by Ashwin Palekar, Dan Simon, Glen Zorn, Simon
   Josefsson, Hao Zhou and Joe Salowey; the authors gratefully
   acknowledge their contribution.

   TEAM is a direct descendent of the Protected Extensible
   Authentication Protocol (PEAP), which was created by Glen Zorn while
   employed by Cisco Systems.






Zorn, et al.            Expires September 9, 2011              [Page 67]


Internet-Draft                    TEAM                        March 2011


10.  Acknowledgements

   Hakan Andersson, Jan-Ove Larsson, Magnus Nystrom, Bernard Aboba,
   Vivek Kamath, Stephen Bensley, Narendra Gidwani, Ilan Frenkel, Nancy
   Cam-Winget, Victor Lortz, Ashwin Palekar, Dan Simon, Glen Zorn, Simon
   Josefsson, Hao Zhou, Joe Salowey, Bernard Aboba, Paul Funk and Jose
   Puthenkulam all contributed at various stages to the development of
   this protocol.

11.  References

11.1.  Normative References

   [I-D.zorn-emu-eap-pwc]        Zorn, G., "A Method for Changing
                                 Cleartext Passwords in the Extensible
                                 Authentication Protocol", March 2011.

   [RFC2119]                     Bradner, S., "Key words for use in RFCs
                                 to Indicate Requirement Levels",
                                 BCP 14, RFC 2119, March 1997.

   [RFC3454]                     Hoffman, P. and M. Blanchet,
                                 "Preparation of Internationalized
                                 Strings ("stringprep")", RFC 3454,
                                 December 2002.

   [RFC3748]                     Aboba, B., Blunk, L., Vollbrecht, J.,
                                 Carlson, J., and H. Levkowetz,
                                 "Extensible Authentication Protocol
                                 (EAP)", RFC 3748, June 2004.

   [RFC3986]                     Berners-Lee, T., Fielding, R., and L.
                                 Masinter, "Uniform Resource Identifier
                                 (URI): Generic Syntax", STD 66,
                                 RFC 3986, January 2005.

   [RFC4013]                     Zeilenga, K., "SASLprep: Stringprep
                                 Profile for User Names and Passwords",
                                 RFC 4013, February 2005.

   [RFC4282]                     Aboba, B., Beadles, M., Arkko, J., and
                                 P. Eronen, "The Network Access
                                 Identifier", RFC 4282, December 2005.

   [RFC5226]                     Narten, T. and H. Alvestrand,
                                 "Guidelines for Writing an IANA
                                 Considerations Section in RFCs",
                                 BCP 26, RFC 5226, May 2008.



Zorn, et al.            Expires September 9, 2011              [Page 68]


Internet-Draft                    TEAM                        March 2011


   [RFC5246]                     Dierks, T. and E. Rescorla, "The
                                 Transport Layer Security (TLS) Protocol
                                 Version 1.2", RFC 5246, August 2008.

11.2.  Informative References

   [I-D.ietf-emu-eaptunnel-req]  Hoeper, K., Hanna, S., Zhou, H., and J.
                                 Salowey, "Requirements for a Tunnel
                                 Based EAP Method",
                                 draft-ietf-emu-eaptunnel-req-09 (work
                                 in progress), December 2010.

   [IEEE.802-11.2007]            IEEE Computer Society, "Information
                                 technology - Telecommunications and
                                 information exchange between systems -
                                 Local and metropolitan area networks -
                                 Specific requirements - Part 11:
                                 Wireless LAN Medium Access Control
                                 (MAC) and Physical Layer (PHY)
                                 specifications", IEEE Standard 802.11,
                                 June 2007.

   [IEEE.802-1X.2004]            IEEE Computer Society, "IEEE Standard
                                 for Local and metropolitan area
                                 networks: Port-Based Network Access
                                 Control", IEEE Standard 802.1X,
                                 December 2004.

   [RFC1968]                     Meyer, G. and K. Fox, "The PPP
                                 Encryption Control Protocol (ECP)",
                                 RFC 1968, June 1996.

   [RFC1990]                     Sklower, K., Lloyd, B., McGregor, G.,
                                 Carr, D., and T. Coradetti, "The PPP
                                 Multilink Protocol (MP)", RFC 1990,
                                 August 1996.

   [RFC2315]                     Kaliski, B., "PKCS #7: Cryptographic
                                 Message Syntax Version 1.5", RFC 2315,
                                 March 1998.

   [RFC2548]                     Zorn, G., "Microsoft Vendor-specific
                                 RADIUS Attributes", RFC 2548,
                                 March 1999.

   [RFC2560]                     Myers, M., Ankney, R., Malpani, A.,
                                 Galperin, S., and C. Adams, "X.509
                                 Internet Public Key Infrastructure



Zorn, et al.            Expires September 9, 2011              [Page 69]


Internet-Draft                    TEAM                        March 2011


                                 Online Certificate Status Protocol -
                                 OCSP", RFC 2560, June 1999.

   [RFC2637]                     Hamzeh, K., Pall, G., Verthein, W.,
                                 Taarud, J., Little, W., and G. Zorn,
                                 "Point-to-Point Tunneling Protocol",
                                 RFC 2637, July 1999.

   [RFC2865]                     Rigney, C., Willens, S., Rubens, A.,
                                 and W. Simpson, "Remote Authentication
                                 Dial In User Service (RADIUS)",
                                 RFC 2865, June 2000.

   [RFC3579]                     Aboba, B. and P. Calhoun, "RADIUS
                                 (Remote Authentication Dial In User
                                 Service) Support For Extensible
                                 Authentication Protocol (EAP)",
                                 RFC 3579, September 2003.

   [RFC3580]                     Congdon, P., Aboba, B., Smith, A.,
                                 Zorn, G., and J. Roese, "IEEE 802.1X
                                 Remote Authentication Dial In User
                                 Service (RADIUS) Usage Guidelines",
                                 RFC 3580, September 2003.

   [RFC3766]                     Orman, H. and P. Hoffman, "Determining
                                 Strengths For Public Keys Used For
                                 Exchanging Symmetric Keys", BCP 86,
                                 RFC 3766, April 2004.

   [RFC3931]                     Lau, J., Townsley, M., and I. Goyret,
                                 "Layer Two Tunneling Protocol - Version
                                 3 (L2TPv3)", RFC 3931, March 2005.

   [RFC4017]                     Stanley, D., Walker, J., and B. Aboba,
                                 "Extensible Authentication Protocol
                                 (EAP) Method Requirements for Wireless
                                 LANs", RFC 4017, March 2005.

   [RFC4962]                     Housley, R. and B. Aboba, "Guidance for
                                 Authentication, Authorization, and
                                 Accounting (AAA) Key Management",
                                 BCP 132, RFC 4962, July 2007.

   [RFC5055]                     Freeman, T., Housley, R., Malpani, A.,
                                 Cooper, D., and W. Polk, "Server-Based
                                 Certificate Validation Protocol
                                 (SCVP)", RFC 5055, December 2007.



Zorn, et al.            Expires September 9, 2011              [Page 70]


Internet-Draft                    TEAM                        March 2011


   [RFC5216]                     Simon, D., Aboba, B., and R. Hurst,
                                 "The EAP-TLS Authentication Protocol",
                                 RFC 5216, March 2008.

   [RFC5247]                     Aboba, B., Simon, D., and P. Eronen,
                                 "Extensible Authentication Protocol
                                 (EAP) Key Management Framework",
                                 RFC 5247, August 2008.

   [RFC5869]                     Krawczyk, H. and P. Eronen, "HMAC-based
                                 Extract-and-Expand Key Derivation
                                 Function (HKDF)", RFC 5869, May 2010.

   [RFC5931]                     Harkins, D. and G. Zorn, "Extensible
                                 Authentication Protocol (EAP)
                                 Authentication Using Only a Password",
                                 RFC 5931, August 2010.

Appendix A.  Compliance with Requirements for a Tunnel Based EAP Method

   The following subsections describe the TEAM protocol's compliance
   with the requirements given in [I-D.ietf-emu-eaptunnel-req].

A.1.  General Requirements

   o  TEAM includes a Security Claims section and satisfies all
      mandatory requirements listed in section 2.2 of [RFC4017].
   o  TEAM meets the MUST and SHOULD requirements of [RFC5247],
      including generation of the MSK, ESMK, Peer-Id, Server-Id, and
      Session-Id.
   o  TEAM is not tied to any single cryptographic algorithm.  A variety
      of ciphersuites can be negotiated in TEAM phase 1 which include a
      plethora of cryptographic algorithms.  Numerous phase 2
      authentication methods are supported which, likewise, constitute a
      plethora of cryptographic algorithms.
   o  TEAM meets all the MUST and SHOULD requirements in section 3 of
      [RFC4962] to the extent that they apply to an EAP method (and not
      to the use of a key derived from TEAM).  In particular TEAM keys
      are vine-ripened and very fresh.

A.2.  Tunnel Requirements

   o  TEAM uses TLS version 1.2 in phase 1 and satisfies all of the
      mandatory TLS requirements of section 4.2.1
      [I-D.ietf-emu-eaptunnel-req].
   o  TEAM supports fragmentation and reassembly per section 4.2.2 of
      [I-D.ietf-emu-eaptunnel-req].




Zorn, et al.            Expires September 9, 2011              [Page 71]


Internet-Draft                    TEAM                        March 2011


   o  Modification of data outside the tunnel is not protected but any
      such modification does not cause an exploitable vulnerability and
      can be detected Section 7.1.

A.3.  Tunnel Payload Requirements

   o  TEAM AVPs are extensible.
   o  TEAM is an EAP method and supports challenge/response operations
      that are typical of EAP methods.
   o  It is possible to indicate whether a TLV is mandatory or not.
   o  TEAM supports Vendor Specific extensions.
   o  TEAM supports indication of result after each changed inner
      method.

A.4.  Channel Binding Requirements

   o  To the extent that it is appropriate to rely on adherence to a
      "work-in-progress", TEAM supports Channel Binding requirements.
      Furthermore, as that "work-in-progress" proceeds in its work there
      is no reason why TEAM could not continue to meet requirements.

A.5.  Username/Password Requirements

   o  TEAM supports the required use of usernames and passwords in
      section 4.5 of [I-D.ietf-emu-eaptunnel-req] through the use of the
      EAP/Identity exchange and GTC [RFC3748], and EAP-PWC
      [I-D.zorn-emu-eap-pwc].  Note, however, that in order to comply
      with the requirements of [I-D.ietf-emu-eaptunnel-req] the user
      name contained in the EAP/Identity/Response and the password
      contined in the EAP-GTC/Response messages MUST be processed
      according to the rules of the [RFC4013] profile of [RFC3454].
      Furthermore, the strings in question SHALL be considered to be
      "stored strings" (per [RFC3454]), and unassigned code points are
      therefore prohibited.  The output SHALL be the binary
      representation of the processed UTF-8 character string.
      Prohibited output and unassigned codepoints encountered during
      SASLprep pre-processing SHALL cause a failure of pre-processing,
      and the output MUST NOT be used.
   o  In addition, TEAM supports the use of username/password
      authentication that allows for an EAP peer and EAP server to
      authenticate each other based on knowledge of a password without
      that password being sent in any format between the peer and
      server.
   o  The TEAM server is authenticated before any possible transmission
      of a password and a peer can check whether the certificate of a
      TEAM server has been revoked or not using OCSP.





Zorn, et al.            Expires September 9, 2011              [Page 72]


Internet-Draft                    TEAM                        March 2011


A.6.  Requirements Around Carriage of EAP Methods

   o  TEAM supports carrying inner EAP methods without modification.
      These methods are negotiated and can be chained.
   o  TEAM supports cryptographic binding of keys derived from EAP
      methods.

Authors' Addresses

   Glen Zorn
   Network Zen
   227/358 Thanon Sanphawut
   Bang Na, Bangkok  10260
   Thailand

   Phone: +66 (0) 87-040-4617
   EMail: gwz@net-zen.net


   Qin Wu
   Huawei Technologies Co., Ltd.
   101 Software Avenue, Yuhua District
   Nanjing, Jiangsu  21001
   China

   Phone: +86-25-84565892
   EMail: sunseawq@huawei.com


   Dan Harkins
   Aruba Networks
   1322 Crossman Avenue
   Sunnyvale, CA  94089-1113
   United States of America

   EMail: dharkins@arubanetworks.com















Zorn, et al.            Expires September 9, 2011              [Page 73]