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

[Nakhjiri Madjid-MNAKHJI1 (Madjid.Nakhjiri]

Same response as that to issue 323 on caching EAP generated keys. 

Either remove or mention explicitly which implementations (there are
counterexamples in the TSK text): 
"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."

Change MUST to SHOULD or MAY: 
"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."

Madjid


-----Original Message-----
From: Bernard Aboba [mailto:bernard_aboba [at] hotmail.com] 
Sent: Sunday, January 08, 2006 12:34 PM
To: eap [at] frascone.com
Subject: [eap] Proposed Resolution to issue 318: Transient Session Keys

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."


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

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