eap Mailing List: Re: Issue: Transient Session Key Derivation

[Jari Arkko (jari.arkko]

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

Bernard Aboba wrote:

> Submitter name: Bernard Aboba
> Submitter email address: aboba [at] internaut.com
> 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