eap Mailing List: Proposed Resolution to issue 318: Transient Session Keys

[Bernard Aboba (bernard_aboba]

The text of Issue 318 is enclosed below.  The proposed resolution is to 
accept the proposed changes.

Issue 318: Transient Session Keys
Submitter name: Bernard Aboba
Submitter email address: aboba [at] internaut.com
Date Submitted: November 30, 2005
Reference:
Document: Keying-08
Comment type: T
Priority: S
Section: 2.3
Rationale/Explanation of issue:

There is no section of the document that talks directly about
generation of transient session keys. Here is a suggested
rewrite of Section 2.3:

2.3 Transient Session Keys

Existing EAP lower layers handle the caching of EAP keying
material and the generation of transient session keys in
different ways:

PPP PPP, defined in [RFC1661] does not support caching of EAP keying
material or parameters. PPP ciphersuites derive their TSKs
directly from the MSK, as described in [RFC2716]. This method
is NOT RECOMMENDED, since were PPP to support caching, this
could result in stale TSKs. As a result, once the PPP session
is terminated, EAP keying material and parameters MUST be discarded.
Since caching of EAP keying material is not permitted, within PPP
there is no way to handle TSK rekey without EAP re-authentication.
Perfect Forward Secrecy (PFS) is only possible within PPP if
the negotiated EAP method supports this.

IKEv2
IKEv2, defined in [IKEv2] only uses EAP keying material for
authentication purposes and not key derivation. As a
result, the keying material derived within IKEv2 is
independent of the EAP keying material and rekey of IPsec
SAs can be handled without requiring EAP re-authentiation.
Since generation of keying material is independent of EAP,
within IKEv2 it is possible to negotiate PFS, regardless of
the EAP method that is used. IKEv2 does not cache EAP keying
material or parameters, nor does it utilize the EAP Key-Lifetime
parameter to determine the lifetime of IPsec SAs. As result,
once IKEv2 authentication completes it is assumed that
EAP keying material and parameters are discarded.

IEEE 802.11i
IEEE 802.11i enables caching of the MSK, but not the EMSK, IV,
Peer-ID, Server-ID, or Session-ID. More details are
about the structure of the cache are available in [IEEE-802.11i].
In IEEE 802.11i, TSKs are derived from the MSK using the
4-way handshake, which includes a nonce exchange. This
guarantees TSK freshness even if the MSK is reused. The
4-way handshake also enables TSK rekey without EAP
re-authentication. PFS is only possible within IEEE 802.11i
if the negotiated EAP method supports this.

IEEE 802.1X-2004
IEEE 802.1X-2004, defined in [IEEE-802.1X-2004] does not support
caching of EAP keying material or parameters. Therefore once EAP
authentication completes, it is assumed that EAP keying material
and parameters are discarded.

IEEE 802.16e
IEEE 802.16e, defined in [IEEE-802.16e] supports caching of the
MSK, but not the EMSK, IV, Peer-ID, Server-ID or Session-ID.
In IEEE 802.16e, TSKs are generated by the authenticator without
any contribution by the peer. The TSKs are encrypted, authenticated
and integrity protected using the MSK. As a result, TSK rekey
is possible without EAP re-authentication. PFS is not possible
even if the negotiated EAP method supports it.

AAA  Existing AAA implementations supporting RADIUS/EAP [RFC3579] or 
Diameter
EAP [RFC4072] do not support caching of EAP keying material or
parameters.  In existing AAA client, proxy and server implementations, 
exported EAP
keying material (MSK, EMSK and IV) as well as parameters and
derived keys are not cached and MUST be presumed lost after the AAA
exchange completes.

In order to avoid key reuse, the AAA layer MUST delete transported
keys once they are sent.  The AAA layer MUST NOT retain keys that
it has previously sent.  For example, a AAA
layer that has transported the MSK MUST delete it, and keys MUST
NOT be derived from the MSK from that point forward."