Subject: [eap] Issue: Transient Session Key Derivation

From: "Bernard Aboba" <[email-masked]>
Date: Wed, 30 Nov 2005 23:31:00 -0800

Submitter name: Bernard Aboba
Submitter email address: [email-masked]
Date Submitted: 11/30/05
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 servers supporting RADIUS/EAP [RFC3579] or Diameter
EAP [RFC4207] do not support caching of EAP keying material or
parameters. In existing AAA 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 to the authenticator. 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.

_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/eap

Arhives: http://lists.frascone.com/pipermail/eap

---

From: Jari Arkko <[email-masked]>
Date: Tue, 13 Dec 2005 16:14:47 +0200

Works for me.

Note that the fact that IKEv2 does not use EAP-provided
lifetimes may in fact be just a mistake resulting from the
lack of a VPN AAA spec. I'd rather not say here that the
lifetime should not be used. Say something softer, e.g,
implementations may not use the lifetime to limit the IPsec
SA lifetimes...

--Jari

---

From: "Bernard Aboba" <[email-masked]>
Date: Tue, 13 Dec 2005 23:02:39 -0800

I think this points out a potential issue with the Key_Lifetime parameter 
exported by the EAP method.  If this were to be encapsulated in the 
Session-Timeout attribute, then it would not be possible to separate AAA 
session times from EAP exported parameter lifetimes.

This is potentially problematic with IKEv2, since IKEv2 VPN might still want 
a Session-Timeout attribute to limit the VPN session time, but would not 
care about an EAP exported parameter lifetime since it doesn't cache 
exported EAP parameters or use them to derive IPsec SAs.

Maybe we should delete mention of the Key_Lifetime parameter entirely.

>From: Jari Arkko <[email-masked]>
>To: Bernard Aboba <[email-masked]>
>CC: [email-masked]
>Subject: Re: [eap] Issue: Transient Session Key Derivation
>Date: Tue, 13 Dec 2005 16:14:47 +0200
>
>Works for me.
>