Subject: [eap] Proposed Resolution to issue 318: Transient Session Keys

From: "Bernard Aboba" <[email-masked]>
Date: Sun, 08 Jan 2006 10:34:23 -0800

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: [email-masked]
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."

_________________________________________________________________
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: Wed, 11 Jan 2006 12:53:06 +0200

> EAP keying material and parameters are discarded.

Hmm. This seems a bit problematic to me. In current AAA,
we do not have separate MSK and session lifetime attributes;
we just have one lifetime attribute. The description above
focuses only on the key lifetime aspects. But I would actually
like a security gateway to limit the lifetime of the SAs to
Session-Timeout in RADIUS, even if the lifetime can not be
communicated to the client.

> NOT be derived from the MSK from that point forward."

I believe we discussed this a bit in IETF-64 hokey bar bof.
The conclusion seemed to be that there are scenarios where
you need to deliver a symmetric key to two network elements
from AAA, and that we should support them. The requirement
in above text is more suited to cases where the EAP-derived
keys are used between the client and a single network
element.  So, should we say something that allows delivery
of a key to one or more parties, and only then deleting it?
OTOH, in the practical cases that I have seen for such symmetric
keys would have been better served by AAA-generated random
key than anything that has to do with EAP.

--Jari

---

From: "Bernard Aboba" <[email-masked]>
Date: Wed, 11 Jan 2006 09:26:32 -0800

>communicated to the client.

The above paragraph is referring only to the Key-Lifetime parameter exported 
by EAP methods, not to the Session-Timeout attribute.  With VPN, 
Session-Timeout is used to limit the VPN session time.   However, the point 
is that in this case Session-Timeout does not represent the MSK lifetime, 
which is zero (e.g. MSK is not cached).

Potential rewrite:

the EAP method that is used. IKEv2 does not cache EAP keying
material or parameters. As result,
once IKEv2 authentication completes it is assumed that
EAP keying material and parameters are discarded.
The Session-Timeout attribute is therefore interpretted as a
limit on the VPN session time, rather than an indication of the
MSK key lifetime.

---

From: Jari Arkko <[email-masked]>
Date: Wed, 11 Jan 2006 19:52:45 +0200

>
> The above paragraph is referring only to the Key-Lifetime parameter 
> exported by EAP methods, not to the Session-Timeout attribute.  With 
> VPN, Session-Timeout is used to limit the VPN session time.   However, 
> the point is that in this case Session-Timeout does not represent the 
> MSK lifetime, which is zero (e.g. MSK is not cached).

Yes. OK.

> limit on the VPN session time, rather than an indication of the

Works for me. s/etted/eted/, I think.

--Jari