6. Cryptographic Calculations
Dieser Abschnitt bewahrt den RFC-Text fuer TEAPv1, einschliesslich TLS tunnel establishment, tunneled authentication, TLV formats, cryptographic calculations, IANA registries, security considerations und examples.
6. Cryptographic Calculations
The definitions given in this section are known to work with all
implementations but only for a few Inner Methods, as described above
in Section 5. In the interest of avoiding additional complexity in
an already complex process, those definitions are given as if they
work for all possible Inner Methods.
We note that some interoperable implementations have been written
based on these definitions, which support Inner Methods other than
EAP-MSCHAPv2 and EAP-TLS. It is therefore useful to document the
full operation of TEAPv1 despite the known issues. We only caution
implementors that Inner Methods that are not listed above in
Section 5 are likely to work with only a subset of existing TEAPv1
implementations.
For key derivation and crypto-binding, TEAP uses the Pseudorandom
Function (PRF) and MAC algorithms negotiated in the underlying TLS
session. Since these algorithms depend on the TLS version and cipher
suite, TEAP implementations need a mechanism to determine the version
and cipher suite in use for a particular session. The implementation
can then use this information to determine which PRF and MAC
algorithm to use.
6.1. TEAP Authentication Phase 1: Key Derivations
With TEAPv1, the TLS master secret is generated as specified in TLS.
If session resumption is used, then the master secret is obtained as
described in [RFC5077].
TEAPv1 makes use of the TLS Keying Material Exporters defined in
[RFC5705] to derive the session_key_seed as follows:
session_key_seed = TLS-Exporter(
"EXPORTER: teap session key seed",, 40)
No context data is used in the export process.
The session_key_seed is used by the TEAP authentication Phase 2
conversation to both cryptographically bind the Inner Method(s) to
the tunnel as well as generate the resulting TEAP session keys. The
other TLS keying materials are derived and used as defined in
[RFC8446].
6.2. Intermediate Compound Key Derivations
As TEAP can run multiple Inner Methods, there needs to be a way to
cryptographically bind each Inner Method to the TLS tunnel and to
cryptographically bind each method to the previous one. This binding
is done by deriving a number of intermediate keys and exchanging that
information in the Crypto-Binding TLV.
The key derivation is complicated by a number of factors. An inner
method can derive an MSK or (as with basic passwords) not derive an
MSK. An Inner Method can derive an EMSK or perhaps not derive an
EMSK, or some EAP types may derive different EMSKs for the peer and
the server. All of these cases must be accounted for and have
recommendations made for how peers and servers can interoperate.
There are a number of intermediate keys used to calculate the final
MSK and EMSK for TEAP. We give a brief overview here in order to
clarify the detailed definitions and derivations given below. As
each Inner Method can derive an MSK (or not) and an EMSK (or not),
there need to be separate intermediate key calculations for MSK and
for EMSK. For the purposes of this overview, we just describe the
derivations at a high level and state that the MSK/EMSK issue is
addressed in the more detailed text below.
For each Inner Method, we derive an IMSK. This key depends on the
inner key (MSK or EMSK). This IMSK is then tied to the TLS session
via the TLS-PRF to derive an Inner Method Compound Key (IMCK). The
IMCK is used to generate a Compound MAC key (CMK). The CMK is mixed
with various data from the TEAP negotiation to create Compound MAC
field of the Crypto-Binding attribute. This TLV cryptographically
binds the Inner Method to the protected tunnel and to the other
fields that have been negotiated. The cryptographic binding prevents
on-path attacks.
The IMCK for this Inner Method is then mixed with keys from previous
Inner Methods, beginning with the TEAP Phase 2 session_key_seed
derived above, to yield a Secure IMCK (S-IMCK) for this round. The
S-IMCK from the final is then used to derive the MSK and EMSK for
TEAP.
We differentiate keys for Inner Methods by counting Inner Methods
starting from 0 and use an index "j" to refer to an arbitrary inner
method. For example, IMCK[0] is the IMCK for the first, or "0" Inner
Method. While TEAPv1 is currently limited to one or two Inner
Methods (j=0 or j=0,1), further updates could allow for more Inner
Method exchanges.
6.2.1. Generating the Inner Method Session Key
Each Inner Method generates an IMSK that depends on the EMSK
(preferred) or the MSK if it exists, or else it is all zeros. We
refer to the IMSK for Inner Method "j" as IMSK[j].
If an Inner Method supports export of an EMSK, then the IMSK SHOULD
be derived from the EMSK, which is defined in [RFC5295]. The
optional data parameter is not used in the derivation.
The above derivation is not a requirement, as some peer
implementations of TEAP are also known to not derive IMSK from EMSK
and to only derive IMSK from MSK. In order to be compatible with
those implementations, the use of EMSK here is not made mandatory.
Some EAP methods may also have the peer and server derive different
EMSKs. Mandating an EMSK-based derivation there would prevent
interoperability, as the Crypto-Binding TLV contents that depend on
EMSK could not then be validated by either side. Those methods
SHOULD NOT derive IMSK from EMSK unless the method has a way to
negotiate how the EMSK is derived, along with a way to signal that
both the peer and server have derived the same EMSK.
It is RECOMMENDED that for those EAP methods, implementations take
the simpler approach of ignoring EMSK and always derive IMSK from
MSK. This approach is less secure, as IMSK no longer
cryptographically binds the Inner Method to the TLS tunnel. A better
solution is to suggest that deployments of TEAP SHOULD avoid such
methods.
The derivation of IMSK[j] from the j'th EMSK is given as follows:
IMSK[j] = First 32 octets of TLS-PRF(
EMSK[j],
"[email protected]",
0x00 | 0x00 | 0x40)
Where:
* "|" denotes concatenation
* The TLS-PRF is defined in [RFC5246] as:
PRF(secret, label, seed) = P_<hash>(secret, label | seed)
* The secret is the EMSK from the j'th Inner Method, the usage label
used is "[email protected]" consisting of the ASCII value for
the label "[email protected]" (without quotes), and the seed
consists of the "\0" null delimiter (0x00) and 2-octet unsigned
integer length of 64 octets in network byte order (0x00 | 0x40)
specified in [RFC5295].
If an Inner Method does not support the export of EMSK but does
export MSK, then the IMSK is copied from the MSK of the Inner Method.
If the MSK is longer than 32 octets, the IMSK is copied from the
first 32 octets and the rest of MSK is ignored. If the MSK is
shorter than 32 octets, then the ISMK is copied from MSK and the
remaining data in IMSK is padded with zeros to a length of 32 octets.
IMSK[j] is then this derived value.
If the Inner Method does not provide either MSK or EMSK, such as when
basic password authentication is used or when no Inner Method has
been run, then both MSK and IMSK[j] are set to all zeroes (i.e.,
IMSK[j] = MSK = 32 octets of 0x00s).
Note that using an MSK of all zeroes opens up TEAP to on-path attacks
as discussed in Section 8.3. It is therefore NOT RECOMMENDED to use
Inner Methods that fail to generate an MSK or EMSK. These methods
should only be used in conjunction with another Inner Method that
does provide for MSK or EMSK generation.
It is also RECOMMENDED that TEAP peers order Inner Methods such that
methods that generate EMSKs are performed before methods that do not
generate EMSKs. Ordering Inner Methods in this manner ensures that
the first Inner Method detects any on-path attackers, and any
subsequent Inner Method used is therefore secure.
For example, Phase 2 could perform both machine authentication using
EAP-TLS, followed by user authentication via the Basic Password
Authentication TLVs. In that case, the use of EAP-TLS would allow an
attacker to be detected before the users' password was sent.
However, it is possible that the peer and server sides might not have
the same capability to export EMSK. In order to maintain maximum
flexibility while prevent downgrading attack, the following mechanism
is in place.
6.2.2. Generating S-IMCK
Once IMSK[j] has been determined, it is mixed via the TLS-PRF with
the key S-IMCK[j-1] from a previous round. That mixing derives a new
key IMCK[j]. This key is then used to derive both S-IMCK[j] for this
round and CMK[j] for this round.
The derivation of S-IMCK is as follows:
S-IMCK[0] = session_key_seed
For j = 1 to n-1 do
IMCK[j] = the first 60 octets of TLS-PRF(S-IMCK[j-1],
"Inner Methods Compound Keys",
IMSK[j])
S-IMCK[j] = first 40 octets of IMCK[j]
CMK[j] = last 20 octets of IMCK[j]
where TLS-PRF is the PRF (described above) negotiated as part of TLS
handshake [RFC5246]. The value j refers to a corresponding Inner
Method 1 through n. The special value of S-IMCK[0] is used to
bootstrap the calculations and can be done as soon as the TLS
connection is established and before any inner methods are run.
In practice, the requirement to use either MSK or EMSK means that an
implementation MUST track two independent derivations of IMCK[j], one
that depends on the MSK and another that depends on EMSK. That is,
we have both values derived from MSK:
* IMSK_MSK[j]
* S-IMCK_MSK[j]
* CMK_MSK[j]
and then also values derived from EMSK:
* IMSK_EMSK[j]
* S-IMCK_EMSK[j]
* CMK_EMSK[j]
At the conclusion of a successful exchange of Crypto-Binding TLVs, a
single S-IMCK[j] is selected based on which Compound MAC value was
included in the Crypto-Binding TLV from the client. If EMSK Compound
MAC was included, S-IMCK[j] is taken from S-IMCK_EMSK[j]. Otherwise,
S-IMCK[j] is taken from S-IMCK_MSK[j].
6.2.3. Choosing Inner Methods Securely
In order to further secure TEAP, implementations can take steps to
increase their security by carefully ordering Inner Methods. Where
multiple Inner Methods are used, implementations SHOULD choose an
ordering so that the first Inner Method used is one that derives
EMSK.
For an EAP server, it can select the first Inner Method to be one
that derives EMSK. Since ordering of Inner Methods is not otherwise
important in EAP, any chosen order is supported by the peer that
receives this request.
For an EAP peer, it can choose its response to a server's request for
a particular type of authentication. The peer can ignore that
request and return an Inner Method that derives EMSK. Again, since
the ordering of Inner Methods is not otherwise important in EAP, any
chosen order is supported by the server that receives this response.
Once the more secure authentication has succeed, the server then
requests the other type of authentication and the peer can respond
with the chosen type of authentication.
Implementations can also provide configuration flags, policies, or
documented recommendations that control the type of Inner Methods
used or verify their order. These configurations allow
implementations and administrators to control their security exposure
to on-path attackers.
Implementations can permit administrators to configure TEAP so that
the following security checks are enforced:
* Verifying that the first Inner Method used is one that derives
EMSK. If this is not done, a fatal error can be returned.
* Verifying that if any Inner Method derives EMSK, the received
Crypto-Binding TLV for that method contains an EMSK Compound MAC.
If an EMSK has been derived and no EMSK Compound MAC is seen, a
fatal error can be returned.
The goal of these suggestions is to enforce the use of the EMSK
Compound MAC to protect the TEAP session from on-path attackers. If
these suggestions are not enforced, then the TEAP session is
vulnerable.
Most of these suggestions are not normative, as some existing
implementations are known to not follow them. Instead, these
suggestions are here to inform new implementors, along with
administrators, of the issues surrounding this subject.
6.2.4. Managing and Computing Crypto-Binding
After an Inner Method has been completed successfully and the inner
keys have been derived, the server sends a Crypto-Binding TLV to the
peer. If the Inner Method has failed, the server does not send a
Crypto-Binding TLV.
The peer verifies the Crypto-Binding TLV by applying the rules
defined in Section 4.2.13. If verification passes, the peer responds
with its own Crypto-Binding TLV, which the server in turn verifies.
If at any point verification fails, the party that makes this
determination terminates the session.
The Crypto-Binding TLV is normally sent in conjunction with other
TLVs that indicate intermediate or final results or that begin
negotiation of a new Inner Method. This negotiation does not
otherwise affect the Crypto-Binding TLV.
While Section 4.2.13 defines that the Compound MAC fields exist in
the Crypto-Binding TLV, it does not describe the derivation and
management of those fields. This derivation is complex and is
therefore located here along with the other key derivations.
The following text defines how the server and peer compute, send, and
then verify the Compound MAC fields Crypto-Binding TLV. Depending on
the Inner Method and site policy, the Crypto-Binding TLV can contain
only an MSK Compound MAC (Flags=2), only the EMSK Compound MAC
(Flags=2), or both Compound MACs (Flags=3). Each party to the TEAP
session follows its own set of procedures to compute and verify the
Compound MAC fields.
The determination of the contents of the Crypto-Binding TLV is done
separately for each Inner Method. If at any point the verification
of a Compound MAC fails, the determining party returns a fatal error
as described in Section 3.9.3.
We presume that each peer and server have site policies that may or
may not require the use of the MSK Compound MAC and/or the EMSK
Compound MAC. These policies can be enforced globally for all Inner
Methods, or they can be enforced separately on each Inner Method.
These policies could be enabled automatically when the EAP method is
known to always generate an EMSK and could otherwise be configurable.
The server initiates crypto-binding by determining which Compound
MAC(s) to use, computing their value(s), placing the resulting
Compound MAC(s) into the Crypto-Binding TLV, and then sending it to
the peer.
Then, the steps taken by the server are as follows:
* If the Inner Method is known to generate only MSK, or if the
server's policy is to not use EMSK Compound MACs:
- The server computes the MSK Compound MAC using the MSK of the
Inner Method. The server does not use the EMSK Compound MAC
field (Flags=2).
Otherwise, the EMSK is available.
* If the server's policy permits the use of the MSK Compound MAC:
- The sender computes the MSK Compound MAC along with the EMSK
Compound MAC (Flags=3).
Otherwise, the server's policy does not allow the use of the MSK
Compound MAC:
- The server computes only the EMSK Compound MAC (Flags=1).
The peer verifies the Crypto-Binding TLV it receives from the server.
It then replies with its own crypto-binding response by determining
which Compound MAC(s) to use, computing their value(s), placing the
resulting Compound MAC(s) into the Crypto-Binding TLV, and then
sending it to the server. The result of this process is either a
fatal error or one or more Compound MACs that are placed in the
Crypto-Binding TLV and sent to the server.
Then, the steps taken by the peer are as follows:
* If the peer site policy requires the use of the EMSK Compound MAC:
- The peer checks if the Flags field indicates the presence of
the EMSK Compound MAC (Flags=1 or 3). If the Flags field has
any other value, the peer returns a fatal error.
- The peer checks if the Inner Method has derived an EMSK. If
not, the peer returns a fatal error.
Otherwise, the peer site policy does not require the use of the
EMSK Compound MAC and the EMSK may or may not exist.
* If the Inner Method is known to generate only MSK and not EMSK:
- The peer checks if the Flags field indicates that only the MSK
Compound MAC exists (Flags=2). If the Flags field has any
other value, the peer returns a fatal error.
Otherwise, the MSK exists, the EMSK may or may not exist, and the
peer allows the use of the EMSK Compound MAC. The peer may have
received one or two Compound MACs (Flags=1,2,3). Any Compound MAC
that is present is verified. No further action is taken by the
peer if a particular Compound MAC is not present. No further
action is taken by the peer if an unexpected Compound MAC is
present.
Note that due to earlier validation of the Flags field
(Section 4.2.13), at least one Compound MAC must now exist
(Flags=1,2,3).
* If the peer has received an MSK Compound MAC, it verifies it and
returns a fatal error if verification fails.
* If EMSK is available and the peer has received an EMSK Compound
MAC, it verifies it and returns a fatal error if verification
fails.
The peer creates a crypto-binding response by determining which
Compound MAC(s) to use, computing their value(s), placing the
resulting Compound MAC(s) into the Crypto-Binding TLV, and then
sending it to the server.
The steps taken by the peer are then as follows.
* If the peer received an MSK Compound MAC from the server:
- Since the MSK always exists, this step is always possible. The
peer computes the MSK Compound MAC for the response (Flags=2).
* If the peer site policy requires the use of the EMSK Compound MAC:
- The preceding steps taken by the peer ensures that the EMSK
exists and the server had sent an EMSK Compound MAC. The peer
computes the EMSK Compound MAC for the response. The Flags
field is updated (Flags=1,3).
Otherwise, if the EMSK exists:
- The peer computes the EMSK Compound MAC for the response. The
Flags field is updated (Flags=1,3).
The server processes the response from the peer via the following
steps:
* If the server site policy requires the use of the EMSK Compound
MAC:
- The server checks if the Flags field indicates the presence of
the EMSK Compound MAC (Flags=1 or 3). If the Flags field has
any other value, the server returns a fatal error.
- The server checks if the Inner Method has derived an EMSK. If
not, the server returns a fatal error.
* If the Inner Method is known to generate only MSK and not EMSK:
- The server checks if the Flags field indicates that only the
MSK Compound MAC exists (Flags=2). If the Flags field has any
other value, the server returns a fatal error.
Otherwise, the MSK exists and the EMSK may or may not exist. The
server may have received one or two Compound MACs (Flags=1,2,3).
Any Compound MAC that is present is verified. No further action
is taken by the server if a particular Compound MAC is not
present. No further action is taken by the server if an
unexpected Compound MAC is present.
* If the server has received an MSK Compound MAC, it verifies it and
returns a fatal error if verification fails.
* If EMSK is available and the server has received an EMSK Compound
MAC, it verifies it and returns a fatal error if verification
fails.
Once the above steps have concluded, the server either continues
authentication with another Inner Method or it returns a Result TLV.
6.2.5. Unintended Side Effects
In earlier drafts of this document, the descriptions of the key
derivations had issues that were only discovered after TEAP had been
widely implemented. These issues need to be documented in order to
enable interoperable implementations.
As noted above, some inner EAP methods derive MSK but do not derive
EMSK. When there is no EMSK, it is therefore not possible to derive
IMCK_EMSK[j] from it. The choice of multiple implementations was
then to simply define:
IMCK_EMSK[j] = IMCK_EMSK[j - 1]
This definition can be trivially implemented by simply keeping a
cached copy of IMCK_EMSK in a data structure. If EMSK is available,
IMCK_EMCK is updated from it via the TLS-PRF function as defined
above. If EMSK is not available, then the IMCK_EMSK value is
unmodified.
This behavior was not explicitly anticipated by earlier drafts of
this document. It instead appears to be an accidental outcome of
implementing the derivations above with the limitation of a missing
EMSK. This behavior is explicitly called out here in the interest of
fully documenting TEAP.
Another unintended consequence is in the calculation of the Crypto-
Binding TLV. That TLV includes compound MACs that depend on the MSK
and EMSK of the current authentication method. Where the current
method does not provide an EMSK, the Crypto-Binding TLV does not
include a compound MAC that depends on the EMSK. Where the current
method does not provide an MSK, the Crypto-Binding TLV includes a
compound MAC that depends on a special "all zero" IMSK as discussed
earlier.
The result of this definition is that the final Crypto-Binding TLV in
an inner TEAP exchange may not include a compound MAC that depends on
EMSK, even if earlier EAP methods in the Phase 2 exchange provided an
EMSK. This result likely has negative effects on security, though
the full impact is unknown at the time of writing this document.
These design flaws have nonetheless resulted in multiple
interoperable implementations. We note that these implementations
seem to support only EAP-TLS and the EAP-FAST-MSCHAPv2 variant of
EAP-MSCHAPv2. Other inner EAP methods may work by accident but are
not likely to work by design. For this document, we can only ensure
that the behavior of TEAPv1 is fully documented, even if that
behavior was an unintended consequence of unclear text in earlier
versions of this specification.
We expect that these issues will be addressed in a future revision of
TEAP.
6.3. Computing the Compound MAC
For Inner Methods that generate keying material, further protection
against on-path attacks is provided through cryptographically binding
keying material established by both TEAP Phase 1 and TEAP Phase 2
conversations. After each successful inner EAP authentication, EAP
EMSK and/or MSKs are cryptographically combined with key material
from TEAP Phase 1 to generate a CMK. The CMK is used to calculate
the Compound MAC as part of the Crypto-Binding TLV described in
Section 4.2.13, which helps provide assurance that the same entities
are involved in all communications in TEAP. During the calculation
of the Compound MAC, the MAC field is filled with zeros.
The Compound MAC computation is as follows:
Compound MAC = the first 20 octets of MAC( CMK[n], BUFFER )
where n is the number of the last successfully executed inner method,
MAC is the MAC function negotiated in TLS (e.g., TLS 1.2 in
[RFC5246]), and BUFFER is created after concatenating these fields in
the following order:
1. The entire Crypto-Binding TLV attribute with both the EMSK and
MSK Compound MAC fields zeroed out.
2. The EAP Type sent by the other party in the first TEAP message,
which MUST be TEAP, encoded as one octet of 0x37.
3. All the Outer TLVs from the first TEAP message sent by the EAP
server to the peer. If a single TEAP message is fragmented into
multiple TEAP packets, then the Outer TLVs in all the fragments
of that message MUST be included.
4. All the Outer TLVs from the first TEAP message sent by the peer
to the EAP server. If a single TEAP message is fragmented into
multiple TEAP packets, then the Outer TLVs in all the fragments
of that message MUST be included.
If no Inner Method is run, then no MSK or EMSK will be generated. If
an IMSK needs to be generated, then the MSK and therefore the IMSK is
set to all zeroes (i.e., IMSK = MSK = 32 octets of 0x00s).
Note that there is no boundary marker between the fields in steps (3)
and (4). However, the server calculates the compound MAC using the
Outer TLVs it sent and the Outer TLVs it received from the peer. On
the other side, the peer calculates the compound MAC using the outer
TLVs it sent and the Outer TLVs it received from the server. As a
result, any modification in transit of the Outer TLVs will be
detected because the two sides will calculate different values for
the compound MAC.
If no key-generating Inner Method is run, then no MSK or EMSK will be
generated. If an IMSK needs to be generated, then the MSK and
therefore the IMSK is set to all zeroes (i.e., IMSK = MSK = 32 octets
of 0x00s)
6.4. EAP Master Session Key Generation
TEAP authentication assures the MSK and EMSK output from running TEAP
are the combined result of all Inner Methods by generating an IMCK.
The IMCK is mutually derived by the peer and the server as described
in Section 6.2 by combining the MSKs from Inner Methods with key
material from TEAP Phase 1. The resulting MSK and EMSK are generated
from the final ("n"th) Inner Method, as part of the IMCK[n] key
hierarchy via the following derivation:
MSK = the first 64 octets of TLS-PRF(S-IMCK[n],
"Session Key Generating Function")
EMSK = the first 64 octets of TLS-PRF(S-IMCK[n],
"Extended Session Key Generating Function")
The secret is S-IMCK[n], where n is the number of the last generated
S-IMCK[j] from Section 6.2. The label is the ASCII value for the
string without quotes. The seed is empty (0 length) and is omitted
from the derivation.
The EMSK is typically only known to the TEAP peer and server and is
not provided to a third party. The derivation of additional keys and
transportation of these keys to a third party are outside the scope
of this document.
If no Inner Method has created an MSK or EMSK, the MSK and EMSK will
be generated directly from the session_key_seed meaning S-IMCK[0] =
session_key_seed.
As we noted above, not all Inner Methods generate both MSK and EMSK,
so we have to maintain two independent derivations of S-IMCK[j], one
for each of MSK[j] and EMSK[j]. The final derivation using S-IMCK[n]
must choose only one of these keys.
If the Crypto-Binding TLV contains an EMSK compound MAC, then the
derivation is taken from the S-IMCK_EMSK[n]. Otherwise, it is taken
from the S-IMCK_MSK[n].