Subject: [eap] issue: editorial (review of eap-keying-08 by mats naslund)

From: Jari Arkko <[email-masked]>
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: [email-masked]
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

---

From: "Bernard Aboba" <[email-masked]>
Date: Wed, 30 Nov 2005 22:42:49 -0800

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 <[email-masked]>
>To: [email-masked]
>CC: "Mats Näslund (KI/EAB)" <[email-masked]>
>Subject: [eap] issue: editorial (review of eap-keying-08 by mats naslund)
>Date: Thu, 01 Dec 2005 07:27:31 +0200
>