| Re: Key derivation and the principle of equivalence | <– Date –> <– Thread –> |
From: Bernard Aboba (aboba internaut.com)
|
|
| Date: Sun, 15 May 2005 20:57:11 -0400 (EDT) | |
Here is some revised text which adds in support for Channel Bindings,
removes the dangling AAA references, and cleans up other miscellaneous
issues. Next, I'll work on cleaning up the text relating to the lower
layer.
EAP Method Operation
EAP, defined in [RFC3748] is a two-party protocol spoken between the
EAP peer and server. Within EAP, keying material is generated by EAP
methods. Part of this keying material may be used by EAP methods
themselves and part of this material may be exported. In addition
to export of keying material, EAP methods may also export associated
parameters, and may import and export Channel Bindings from the lower
layer.
As illustrated in Figure 1, the EAP method key derivation
has at the root the long term credential utilized by the
selected EAP method. If authentication is based on a
pre-shared key, the parties store the EAP method to be used
and the pre-shared key. The EAP server also
stores the peer's identity and/or other information necessary to
decide whether access to some service should be granted. The peer
stores information necessary to choose which secret to use for which
service.
If authentication is based on proof of possession of the private key
corresponding to the public key contained within a certificate, the
parties store the EAP method to be used and the trust anchors used to
validate the certificates. The EAP server also stores the peer's
identity and/or other information necessary to decide whether access
to some service should be granted. The peer stores information
necessary to choose which certificate to use for which service.
Based on the long term credential established between the peer and
the server, EAP derives two types of keys:
[1] Keys calculated locally by the EAP method but not exported
by the EAP method, such as the TEKs.
[2] Keying material exported by the EAP method: MSK, EMSK, IV.
As noted in [RFC3748] Section 7.10, EAP methods generating keys are
required to calculate and export the MSK and EMSK, which must be at
least 64 octets in length. EAP methods also may export the IV;
however, the use of the IV is deprecated.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+
| | ^
| EAP Method | |
| | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ | |
| | | | | | |
| | EAP Method Key |<->| Long-Term | | |
| | Derivation | | Credential | | |
| | | | | | |
| | | +-+-+-+-+-+-+-+ | Local to |
| | | | EAP |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Method |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+ | |
| | | TEK | |MSK, EMSK | |IV | | |
| | |Derivation | |Derivation | |Derivation | | |
| | +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+ | |
| | | | | |
| | ^ | | | V
+-+-|-+-+-+-+-+-+-+-+-|-+-+-+-+-+-|-+-+-+-+-+-+-+-+-|-+-+-+ ---+
| | | | ^
| Peer-ID, | | | Exported|
| Server-ID, | Channel | MSK (64+B) | IV (64B) by |
| Method-ID, | Bindings | EMSK (64+B) | EAP |
| Key-Lifetime | & Result | | Method |
V V V V V
Figure 1: EAP Parameter Import/Export
EAP methods also MAY export method-specific peer and server
identifiers (peer-ID and server-ID), a method-specific EAP
conversation identifier known as the Method-ID, and the lifetime of
the exported keys, known the Key-Lifetime. EAP methods
MAY also support the import and export of Channel Bindings.
New EAP method specifications MUST define the Peer-ID, Server-ID and
Method-ID. The combination of the Peer-ID and Server-ID uniquely
specifies the endpoints of the EAP method exchange.
Peer-ID
As described in [RFC3748] Section 7.3, the identity provided in
the EAP-Response/Identity, may be different from the peer identity
authenticated by the EAP method. Where the EAP method
authenticates the peer identity, that identity is exported by the
method as the Peer-ID. A suitable EAP peer name may not always be
available. Where an EAP method does not define a method-specific
peer identity, the Peer-ID is the null string. The Peer-ID for
existing EAP methods is defined in Appendix E.
Server-ID
Where the EAP method authenticates the server identity, that
identity is exported by the method as the Server-ID. A suitable
EAP server name may not always be available. Where an EAP method
does not define a method-specific peer identity, the Server-ID is
the null string. The Server-ID for existing EAP methods is
defined in Appendix E.
Method-ID
EAP method specifications deriving keys MUST specify a temporally
unique method identifier known as the Method-ID. The EAP Method-
ID uniquely identifies an EAP session of a given Type between an
EAP peer and server. The Method-ID is typically constructed from
nonces or counters used within the EAP method exchange. The
Method-ID for existing EAP methods is defined in Appendix E.
Session-ID
The Session-ID uniquely identifies an EAP session between an EAP
peer (as identified by the Peer-ID) and server (as identified by
the Server-ID). The EAP Session-ID consists of the concatenation
of the Expanded EAP Type Code (including the Type, Vendor-ID and
Vendor-Type fields defined in [RFC3748] Section 5.7) and the
Method-ID.
Key-Lifetime
While EAP itself does not support key lifetime negotiation, it is
possible to specify methods that do. However, systems that rely on
such negotiation for exported keys would only function with these
methods. As a result, it is NOT RECOMMENDED to use this approach as
the sole way to determine key lifetimes.
Channel Bindings
Channel Bindings include lower layer parameters that
are verified for consistency between the EAP peer and server.
In order to avoid introducing media dependencies, EAP
methods MUST treat Channel Bindings as opaque octets.
Typically the EAP method imports Channel Bindings from the
lower layer on the peer, and transmits them securely to the
EAP server, which exports them to the lower layer. However,
transport may occur from EAP server to peer, or may be
bi-directional. On the side of the exchange (peer or server)
where Channel Bindings are verified, the lower layer passes
the result of the verification (TRUE or FALSE) up to the
EAP method.
Layering
As illustrated in Figure 2, keying material and parameters exported
by EAP methods are passed down to the EAP peer or authenticator
layers, which passes them to the EAP layer. Keying material and
related parameters (including Channel Bindings) MUST NOT be cached
by the EAP peer or authenticator layers, or the EAP layer.
Based on the Method-ID exported by the EAP method, the EAP layer
forms the EAP Session-ID by concatenating the EAP Expanded Type with
the Method-ID. Together with the MSK, EMSK, IV, Peer-ID, Server-ID,
and Key-Lifetime, the EAP layer passes the Session-ID down to the
lower layer.
The Method-ID is exported by EAP methods rather than the Session-ID
so as to prevent EAP methods from writing into each other's Session-
ID space. Lower layers MAY cache keying material and related
parameters, including Channel Bindings. Lower Layer behavior is
discussed in more detail in Section TBD.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
| EAP method |
| |
| MSK, EMSK, IV, Channel |
| Peer-ID, Server-ID, Bindings |
| Method-ID, |
| Key-Lifetime |
| |
| V ^ ^ |
+-+-+-+-!-+-+-+-+-+-+-+-+-+-+-+-!-+-+-+-+-!-+-+
| ! ! ! |
| EAP ! Peer or Authenticator ! ! |
| ! layer ! ! |
| ! ! ! |
+-+-+-+-!-+-+-+-+-+-+-+-+-+-+-+-!-+-+-+-+-!-+-+
| ! ! ! |
| EAP ! layer ! ! |
| ! ! ! |
| ! Session-ID = ! ! |
| ! Expanded-Type || ! ! |
| ! Method-ID ! ! |
| ! ! ! |
+-+-+-+-!-+-+-+-+-+-+-+-+-+-+-+-!-+-+-+-+-!-+-+
| ! ! ! |
| Lower ! layer ! ! |
| ! ! ! |
| V V ^ |
| MSK, EMSK, IV, Channel Result |
| Peer-ID, Server-ID, Bindings |
| Session-ID, |
| Key-Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Flow of EAP parameters
Key Naming
The naming of keys within the EAP key hierarchy is based on the EAP
Session-ID.
MSK Name
This key is created between the EAP peer and EAP server, and can
be referred to using the string "MSK:", concatenated with the EAP
Session-ID.
EMSK Name
The EMSK can be referred to using the string "EMSK:", concatenated
with the EAP Session-ID.
IV Name
Use of the IV is deprecated. However, if necessary the IV can be
referred to using the string "IV:" concatenated with the EAP
Session-ID.
PMK Name
This document does not specify a naming scheme for the PMK. The
PMK is only identified by the key from which it is derived.
Note: IEEE 802.11i names the PMKID for the purposes of being able
to refer to it in the Secure Association protocol; this naming is
based on a hash of the PMK itself as well as some other parameters
(see Section 8.5.1.2 [IEEE-802.11i]).
TEKs
The TEKs may or may not be named. Their naming is specified in the
EAP method.
EAP Invariants
Certain basic characteristics, known as "EAP Invariants", hold
true for EAP implementations on all media:
Mode independence
Media independence
Method independence
Ciphersuite independence
Mode Independence
EAP as defined in [RFC3748] is a two party protocol spoken between
the EAP peer and server. A fundamental property of EAP is that at the
EAP method layer, the conversation between the EAP peer and server is
unaffected by whether the EAP authenticator is operating in
"pass-through" mode.
EAP methods operate identically in all aspects, including key
derivation and parameter import/export, regardless of whether
the authenticator is operating as a pass-through or not.
The successful completion of an EAP method that supports key
derivation results in the export of keying material on the
EAP peer and server. Even though the EAP peer or server may
import Channel-Bindings that may include the identity
of the EAP authenticator, this information is treated as opaque
octets. As a result, within EAP the only relevant identities
are the Peer-ID and Server-ID. Channel Bindings are only
interpreted by the lower layer.
Within EAP, the primary function of the AAA protocol is to maintain
the principle of Mode Independence, so that as far as the EAP peer is
concerned, its conversation with the EAP authenticator, and all
consequences of that conversation, are identical, regardless of the
authenticator mode of operation.
Media Independence
One of the goals of EAP is to allow EAP methods to function on any
lower layer meeting the criteria outlined in [RFC3748], Section 3.1.
For example, as described in [RFC3748], EAP authentication can be run
over PPP [RFC1661], IEEE 802 wired networks [IEEE-802.1X], and IEEE
802.11 wireless LANs [IEEE-802.11i].
In order to maintain media independence, it is necessary for EAP to
avoid consideration of media-specific elements. For example, EAP
methods cannot be assumed to have knowledge of the lower layer over
which they are transported, and cannot be restricted to identifiers
associated with a particular usage environment (e.g. MAC addresses).
Note that media independence may be retained within EAP methods that
support Channel-Bindings or method-specific identification. An EAP
method need not be aware of the content of an identifier in order to
use it. This enables an EAP method to use media-specific identifiers
such as MAC addresses without compromising media independence.
Channel-Bindings are treated as opaque octets by EAP methods, so
that handling them does not require media-specific knowledge.
Method Independence
By enabling pass-through, authenticators can support any method
implemented on the peer and server, not just locally implemented
methods. This allows the authenticator to avoid implementing code
for each EAP method required by peers. In fact, since a pass-through
authenticator is not required to implement any EAP methods at all, it
cannot be assumed to support any EAP method-specific code.
As a result, as noted in [RFC3748], authenticators must by default be
capable of supporting any EAP method. This is useful where there is
no single EAP method that is both mandatory-to-implement and offers
acceptable security for the media in use. For example, the
[RFC3748] mandatory-to-implement EAP method (MD5-Challenge) does not
provide dictionary attack resistance, mutual authentication or key
derivation, and as a result is not appropriate for use in wireless
LAN authentication [RFC4017]. However, despite this it is possible
for the peer and authenticator to interoperate as long as a suitable
EAP method is supported on the EAP server.
Ciphersuite Independence
Ciphersuite Independence is a consequence of the principles of Mode
Independence and Media Independence.
While EAP methods may negotiate the ciphersuite used in protection of
the EAP conversation, the ciphersuite used for the protection of the
data exchanged after EAP authentication has completed is negotiated
between the peer and authenticator within the lower layer, outside
of EAP. Since the ciphersuites used to protect data depend on the
lower layer, requiring EAP methods have knowledge of lower layer
ciphersuites would compromise the principle of Media Indepence.
Since ciphersuite negotiation occurs in the lower layer, there is no
need for ciphersuite negotiation within EAP, and EAP methods
generate keying material that is ciphersuite-independent.
For example, within PPP, the ciphersuite is negotiated within the
Encryption Control Protocol (ECP) defined in [RFC1968], after EAP
authentication is completed. Within [IEEE-802.11i], the AP
ciphersuites are advertised in the Beacon and Probe Responses prior
to EAP authentication, and are securely verified during a 4-way
handshake exchange.
Advantages of ciphersuite-independence include:
Reduced update requirements
If EAP methods were to specify how to derive transient session keys
for each ciphersuite, they would need to be updated each time a new
ciphersuite is developed. In addition, backend authentication
servers might not be usable with all EAP-capable authenticators,
since the backend authentication server would also need to be
updated each time support for a new ciphersuite is added to the
authenticator.
Reduced EAP method complexity
Requiring each EAP method to include ciphersuite-specific code for
transient session key derivation would increase method complexity
and result in duplicated effort.
Simplified configuration
The ciphersuite is negotiated between the peer and authenticator
outside of EAP. Where the authenticator operates in "pass-through"
mode, the EAP server is not a party to this negotiation, nor is
it involved in the data flow between the EAP peer and authenticator.
As a result, the EAP server may not have knowledge of the
ciphersuites and negotiation policies implemented by the peer and
authenticator, or be aware of the ciphersuite negotiated between
them. For example, since ECP negotiation occurs after authentication,
when run over PPP, the EAP peer and server may not anticipate
the negotiated ciphersuite and therefore this information cannot
be provided to the EAP method.
Appendix E - Exported Parameters in Existing Methods
This Appendix specifies Method-ID, Peer-ID, Server-ID and Key-
Lifetime for EAP methods that have been published prior to this
specification. Future EAP method specifications MUST include a
definition of the Method-ID, Peer-ID, and Server-ID (could be the
empty string) and MAY also define the Key-Lifetime (assumed to be
indeterminate if not described).
EAP-Identity
The EAP-Identity method does not derive keys, and therefore does not
define the Key-Lifetime or Method-ID. The Peer-ID exported by the
Identity method is determined by the octets included within the EAP-
Response/Identity. The Server-ID is the empty string (zero length).
EAP-Notification
The EAP-Notification method does not derive keys and therefore does
not define the Key-Lifetime and Method-ID. The Peer-ID and Server-ID
are the empty string (zero length).
EAP-GTC
The EAP-GTC method does not derive keys and therefore does not define
the Key-Lifetime and Method-ID. The Peer-ID and Server-ID are the
empty string.
EAP-OTP
The EAP-OTP method does not derive keys and therefore does not define
the Key-Lifetime and Method-ID. The Peer-ID and Server-ID are the
empty string.
EAP-TLS
The EAP-TLS Method-Id is the concatenation of the peer and server
nonces.
The Peer-ID and Server-ID are the contents of the altSubjectName in
the peer and server certificates.
EAP-TLS does not negotiate a Key-Lifetime.
EAP-AKA
The EAP-AKA Method-Id is the contents of the RAND field from the
AT_RAND attribute, followed by the contents of the AUTN field in the
AT_AUTN attribute.
The Peer-ID is the contents of the Identity field from the
AT_IDENTITY attribute, using only the Actual Identity Length octets
from the beginning, however. Note that the contents are used as they
are transmitted, regardless of whether the transmitted identity was a
permanent, pseudonym, or fast reauthentication identity. The Server-
ID is an empty string. EAP-AKA does not negotiate a key lifetime.
EAP-SIM
The Method-Id is the contents of the RAND field from the AT_RAND
attribute, followed by the contents of the NONCE_MT field in the
AT_NONCE_MT attribute.
The Peer-ID is the contents of the Identity field from the
AT_IDENTITY attribute, using only the Actual Identity Length octets
from the beginning, however. Note that the contents are used as they
are transmitted, regardless of whether the transmitted identity was a
permanent, pseudonym, or fast reauthentication identity. The Server-
ID is an empty string. EAP-SIM does not negotiate a key lifetime.
-
Key derivation and the principle of equivalence Bernard Aboba, May 11 2005
-
Re: Key derivation and the principle of equivalence Jari Arkko, May 12 2005
- Re: Key derivation and the principle of equivalence Bernard Aboba, May 12 2005
- Re: Key derivation and the principle of equivalence Bernard Aboba, May 15 2005
- Re: Key derivation and the principle of equivalence Yoshihiro Ohba, May 16 2005
- Re: Key derivation and the principle of equivalence Bernard Aboba, May 17 2005
- Re: Key derivation and the principle of equivalence Yoshihiro Ohba, May 17 2005
- Re: Key derivation and the principle of equivalence Bernard Aboba, May 17 2005
-
Re: Key derivation and the principle of equivalence Jari Arkko, May 12 2005
Results generated by Tiger Technologies using MHonArc.