tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search     info

RFC 7170

 
 
 

Tunnel Extensible Authentication Protocol (TEAP) Version 1

Part 2 of 4, p. 24 to 58
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 24 
4.  Message Formats

   The following sections describe the message formats used in TEAP.
   The fields are transmitted from left to right in network byte order.

4.1.  TEAP Message Format

   A summary of the TEAP Request/Response packet format is shown below.

    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 |        Message Length         :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :         Message Length        |         Outer TLV Length
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :     Outer TLV Length          |         TLS Data...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       Outer TLVs...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Code

      The Code field is one octet in length and is defined as follows:

         1 Request

         2 Response

Top      Up      ToC       Page 25 
   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 the 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, Ver,
      Message Length, TLS Data, and Outer TLVs fields.  Octets outside
      the range of the Length field should be treated as Data Link Layer
      padding and should be ignored on reception.

   Type

      55 for TEAP

   Flags

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

      L  Length included; set to indicate the presence of the four-octet
         Message Length field.  It MUST be present for the first
         fragment of a fragmented message.  It MUST NOT be present for
         any other message.

      M  More fragments; set on all but the last fragment.

      S  TEAP start; set in a TEAP Start message sent from the server to
         the peer.

      O  Outer TLV length included; set to indicate the presence of the
         four-octet Outer TLV Length field.  It MUST be present only in
         the initial request and response messages.  If the initial
         message is fragmented, then it MUST be present only on the
         first fragment.

      R  Reserved (MUST be zero and ignored upon receipt)

   Ver

      This field contains the version of the protocol.  This document
      describes version 1 (001 in binary) of TEAP.

Top      Up      ToC       Page 26 
   Message Length

      The Message Length field is four octets and is present only if the
      L bit is set.  This field provides the total length of the message
      that may be fragmented over the data fields of multiple packets.

   Outer TLV Length

      The Outer TLV Length field is four octets and is present only if
      the O bit is set.  This field provides the total length of the
      Outer TLVs if present.

   TLS Data

      When the TLS Data field is present, it consists of an encapsulated
      TLS packet in TLS record format.  A TEAP packet with Flags and
      Version fields, but with zero length TLS Data field, is used to
      indicate TEAP acknowledgement for either a fragmented message, a
      TLS Alert message, or a TLS Finished message.

   Outer TLVs

      The Outer TLVs consist of the optional data used to help establish
      the TLS tunnel in TLV format.  They are only allowed in the first
      two messages in the TEAP protocol.  That is the first EAP-server-
      to-peer message and first peer-to-EAP-server message.  The start
      of the Outer TLVs can be derived from the EAP Length field and
      Outer TLV Length field.

4.2.  TEAP TLV Format and Support

   The TLVs defined here are TLV objects.  The TLV objects could be used
   to carry arbitrary parameters between an EAP peer and EAP server
   within the protected TLS tunnel.

   The EAP peer may not necessarily implement all the TLVs supported by
   the EAP server.  To allow for interoperability, TLVs are designed to
   allow an EAP server to discover if a TLV is supported by the EAP peer
   using the NAK TLV.  The mandatory bit in a TLV indicates whether
   support of the TLV is required.  If the peer or server does not
   support a TLV marked mandatory, then it MUST send a NAK TLV in the
   response, and all the other TLVs in the message MUST be ignored.  If
   an EAP peer or server finds an unsupported TLV that is marked as
   optional, it can ignore the unsupported TLV.  It MUST NOT send a NAK
   TLV for a TLV that is not marked mandatory.  If all TLVs in a message
   are marked optional and none are understood by the peer, then a NAK
   TLV or Result TLV could be sent to the other side in order to
   continue the conversation.

Top      Up      ToC       Page 27 
   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
   individual TLV specification.

   EAP implementations compliant with this specification MUST support
   TLV exchanges as well as the processing of mandatory/optional
   settings on the TLV.  Implementations conforming to this
   specification MUST support the following TLVs:

      Authority-ID TLV

      Identity-Type TLV

      Result TLV

      NAK TLV

      Error TLV

      Request-Action TLV

      EAP-Payload TLV

      Intermediate-Result TLV

      Crypto-Binding TLV

      Basic-Password-Auth-Req TLV

      Basic-Password-Auth-Resp TLV

Top      Up      ToC       Page 28 
4.2.1.  General 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:

      0  Unassigned

      1  Authority-ID TLV (Section 4.2.2)

      2  Identity-Type TLV (Section 4.2.3)

      3  Result TLV (Section 4.2.4)

      4  NAK TLV (Section 4.2.5)

      5  Error TLV (Section 4.2.6)

      6  Channel-Binding TLV (Section 4.2.7)

      7  Vendor-Specific TLV (Section 4.2.8)

      8  Request-Action TLV (Section 4.2.9)

      9  EAP-Payload TLV (Section 4.2.10)

      10 Intermediate-Result TLV (Section 4.2.11)

Top      Up      ToC       Page 29 
      11 PAC TLV (Section 4.2.12)

      12 Crypto-Binding TLV (Section 4.2.13)

      13 Basic-Password-Auth-Req TLV (Section 4.2.14)

      14 Basic-Password-Auth-Resp TLV (Section 4.2.15)

      15 PKCS#7 TLV (Section 4.2.16)

      16 PKCS#10 TLV (Section 4.2.17)

      17 Trusted-Server-Root TLV (Section 4.2.18)

   Length

      The length of the Value field in octets.

   Value

      The value of the TLV.

4.2.2.  Authority-ID TLV

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

   M

      Mandatory, set to one (1)

   R

      Reserved, set to zero (0)

   TLV Type

      1 - Authority-ID

   Length

      The Length field is two octets and contains the length of the ID
      field in octets.

Top      Up      ToC       Page 30 
   ID

      Hint of the identity of the server to help the peer to match the
      credentials available for the server.  It should be unique across
      the deployment.

4.2.3.  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.  TEAPv1 implementations MUST support this TLV.  Only one
   Identity-Type TLV SHOULD be present in the TEAP request or response
   packet.  The Identity-Type TLV request MUST come with an EAP-Payload
   TLV or Basic-Password-Auth-Req TLV.  If the EAP peer does have an
   identity corresponding to the identity type requested, then the peer
   SHOULD respond with an Identity-Type TLV with the requested type.  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 requested, then the peer SHOULD respond with an
   Identity-Type TLV with the one of available identity types.  If the
   server receives an identity type in the response that does not match
   the requested type, then the peer does not possess the requested
   credential type, and the server SHOULD proceed with authentication
   for the credential type proposed by the peer, proceed with requesting
   another credential type, or simply apply the network policy based on
   the configured policy, e.g., sending Result TLV with Failure.

   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

      Reserved, set to zero (0)

   TLV Type

      2 - Identity-Type TLV

Top      Up      ToC       Page 31 
   Length

      2

   Identity-Type

      The Identity-Type field is two octets.  Values include:

      1  User

      2  Machine

4.2.4.  Result TLV

   The Result TLV provides support for acknowledged success and failure
   messages for protected termination within TEAP.  If the Status field
   does not contain one of the known values, then the peer or EAP server
   MUST treat this as a fatal error of Unexpected TLVs Exchanged.  The
   behavior of the Result TLV is further discussed in Sections 3.3.3 and
   3.6.3.  A Result TLV indicating failure MUST NOT be accompanied by
   the following TLVs: NAK, EAP-Payload TLV, or Crypto-Binding TLV.  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

      Mandatory, set to one (1)

   R

      Reserved, set to zero (0)

   TLV Type

      3 - Result TLV

   Length

      2

Top      Up      ToC       Page 32 
   Status

      The Status field is two octets.  Values include:

      1  Success

      2  Failure

4.2.5.  NAK TLV

   The NAK TLV allows a peer to detect TLVs that are not supported by
   the other peer.  A TEAP packet can contain 0 or more NAK TLVs.  A NAK
   TLV should not be accompanied by other TLVs.  A NAK TLV MUST NOT be
   sent in response to a message containing a Result TLV, instead a
   Result TLV of failure should be sent indicating failure and an Error
   TLV of Unexpected TLVs Exchanged.  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

      Mandatory, set to one (1)

   R

      Reserved, set to zero (0)

   TLV Type

      4 - NAK TLV

   Length

      >=6

   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 three octets are the Structure of Management

Top      Up      ToC       Page 33 
      Information (SMI) Network Management Private Enterprise Number of
      the Vendor in network byte order.  The Vendor-Id field MUST be
      zero for TLVs that are not Vendor-Specific TLVs.

   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 zero or more TLVs, each of which
      MUST NOT have the mandatory bit set.  These optional TLVs are for
      future extensibility to communicate why the offending TLV was
      determined to be unsupported.

4.2.6.  Error TLV

   The Error TLV allows an EAP peer or server to indicate errors to the
   other party.  A TEAP packet can contain 0 or more Error TLVs.  The
   Error-Code field describes the type of error.  Error codes 1-999
   represent successful outcomes (informative messages), 1000-1999
   represent warnings, and 2000-2999 represent fatal errors.  A fatal
   Error TLV MUST be accompanied by a Result TLV indicating failure, and
   the conversation is terminated as described in Section 3.6.3.

   Many of the error codes below refer to errors in inner method
   processing that may be retrieved if made available by the inner
   method.  Implementations MUST take care that error messages do not
   reveal too much information to an attacker.  For example, the usage
   of error message 1031 (User account credentials incorrect) is NOT
   RECOMMENDED, because it allows an attacker to determine valid
   usernames by differentiating this response from other responses.  It
   should only be used for troubleshooting purposes.

   The Error 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                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Top      Up      ToC       Page 34 
   M

      Mandatory, set to one (1)

   R

      Reserved, set to zero (0)

   TLV Type

      5 - Error TLV

   Length

      4

   Error-Code

      The Error-Code field is four octets.  Currently defined values for
      Error-Code include:

      1     User account expires soon

      2     User account credential expires soon

      3     User account authorizations change soon

      4     Clock skew detected

      5     Contact administrator

      6     User account credentials change required

      1001  Inner Method Error

      1002  Unspecified authentication infrastructure problem

      1003  Unspecified authentication failure

      1004  Unspecified authorization failure

      1005  User account credentials unavailable

      1006  User account expired

      1007  User account locked: try again later

      1008  User account locked: admin intervention required

Top      Up      ToC       Page 35 
      1009  Authentication infrastructure unavailable

      1010  Authentication infrastructure not trusted

      1011  Clock skew too great

      1012  Invalid inner realm

      1013  Token out of sync: administrator intervention required

      1014  Token out of sync: PIN change required

      1015  Token revoked

      1016  Tokens exhausted

      1017  Challenge expired

      1018  Challenge algorithm mismatch

      1019  Client certificate not supplied

      1020  Client certificate rejected

      1021  Realm mismatch between inner and outer identity

      1022  Unsupported Algorithm In Certificate Signing Request

      1023  Unsupported Extension In Certificate Signing Request

      1024  Bad Identity In Certificate Signing Request

      1025  Bad Certificate Signing Request

      1026  Internal CA Error

      1027  General PKI Error

      1028  Inner method's channel-binding data required but not
            supplied

      1029  Inner method's channel-binding data did not include required
            information

      1030  Inner method's channel binding failed

      1031  User account credentials incorrect [USAGE NOT RECOMMENDED]

Top      Up      ToC       Page 36 
      2001  Tunnel Compromise Error

      2002  Unexpected TLVs Exchanged

4.2.7.  Channel-Binding TLV

   The Channel-Binding TLV provides a mechanism for carrying channel-
   binding data from the peer to the EAP server and a channel-binding
   response from the EAP server to the peer as described in [RFC6677].
   TEAPv1 implementations MAY support this TLV, which cannot be
   responded to with a NAK TLV.  If the Channel-Binding data field does
   not contain one of the known values or if the EAP server does not
   support this TLV, then the server MUST ignore the value.  The
   Channel-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             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Data ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   M

      0 (Optional)

   R

      Reserved, set to zero (0)

   TLV Type

      6 - Channel-Binding TLV

   Length

      variable

   Data

      The data field contains a channel-binding message as defined in
      Section 5.3 of [RFC6677].

Top      Up      ToC       Page 37 
4.2.8.  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 attribute can contain one or more TLVs, referred
   to as Vendor TLVs.  The TLV type of a Vendor-TLV is defined by the
   vendor.  All the Vendor TLVs inside a single Vendor-Specific TLV
   belong to the same vendor.  There can be multiple Vendor-Specific
   TLVs from different vendors in the same message.  Error handling in
   the Vendor TLV could use the vendor's own specific error-handling
   mechanism or use the standard TEAP error codes defined.

   Vendor TLVs may be optional or mandatory.  Vendor TLVs sent with
   Result TLVs MUST be marked as optional.  If the Vendor-Specific TLV
   is marked as mandatory, then it is expected that the receiving side
   needs to recognize the vendor ID, parse all Vendor TLVs within, and
   deal with error handling within the Vendor-Specific TLV as defined by
   the vendor.

   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

      0 or 1

   R

      Reserved, set to zero (0)

   TLV Type

      7 - Vendor-Specific TLV

   Length

      4 + cumulative length of all included Vendor TLVs

   Vendor-Id

Top      Up      ToC       Page 38 
      The Vendor-Id field is four octets and contains the Vendor-Id of
      the TLV.  The high-order octet is 0, and the low-order 3 octets
      are the SMI Network Management Private Enterprise Number of the
      Vendor in network byte order.

   Vendor TLVs

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

4.2.9.  Request-Action TLV

   The Request-Action TLV MAY be sent by both the peer and the server in
   response to a successful or failed Result TLV.  It allows the peer or
   server to request the other side to negotiate additional EAP methods
   or process TLVs specified in the response packet.  The receiving side
   MUST process this TLV.  The processing for the TLV is as follows:

      The receiving entity MAY choose to process any of the TLVs that
      are included in the message.

      If the receiving entity chooses NOT to process any TLV in the
      list, then it sends back a Result TLV with the same code in the
      Status field of the Request-Action TLV.

      If multiple Request-Action TLVs are in the request, the session
      can continue if any of the TLVs in any Request-Action TLV are
      processed.

      If multiple Request-Action TLVs are in the request and none of
      them is processed, then the most fatal status should be used in
      the Result TLV returned.  If a status code in the Request-Action
      TLV is not understood by the receiving entity, then it should be
      treated as a fatal error.

      After processing the TLVs or EAP method in the request, another
      round of Result TLV exchange would occur to synchronize the final
      status on both sides.

   The peer or the server MAY send multiple Request-Action TLVs to the
   other side.  Two Request-Action TLVs MUST NOT occur in the same TEAP
   packet if they have the same Status value.  The order of processing
   multiple Request-Action TLVs is implementation dependent.  If the
   receiving side processes the optional (non-fatal) items first, it is
   possible that the fatal items will disappear at a later time.  If the
   receiving side processes the fatal items first, the communication
   time will be shorter.

Top      Up      ToC       Page 39 
   The peer or the server MAY return a new set of Request-Action TLVs
   after one or more of the requested items has been processed and the
   other side has signaled it wants to end the EAP conversation.

   The Request-Action 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   |      Action    |                TLVs....
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-

   M

      Mandatory, set to one (1)

   R

      Reserved, set to zero (0)

   TLV Type

      8 - Request-Action TLV

   Length

      2 + cumulative length of all included TLVs

   Status

      The Status field is one octet.  This indicates the result if the
      server does not process the action requested by the peer.  Values
      include:

      1  Success

      2  Failure

   Action

      The Action field is one octet.  Values include:

      1  Process-TLV

      2  Negotiate-EAP

Top      Up      ToC       Page 40 
   TLVs

      This field is of indefinite length.  It contains TLVs that the
      peer wants the server to process.

4.2.10.  EAP-Payload TLV

   To allow piggybacking an EAP request or response with other TLVs, the
   EAP-Payload TLV is defined, which includes an encapsulated EAP packet
   and a list of optional TLVs.  The optional TLVs are provided for
   future extensibility to provide hints about the current EAP
   authentication.  Only one EAP-Payload TLV is allowed in a message.
   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

      Mandatory, set to one (1)

   R

      Reserved, set to zero (0)

   TLV Type

      9 - EAP-Payload TLV

   Length

      length of embedded EAP packet + cumulative length of additional
      TLVs

   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.

Top      Up      ToC       Page 41 
   TLVs

      This (optional) field contains a list of TLVs associated with the
      EAP packet field.  The TLVs 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.

4.2.11.  Intermediate-Result TLV

   The Intermediate-Result TLV provides support for acknowledged
   intermediate Success and Failure messages between multiple inner EAP
   methods within EAP.  An Intermediate-Result TLV indicating success
   MUST be accompanied by a Crypto-Binding TLV.  The optional TLVs
   associated with this TLV are provided for future extensibility to
   provide hints about the current result.  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

      Mandatory, set to one (1)

   R

      Reserved, set to zero (0)

   TLV Type

      10 - Intermediate-Result TLV

   Length

      2 + cumulative length of the embedded associated TLVs

   Status

      The Status field is two octets.  Values include:

      1  Success

Top      Up      ToC       Page 42 
      2  Failure

   TLVs

      This field is of indeterminate length and contains zero or more of
      the TLVs associated with the Intermediate Result TLV.  The TLVs in
      this field MUST NOT have the mandatory bit set.

4.2.12.  PAC TLV Format

   The PAC TLV provides support for provisioning the Protected Access
   Credential (PAC).  The PAC TLV carries the PAC and related
   information within PAC attribute fields.  Additionally, the PAC TLV
   MAY be used by the peer to request provisioning of a PAC of the type
   specified in the PAC-Type PAC attribute.  The PAC TLV MUST only be
   used in a protected tunnel providing encryption and integrity
   protection.  A general PAC TLV format 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             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        PAC Attributes...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   M

      0 or 1

   R

      Reserved, set to zero (0)

   TLV Type

      11 - PAC TLV

   Length

      Two octets containing the length of the PAC Attributes field in
      octets.

   PAC Attributes

      A list of PAC attributes in the TLV format.

Top      Up      ToC       Page 43 
4.2.12.1.  Formats for PAC Attributes

   Each PAC attribute in a PAC TLV is formatted as a TLV 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Type               |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              Value...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type

      The Type field is two octets, denoting the attribute type.
      Allocated types include:

         1 - PAC-Key

         2 - PAC-Opaque

         3 - PAC-Lifetime

         4 - A-ID

         5 - I-ID

         6 - Reserved

         7 - A-ID-Info

         8 - PAC-Acknowledgement

         9 - PAC-Info

         10 - PAC-Type

   Length

      Two octets containing the length of the Value field in octets.

   Value

      The value of the PAC attribute.

Top      Up      ToC       Page 44 
4.2.12.2.  PAC-Key

   The PAC-Key is a secret key distributed in a PAC attribute of type
   PAC-Key.  The PAC-Key attribute is included within the PAC TLV
   whenever the server wishes to issue or renew a PAC that is bound to a
   key such as a Tunnel PAC.  The key is a randomly generated octet
   string that is 48 octets in length.  The generator of this key is the
   issuer of the credential, which is identified by the Authority
   Identifier (A-ID).

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Type               |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                              Key                              ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type

      1 - PAC-Key

   Length

      2-octet length indicating the length of the key.

   Key

      The value of the PAC-Key.

4.2.12.3.  PAC-Opaque

   The PAC-Opaque attribute is included within the PAC TLV whenever the
   server wishes to issue or renew a PAC.

   The PAC-Opaque is opaque to the peer, and thus the peer MUST NOT
   attempt to interpret it.  A peer that has been issued a PAC-Opaque by
   a server stores that data and presents it back to the server
   according to its PAC-Type.  The Tunnel PAC is used in the ClientHello
   SessionTicket extension field defined in [RFC5077].  If a peer has
   opaque data issued to it by multiple servers, then it stores the data
   issued by each server separately according to the A-ID.  This
   requirement allows the peer to maintain and use each opaque datum as
   an independent PAC pairing, with a PAC-Key mapping to a PAC-Opaque
   identified by the A-ID.  As there is a one-to-one correspondence
   between the PAC-Key and PAC-Opaque, the peer determines the PAC-Key

Top      Up      ToC       Page 45 
   and corresponding PAC-Opaque based on the A-ID provided in the
   TEAP/Start message and the A-ID provided in the PAC-Info when it was
   provisioned with a PAC-Opaque.

   The PAC-Opaque attribute format is summarized 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Type               |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              Value ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type

      2 - PAC-Opaque

   Length

      The Length field is two octets, which contains the length of the
      Value field in octets.

   Value

      The Value field contains the actual data for the PAC-Opaque.  It
      is specific to the server implementation.

4.2.12.4.  PAC-Info

   The PAC-Info is comprised of a set of PAC attributes as defined in
   Section 4.2.12.1.  The PAC-Info attribute MUST contain the A-ID,
   A-ID-Info, and PAC-Type attributes.  Other attributes MAY be included
   in the PAC-Info to provide more information to the peer.  The
   PAC-Info attribute MUST NOT contain the PAC-Key, PAC-Acknowledgement,
   PAC-Info, or PAC-Opaque attributes.  The PAC-Info attribute is
   included within the PAC TLV whenever the server wishes to issue or
   renew a PAC.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Type               |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Attributes...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Top      Up      ToC       Page 46 
   Type

      9 - PAC-Info

   Length

      2-octet field containing the length of the Attributes field in
      octets.

   Attributes

      The Attributes field contains a list of PAC attributes.  Each
      mandatory and optional field type is defined as follows:

      3 - PAC-Lifetime

         This is a 4-octet quantity representing the expiration time of
         the credential expressed as the number of seconds, excluding
         leap seconds, after midnight UTC, January 1, 1970.  This
         attribute MAY be provided to the peer as part of the PAC-Info.

      4 - A-ID

         The A-ID is the identity of the authority that issued the PAC.
         The A-ID is intended to be unique across all issuing servers to
         avoid namespace collisions.  The A-ID is used by the peer to
         determine which PAC to employ.  The A-ID is treated as an
         opaque octet string.  This attribute MUST be included in the
         PAC-Info attribute.  The A-ID MUST match the Authority-ID the
         server used to establish the tunnel.  One method for generating
         the A-ID is to use a high-quality random number generator to
         generate a random number.  An alternate method would be to take
         the hash of the public key or public key certificate belonging
         to a server represented by the A-ID.

      5 - I-ID

         Initiator Identifier (I-ID) is the peer identity associated
         with the credential.  This identity is derived from the inner
         authentication or from the client-side authentication during
         tunnel establishment if inner authentication is not used.  The
         server employs the I-ID in the TEAP Phase 2 conversation to
         validate that the same peer identity used to execute TEAP Phase
         1 is also used in at minimum one inner authentication in TEAP
         Phase 2.  If the server is enforcing the I-ID validation on the
         inner authentication, then the I-ID MUST be included in the
         PAC-Info, to enable the peer to also enforce a unique PAC for
         each unique user.  If the I-ID is missing from the PAC-Info, it

Top      Up      ToC       Page 47 
         is assumed that the Tunnel PAC can be used for multiple users
         and the peer will not enforce the unique-Tunnel-PAC-per-user
         policy.

      7 - A-ID-Info

         Authority Identifier Information is intended to provide a user-
         friendly name for the A-ID.  It may contain the enterprise name
         and server name in a human-readable format.  This TLV serves as
         an aid to the peer to better inform the end user about the
         A-ID.  The name is encoded in UTF-8 [RFC3629] format.  This
         attribute MUST be included in the PAC-Info.

      10 - PAC-Type

         The PAC-Type is intended to provide the type of PAC.  This
         attribute SHOULD be included in the PAC-Info.  If the PAC-Type
         is not present, then it defaults to a Tunnel PAC (Type 1).

4.2.12.5.  PAC-Acknowledgement TLV

   The PAC-Acknowledgement is used to acknowledge the receipt of the
   Tunnel PAC by the peer.  The peer includes the PAC-Acknowledgement
   TLV in a PAC TLV sent to the server to indicate the result of the
   processing and storing of a newly provisioned Tunnel PAC.  This TLV
   is only used when Tunnel PAC is provisioned.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Type               |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Result             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type

      8 - PAC-Acknowledgement

   Length

      The length of this field is two octets containing a value of 2.

   Result

      The resulting value MUST be one of the following:

         1 - Success

Top      Up      ToC       Page 48 
         2 - Failure

4.2.12.6.  PAC-Type TLV

   The PAC-Type TLV is a TLV intended to specify the PAC-Type.  It is
   included in a PAC TLV sent by the peer to request PAC provisioning
   from the server.  Its format is described below:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Type               |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         PAC-Type              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type

      10 - PAC-Type

   Length

      2-octet field with a value of 2.

   PAC-Type

      This 2-octet field defines the type of PAC being requested or
      provisioned.  The following values are defined:

               1 - Tunnel PAC

4.2.13.  Crypto-Binding TLV

   The Crypto-Binding TLV is used to prove that both the peer and server
   participated in the tunnel establishment and sequence of
   authentications.  It also provides verification of the TEAP type,
   version negotiated, and Outer TLVs exchanged before the TLS tunnel
   establishment.

   The Crypto-Binding TLV MUST be exchanged and verified before the
   final Result TLV exchange, regardless of whether there is an inner
   EAP method authentication or not.  It MUST be included with the
   Intermediate-Result TLV to perform cryptographic binding after each
   successful EAP method in a sequence of EAP methods, before proceeding
   with another inner EAP method.  The Crypto-Binding TLV is valid only
   if the following checks pass:

   o  The Crypto-Binding TLV version is supported.

Top      Up      ToC       Page 49 
   o  The MAC verifies correctly.

   o  The received version in the Crypto-Binding TLV matches the version
      sent by the receiver during the EAP version negotiation.

   o  The subtype is set to the correct value.

   If any of the above checks fails, then the TLV is invalid.  An
   invalid Crypto-Binding TLV is a fatal error and is handled as
   described in Section 3.6.3

   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.| Flags|Sub-Type|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                             Nonce                             ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                   EMSK Compound MAC                           ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                    MSK Compound MAC                           ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   M

      Mandatory, set to one (1)

   R

      Reserved, set to zero (0)

   TLV Type

      12 - Crypto-Binding TLV

   Length

      76

Top      Up      ToC       Page 50 
   Reserved

      Reserved, set to zero (0)

   Version

      The Version field is a single octet, which is set to the version
      of Crypto-Binding TLV the TEAP method is using.  For an
      implementation compliant with this version of TEAP, the version
      number MUST be set to one (1).

   Received Ver

      The Received Ver field is a single octet and MUST be set to the
      TEAP version number received during version negotiation.  Note
      that this field only provides protection against downgrade
      attacks, where a version of EAP requiring support for this TLV is
      required on both sides.

   Flags

      The Flags field is four bits.  Defined values include

      1  EMSK Compound MAC is present

      2  MSK Compound MAC is present

      3  Both EMSK and MSK Compound MAC are present

   Sub-Type

      The Sub-Type field is four bits.  Defined 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.  The nonce in a request MUST have its least significant bit
      set to zero (0), and the nonce in a response MUST have the same
      value as the request nonce except the least significant bit MUST
      be set to one (1).

Top      Up      ToC       Page 51 
   EMSK Compound MAC

      The EMSK Compound MAC field is 20 octets.  This can be the Server
      MAC (B1_MAC) or the Client MAC (B2_MAC).  The computation of the
      MAC is described in Section 5.3.

   MSK Compound MAC

      The MSK Compound MAC field is 20 octets.  This can be the Server
      MAC (B1_MAC) or the Client MAC (B2_MAC).  The computation of the
      MAC is described in Section 5.3.

4.2.14.  Basic-Password-Auth-Req TLV

   The Basic-Password-Auth-Req TLV is used by the authentication server
   to request a username and password from the peer.  It contains an
   optional user prompt message for the request.  The peer is expected
   to obtain the username and password and send them in a Basic-
   Password-Auth-Resp TLV.

   The Basic-Password-Auth-Req 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             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Prompt ....
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   M

      0 (Optional)

   R

      Reserved, set to zero (0)

   TLV Type

      13 - Basic-Password-Auth-Req TLV

   Length

      variable

Top      Up      ToC       Page 52 
   Prompt

      optional user prompt message in UTF-8 [RFC3629] format

4.2.15.  Basic-Password-Auth-Resp TLV

   The Basic-Password-Auth-Resp TLV is used by the peer to respond to a
   Basic-Password-Auth-Req TLV with a username and password.  The TLV
   contains a username and password.  The username and password are in
   UTF-8 [RFC3629] format.

   The Basic-Password-Auth-Resp 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             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Userlen     |             Username
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         ...     Username    ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Passlen     |             Password
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         ...     Password    ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   M

      0 (Optional)

   R

      Reserved, set to zero (0)

   TLV Type

      14 - Basic-Password-Auth-Resp TLV

   Length

      variable

   Userlen

      Length of Username field in octets

Top      Up      ToC       Page 53 
   Username

      Username in UTF-8 [RFC3629] format

   Passlen

      Length of Password field in octets

   Password

      Password in UTF-8 [RFC3629] format

4.2.16.  PKCS#7 TLV

   The PKCS#7 TLV is used by the EAP server to deliver certificate(s) to
   the peer.  The format consists of a certificate or certificate chain
   in binary DER encoding [X.690] in a degenerate Certificates Only
   PKCS#7 SignedData Content as defined in [RFC5652].

   When used in response to a Trusted-Server-Root TLV request from the
   peer, the EAP server MUST send the PKCS#7 TLV inside a Trusted-
   Server-Root TLV.  When used in response to a PKCS#10 certificate
   enrollment request from the peer, the EAP server MUST send the PKCS#7
   TLV without a Trusted-Server-Root TLV.  The PKCS#7 TLV is always
   marked as optional, which cannot be responded to with a NAK TLV.
   TEAP implementations that support the Trusted-Server-Root TLV or the
   PKCS#10 TLV MUST support this TLV.  Peers MUST NOT assume that the
   certificates in a PKCS#7 TLV are in any order.

   TEAP servers MAY return self-signed certificates.  Peers that handle
   self-signed certificates or trust anchors MUST NOT implicitly trust
   these certificates merely due to their presence in the certificate
   bag.  Note: Peers are advised to take great care in deciding whether
   to use a received certificate as a trust anchor.  The authenticated
   nature of the tunnel in which a PKCS#7 bag is received can provide a
   level of authenticity to the certificates contained therein.  Peers
   are advised to take into account the implied authority of the EAP
   server and to constrain the trust it can achieve through the trust
   anchor received in a PKCS#7 TLV.

Top      Up      ToC       Page 54 
   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 TLV

   R

      Reserved, set to zero (0)

   TLV Type

      15 - PKCS#7 TLV

   Length

      The length of the PKCS#7 Data field.

   PKCS#7 Data

      This field contains the DER-encoded X.509 certificate or
      certificate chain in a Certificates-Only PKCS#7 SignedData
      message.

4.2.17.  PKCS#10 TLV

   The PKCS#10 TLV is used by the peer to initiate the "simple PKI"
   Request/Response from [RFC5272].  The format of the request is as
   specified in Section 6.4 of [RFC4945].  The PKCS#10 TLV is always
   marked as optional, which cannot be responded to with a NAK TLV.

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

Top      Up      ToC       Page 55 
   M

      0 - Optional TLV

   R

      Reserved, set to zero (0)

   TLV Type

      16 - PKCS#10 TLV

   Length

      The length of the PKCS#10 Data field.

   PKCS#10 Data

      This field contains the DER-encoded PKCS#10 certificate request.

4.2.18.  Trusted-Server-Root TLV

   Trusted-Server-Root TLV facilitates the request and delivery of a
   trusted server root certificate.  The Trusted-Server-Root TLV can be
   exchanged in regular TEAP authentication mode or provisioning mode.
   The Trusted-Server-Root TLV is always marked as optional and cannot
   be responded to with a Negative Acknowledgement (NAK) TLV.  The
   Trusted-Server-Root TLV MUST only be sent as an Inner TLV (inside the
   protection of the tunnel).

   After the peer has determined that it has successfully authenticated
   the EAP server and validated the Crypto-Binding TLV, it MAY send one
   or more Trusted-Server-Root TLVs (marked as optional) to request the
   trusted server root certificates from the EAP server.  The EAP server
   MAY send one or more root certificates with a Public Key
   Cryptographic System #7 (PKCS#7) TLV inside the Trusted-Server-Root
   TLV.  The EAP server MAY also choose not to honor the request.

   The Trusted-Server-Root TLV allows the peer to send a request to the
   EAP server for a list of trusted roots.  The server may respond with
   one or more root certificates in PKCS#7 [RFC2315] format.

   If the EAP server sets the credential format to PKCS#7-Server-
   Certificate-Root, then the Trusted-Server-Root TLV should contain the
   root of the certificate chain of the certificate issued to the EAP
   server packaged in a PKCS#7 TLV.  If the server certificate is a
   self-signed certificate, then the root is the self-signed
   certificate.

Top      Up      ToC       Page 56 
   If the Trusted-Server-Root TLV credential format contains a value
   unknown to the peer, then the EAP peer should ignore the TLV.

   The Trusted-Server-Root 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             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Credential-Format   |     Cred TLVs...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

   M

      0 - Optional TLV

   R

      Reserved, set to zero (0)

   TLV Type

      17 - Trusted-Server-Root TLV

   Length

      >=2 octets

   Credential-Format

      The Credential-Format field is two octets.  Values include:

      1 - PKCS#7-Server-Certificate-Root

   Cred TLVs

      This field is of indefinite length.  It contains TLVs associated
      with the credential format.  The peer may leave this field empty
      when using this TLV to request server trust roots.

4.3.  TLV Rules

   To save round trips, multiple TLVs can be sent in a single TEAP
   packet.  However, multiple EAP Payload TLVs, multiple Basic Password
   Authentication TLVs, or an EAP Payload TLV with a Basic Password
   Authentication TLV within one single TEAP packet is not supported in
   this version and MUST NOT be sent.  If the peer or EAP server

Top      Up      ToC       Page 57 
   receives multiple EAP Payload TLVs, then it MUST terminate the
   connection with the Result TLV.  The order of TLVs in TEAP does not
   matter, except one should always process the Identity-Type TLV before
   processing the EAP TLV or Basic Password Authentication TLV as the
   Identity-Type TLV is a hint to the type of identity that is to be
   authenticated.

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

   0     This TLV MUST NOT be present in the message.

   0+    Zero or more instances of this TLV MAY be present in the
         message.

   0-1   Zero or one instance of this TLV MAY be present in the message.

   1     Exactly one instance of this TLV MUST be present in the
         message.

4.3.1.  Outer TLVs

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

   Request  Response    Success   Failure   TLVs
   0-1      0           0         0         Authority-ID
   0-1      0-1         0         0         Identity-Type
   0+       0+          0         0         Vendor-Specific

   Outer TLVs MUST be marked as optional.  Vendor-TLVs inside 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 TEAP
   messages sent by peer and EAP-server respectively.  That is 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.  If Outer TLVs are included in messages after the first
   two TEAP messages, they MUST be ignored.

4.3.2.  Inner TLVs

   The following table provides a guide to which Inner TLVs may be
   encapsulated in TLS in TEAP Phase 2, in which kind of packets, and in
   what quantity.  The messages are as follows: Request is a TEAP
   Request, Response is a TEAP Response, Success is a message containing
   a successful Result TLV, and Failure is a message containing a failed
   Result TLV.

Top      Up      ToC       Page 58 
   Request  Response    Success   Failure   TLVs
   0-1      0-1         0         0         Identity-Type
   0-1      0-1         1         1         Result
   0+       0+          0         0         NAK
   0+       0+          0+        0+        Error
   0-1      0-1         0         0         Channel-Binding
   0+       0+          0+        0+        Vendor-Specific
   0+       0+          0+        0+        Request-Action
   0-1      0-1         0         0         EAP-Payload
   0-1      0-1         0-1       0-1       Intermediate-Result
   0+       0+          0+        0         PAC TLV
   0-1      0-1         0-1       0-1       Crypto-Binding
   0-1      0           0         0         Basic-Password-Auth-Req
   0        0-1         0         0         Basic-Password-Auth-Resp
   0-1      0           0-1       0         PKCS#7
   0        0-1         0         0         PKCS#10
   0-1      0-1         0-1       0         Trusted-Server-Root

   NOTE: Vendor TLVs (included in Vendor-Specific TLVs) sent with a
   Result TLV MUST be marked as optional.



(page 58 continued on part 3)

Next RFC Part