eap Mailing List: RE: issue: editorial (review of eap-keying-08 by mats naslund)

[Bernard Aboba (bernard_aboba]

The document doesn't really provide a framework for the generation of
EAP keying material (MSK/EMSK). At best it describes some requirements and
provides some examples.

The TSK generation examples are no longer in Appendix B; this is now
discussed in Section 2.3 (not sure this is the best place for that though).
The discussion might be expanded to talk a bit more about the security
properties of various schemes:

PPP: TSKs generated directly from MSK. Caching not supported,
since this could lead to TSK reuse. PFS only possible with
methods that support it.
IEEE 802.11i: TSKs generated from MSK via 4-way handshake. Caching
allowed since freshness is guaranteed. PFS not possible
where cached PMKs are used.
IKEv2: TSKs generated from IKEv2 exchange, EAP keying material
only used for authentication. No caching. PFS can be
negotiated.
IEEE 802.16e: TSKs generated by the authenticator. EAP keying material
used to encrypt, and integrity protect the transported
TSK. PFS not possible.

Figure 1 currently includes the TEKs, MSK, EMSK. In -07, Figure 5
included the AAA-Key and TSKs, though not the PMK. The problem
with that figure is that it was potentially misleading, since it
implied that the TSKs are always derived from the MSK. As noted
above, this is not necessarily the case.

Perhaps we can include MSK = AAA-Key in figure 1 and maybe add
a few words about the PMK, just to say that it represents a
portion of the MSK (the portion varies between different lower
layers).


> From: Jari Arkko <jari.arkko [at] piuha.net>
> To: eap [at] frascone.com
> CC: "Mats Näslund (KI/EAB)" <mats.naslund [at] ericsson.com>
> Subject: [eap] issue: editorial (review of eap-keying-08 by mats naslund)
> Date: Thu, 01 Dec 2005 07:27:31 +0200
>
> There are multiple issues, each in separate e-mail
>
> Submitter name: Mats Naslund
> Submitter email address: Mats.Naslund [at] ericsson.com
> Reference: (this email)
> Document: Keying Framework
> Comment type: E
> Priority: 1
> Section: multiple
> Rationale/Explanation of issue:
>
>   The Extensible Authentication Protocol (EAP), defined in [RFC3748],
>   enables extensible network access authentication.  This document
>   provides a framework for the generation, transport and usage of
>
> MN: In what sense is _generation_ of key material really covered?
> It explains how some methods have done, but does it really specify
> a framework for key generation?
>
> Transient Session Keys (TSKs)
>     Session keys used to protect data exchanged in a session between
>     the peer and authenticator after the EAP authentication has
>     successfully completed.  TSKs are appropriate for the lower layer
>     ciphersuite negotiated between the ports of the EAP peer and
>     authenticator.  Examples of TSK derivation are provided in Appendix
>     B.
>
> MN: sorry, didn't find a single such example.
>
> AAA-Key
>     A key derived by the peer and EAP server, used by the peer and
>     authenticator in the derivation of Transient Session Keys (TSKs).
>     Where a backend authentication server is present, the AAA-Key is
>     transported from the backend authentication server to the
>     authenticator.  In existing usage, the AAA-Key is always derived
>     from the MSK and so can be referred to using the MSK name.  AAA-Key
>     = MSK(0,63).
>
> MN: Why not show a figure of the hierachy? In fact, what does it look like?
>
>        ---> TEK
>       /
>   .../ ---> MSK = AAAk  ----> TSK
>      \         \
>       \         \---> PMK --> TSK
>        \
>         \---> EMSK
>
> _________________________________________________________________
> To unsubscribe or modify your subscription options, please visit:
> http://lists.frascone.com/mailman/listinfo/eap
>
> Arhives: http://lists.frascone.com/pipermail/eap