4. Message Formats
Questa sezione conserva il testo RFC per TEAPv1, inclusi TLS tunnel establishment, tunneled authentication, TLV formats, cryptographic calculations, IANA registries, security considerations ed examples.
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 acknowledgment 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. 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 only send a NAK
TLV for a TLV that is marked mandatory but is not understood and MUST
NOT otherwise send a NAK TLV. If all TLVs in a message are marked
optional and none are understood by the peer, then a Result TLV
SHOULD be sent to the other side in order to continue the
conversation. It is also possible to send a NAK TLV when all TLVs in
a message are marked optional.
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.
If a peer or server receives a TLV that is not of the correct format,
the TLV MUST be discarded. It is generally useful to log an error or
debugging message that indicates which TLV had an issue and what the
problem is. However, TLVs that are malformed are invalid and cannot
be used.
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 (DEPRECATED)
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)
18 CSR-Attributes TLV (Section 4.2.19)
19 Identity-Hint TLV (Section 4.2.20)
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
0 - Optional TLV
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.
A server sending the Identity-Type TLV MUST also include an EAP-
Payload TLV or a Basic-Password-Auth-Resp TLV. A peer sending an
Identity-Type TLV MUST also include EAP-Payload TLV or a Basic-
Password-Auth-Resp TLV.
An EAP peer receiving an Identity-Type request 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.
A server receiving an Identity-Type in the response MUST check if the
value of the Identity-Type in the response matches the value of the
Identity-Type that was sent in the request. A match means that the
server can proceed with authentication.
However, if the values do not match, the server can proceed with
authentication if and only if the following two conditions match. If
either of the following two conditions does not match, the server
MUST respond with a Result TLV of Failure.
1. The Identity-Type contains a value permitted by the server
configuration.
2. The Identity-Type value was not previously used for a successful
authentication.
The first condition allows a server to be configured to permit only
user authentication, or else only machine authentication. A server
could also use an Identity-Hint TLV sent in the response to permit
different types of authentication for different identities. A server
could also permit or forbid different kinds of authentication based
on other information, such an outer EAP Identity, fields in an outer
EAP client certificate, or other fields received in a RADIUS or
Diameter packet along with the TEAP session. There is no requirement
that a server has to support both user and machine authentication for
all TEAP sessions.
The second condition ensures that if a particular Inner Method
succeeds, the server does not attempt a subsequent Inner Method for
the same Identity-Type. For example, if a user is authenticated via
an Inner Method of EAP-TLS, there is no benefit to also requesting
additional authentication via a different Inner Method. Similarly,
there is no benefit to repeating an authentication sessions for the
same user; the result will not change.
This second condition also forbids multiple rounds of challenge/
response authentication via the Basic-Password-Auth-Req TLV. TEAPv1
supports only one round of Basic-Password-Auth-Req followed by Basic-
Password-Auth-Resp. The result of that round MUST NOT be another
Basic-Password-Auth-Req TLV.
This second condition also means that a server MUST NOT send an
Identity-Hint TLV that has the same value as was previously used for
a successful authentication.
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
Mandatory, set to one (1)
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.6.6 and
3.9.3.
A Result TLV indicating failure MUST NOT be accompanied by the
following TLVs: NAK, EAP-Payload, or Crypto-Binding.
A Result TLV indicating success MUST be accompanied by a 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.9.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]
1032 Inner Method not supported
2001 Tunnel Compromise Error
2002 Unexpected TLVs Exchanged
2003 The Crypto-Binding TLV is invalid (Version, Received-Ver, or
Sub-Type)
2004 The first Inner Method did not derive EMSK
2005 The Crypto-Binding TLV did not include a required MSK
Compound MAC
2006 The MSK Compound MAC fails verification
2007 The Crypto-Binding TLV did not include a required EMSK
Compound MAC
2008 The EMSK Compound MAC fails verification
2009 The EMSK Compound MAC exists, but the Inner Method did not
derive EMSK
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 TLV
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 particular 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.
Where a Vendor-Specific TLV carries an authentication protocol in the
Inner Method, it MUST define values for MSK and EMSK. Where these
values cannot be derived from cryptographic primitives, they MUST be
set to zero, as happens when Basic-Password-Auth-Req is used.
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 at any time. The Request-Action
TLV allows the peer or server to request that the other side
negotiates additional Inner Methods or process TLVs that are passed
inside of the Request-Action TLV.
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. Otherwise, the receiving entity MAY
send a Request-Action TLV containing an Error TLV of value 2002
(Unexpected TLVs Exchanged).
After processing the TLVs or Inner Method in the request, another
round of Result TLV exchange MUST 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 have 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
party who receives this TLV does not process the action. 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 coalescing 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 signals intermediate Success and Failure
messages for all inner methods. The Intermediate-Result TLV MUST be
used for all Inner Methods.
An Intermediate-Result TLV indicating success MUST be accompanied by
a Crypto-Binding TLV.
An Intermediate-Result TLV indicating failure SHOULD be accompanied
by an Error TLV that indicates why the authentication failed.
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
[RFC7170] defined a Protected Access Credential (PAC) to mirror EAP-
FAST [RFC4851]. However, implementation experience and analysis
determined that the PAC was not necessary. Instead, TEAP performs
session resumption using the NewSessionTicket message as defined in
Sections 2.1.2 and 2.1.3 of [RFC9190]. As such, the PAC TLV has been
deprecated.
As the PAC TLV is deprecated, an entity receiving it SHOULD send a
Result TLV indicating failure and an Error TLV of Unexpected TLVs
Exchanged.
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.
A Crypto-Binding MUST be accompanied by an Intermediate-Result TLV
indicating success.
The Crypto-Binding TLV MUST be exchanged and validated before any
Intermediate-Result or Result TLV value is examined, regardless of
whether there is an Inner Method or not. It MUST be included with
the Intermediate-Result TLV to perform cryptographic binding after
each successful Inner Method in a sequence of inner methods, before
proceeding with another Inner Method. If no MSK or EMSK has been
generated and a Crypto-Binding TLV is required, then the MSK Compound
MAC field contains the MAC using keys generated according to
Section 6.3.
The Crypto-Binding TLV is valid only if the following checks pass on
its contents:
* The Version field contain a known value.
* The Received-Ver field matches the TEAP version sent by the
receiver during the EAP version negotiation.
* The Sub-Type field is set to the correct value for this exchange.
* The Flags field is set to a known value.
* The Compound MAC(s) verify correctly.
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.9.3
See Section 6 for a more detailed discussion of how the Compound MAC
fields are constructed and verified.
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 TEAPv1, 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.
For TEAPv1, this version number MUST be set to one (1).
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
All other values of the Flags field are invalid.
Sub-Type
The Sub-Type field is four bits. Defined values include:
0 Binding Request
1 Binding Response
All other values of the Sub-Type field are invalid.
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 6.3.
Note that this field is always 20 octets in length. Any larger
MAC is simply truncated. All validations or comparisons MUST be
done on the truncated value.
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 6.3.
Note that this field is always 20 octets in length. Any larger
MAC is simply truncated. All validations or comparisons MUST be
done on the truncated value.
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
Mandatory, set to one (1)
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
Mandatory, set to one (1)
R
Reserved, set to zero (0)
TLV Type
14 - Basic-Password-Auth-Resp TLV
Length
variable
Userlen
Length of Username field in octets.
The value of Userlen MUST NOT be zero.
Username
Username in UTF-8 [RFC3629] format.
The content of Username SHOULD follow the guidelines set in
[RFC9427], Section 3.1.
Passlen
Length of Password field in octets.
The value of Passlen MUST NOT be zero.
Password
Password in UTF-8 [RFC3629] format.
Note that there is no requirement that passwords be humanly
readable. Octets in a passwords may have values less than 0x20,
including 0x00.
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 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.2.19. CSR-Attributes TLV
The CSR-Attributes TLV provides information from the server to the
peer on how certificate signing requests should be formed. The
purpose of CSR attributes is described in Section 4.5 of [RFC7030].
Servers MAY send the CSR-Attributes TLV directly after the TLS
session has been established. A server MAY also send in the same
message a Request-Action frame for a PKCS#10 TLV. This is an
indication to the peer that the server would like the peer to renew
its certificate using the parameters provided in this TLV. Servers
shall construct the contents of the CSR-Attributes TLV as specified
in [RFC7030], Section 4.5.2 with the exception that the DER encoding
MUST NOT be encoded in base64. The base64 encoding is used in
[RFC7030] because the transport protocol used there requires textual
encoding. In contrast, TEAP attributes can transport arbitrary
binary data.
Servers and peers MUST follow the guidance provided in [RFC9908] when
creating the CSR-Attributes TLV. Peers MAY ignore the contents of
the TLV if they are unable to do so, but then servers may not process
PKCS#10 certificate requests for this or any other reason.
The CSR-Attributes 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DER Encoded CSR Attributes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
M
0 - Optional TLV
R
Reserved, set to zero (0)
TLV Type
18 - CSR-Attributes
Length
>=2 octets
4.2.20. Identity-Hint TLV
The Identity-Hint TLV is an optional TLV that can be sent by the peer
to the server at the beginning of the Phase 2 TEAP conversation. The
purpose of the TLV is to provide a "hint" as to the identity or
identities that the peer will be using by subsequent Inner Methods.
The purpose of this TLV is to solve the "bootstrapping" problem for
the server. In order to perform authentication, the server must
choose an Inner Method. However, the server has no knowledge of what
methods are supported by the peer. Without an identity hint, the
server needs to propose a method and then have the peer return a
response indicating that the requested method is not available. This
negotiation increases the number of round trips required for TEAP to
conclude with no additional benefit.
When the Identity-Hint is used, the peer can signal which identities
it has available, which enables the server to choose an Inner Method
that is appropriate for that identity.
The peer SHOULD send an Identity-Hint TLV for each Identity-Type that
is available to it. For example, if the peer can do both machine and
user authentication, it can send two Identity-Hint TLVs with values
"host/name.example.com" (for a machine with hostname
"name.example.com") and "[email protected]" (for a person with
identity "[email protected]").
The contents of the Identity-Hint TLV SHOULD be in the format of an
NAI [RFC7542], but we note that as given in the example above,
Machine identities might not follow that format. As these identities
are never used for AAA routing as discussed in [RFC7542], Section 3,
the format and definition of these identities are entirely site
local. Robust implementations MUST support arbitrary data in the
content of this TLV, including binary octets.
As the Identity-Hint TLV is a "hint", server implementations are free
to ignore the hints given and do whatever is required by site-local
policies.
The Identity-Hint TLV is used only as a guide when selecting which
Inner Methods to use. This TLV has no other meaning, and it MUST NOT
be used for any other purpose. Specifically, server implementations
MUST NOT compare the identities given this TLV to later identities
given as part of the Inner Methods. There is no issue with the
hint(s) failing to match any subsequent identity that is used.
The Identity-Hint TLV MUST NOT be used for server unauthenticated
provisioning. This TLV is only used as a hint for normal
authentication.
The Identity-Hint 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 Hint |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
M
0 - Optional TLV
R
Reserved, set to zero (0)
TLV Type
19 - Identity-Hint
Length
>=2 octets
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 in which TLVs are encoded
in a TEAP packet does not matter. However, there is an order in
which TLVs in a packet must be processed:
1. Crypto-Binding TLV
2. Intermediate-Result TLV
3. Result TLV or Request-Action TLV
4. Identity-Type TLV
5. EAP-Payload TLV (Identity-Request) or Basic-Password-Auth-Req TLV
6. Other TLVs
That is, cryptographic binding is checked before any result is used
and identities are checked before proposing an Inner Method, as the
identity may influence the chosen Inner Method.
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, in 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 |
+---------+----------+---------+---------+-----------------+
Table 1
Outer TLVs MUST be marked as optional. Vendor TLVs inside of a
Vendor-Specific TLV MUST be marked as optional when included in Outer
TLVs. Outer TLVs MUST NOT be included in messages after the first
two 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-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 |
+-------+----------+---------+---------+--------------------------+
|0-1 | 0 | 0 | 0 | CSR-Attributes TLV |
+-------+----------+---------+---------+--------------------------+
|0 | 0+ | 0 | 0 | Identity-Hint TLV |
+-------+----------+---------+---------+--------------------------+
Table 2
NOTE: Vendor TLVs (included in Vendor-Specific TLVs) sent with a
Result TLV MUST be marked as optional. Also, the CSR-Attributes TLV
is never transmitted by the peer, and so is treated as a request in
this table.