RFC 7170
Tunnel Extensible Authentication Protocol (TEAP) Version 1
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
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.
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.
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
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)
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.
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
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
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
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
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]
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].
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
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.
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
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.
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
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.
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.
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
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...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
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
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.
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
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).
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
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
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.
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...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
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.
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
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.
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)
