Subject: [eap] Proposed Resolution of Issue 257: Accept

From: Bernard Aboba <[email-masked]>
Date: Tue, 19 Oct 2004 13:51:39 -0700 (PDT)

The text of Issue 257 is enclosed below.  The proposed resolution is to
accept the proposed changes.

------------------------------------------------------------------------
Issue 257: Editorial Comments on Keying Framework
Submitter name: Florent Bersani
Submitter email address: [email-masked]
Date first submitted: 7/30/2004
Reference:
http://mail.frascone.com/pipermail/eap/2004-July/002697.html
Document: Keying-03
Comment type: T
Priority: S
Section: Various
Rationale/Explanation of issue

Section 1

"Since in EAP keying material is generated by EAP methods, transported
by AAA protocols, transformed into session keys by Secure Association
Protocols and used by lower layer ciphersuites"

Stricto sensu, I think we should rather say:
"In EAP keying material is generated by EAP methods. Part of this keying
material may be used by EAP methods themselves and part of this material
may be exported. The exported keying material may be transported by AAA
protocols or transformed by Secure Association Protocols into session
keys which are used by lower layer ciphersuites."

Section 1.2

<>"security association
A set of policies and key(s) used to protect information. This
information in the security association is stored by each party of the
security association and must be consistent among the parties. Elements
of a security association include cryptographic keys, negotiated
ciphersuites and other parameters, counters, sequence spaces,
authorization attributes, etc."

Just for the record, in RFC 2401 we find: "A Security Association (SA)
is a simplex "connection" that affords security services to the traffic
carried by it."

<>Here my point is that "set of policies and key(s)" conflicts with
"Elements of a security association include cryptographic keys,
negotiated ciphersuites and other parameters, counters, sequence spaces,
authorization attributes, etc".
My suggestion:
"A set of policies and cryptographic state used to protect information
and Elements of a security association may include cryptographic keys,
negotiated ciphersuites and other parameters, counters, sequence spaces,
authorization attributes, etc"

Section 1.4.1

" Note that media independence may be retained within EAP methods that
support channel binding or method-specific identification. An EAP
method need not be aware of the content of an identifier in order to use
it. This enables an EAP method to use media-specific identifiers such
as MAC addresses without compromising media independence. To support
channel binding, an EAP method can pass binding parameters to the AAA
server in the form of an opaque blob, and receive confirmation of
whether the parameters match, without requiring media-specific knowledge."

This seems to be the proposed resolution of a point I raised in
http://mail.frascone.com/pipermail/eap/2004-April/002427.html... I like
it :-)!

Section 1.4.3

" While EAP methods may negotiate the ciphersuite used in protection of
the EAP conversation, the ciphersuite used for the protection of data is
negotiated within the Secure Association Protocol, out-of-band of EAP."

<>Perhaps clarify and say:
" While EAP methods may negotiate the ciphersuite used in protection of
the EAP conversation, the ciphersuite used for the protection of the
data exchanged after EAP authentication has completed is negotiated
within the Secure Association Protocol, out-of-band of EAP."

<>"For example, PPP ciphersuite negotiation occurs in the Encryption
Control Protocol (ECP) [RFC1968]. Since ECP negotiation occurs after
authentication, unless an EAP method is utilized that supports
ciphersuite negotiation, the peer, authenticator and backend
authentication server may not be able to anticipate the negotiated
ciphersuite and therefore this information cannot be provided to the EAP
method. Since ciphersuite negotiation is assumed to occur out-of-band,
there is no need for ciphersuite negotiation within EAP.
For example, a peer might be pre-configured with policy indicating the
ciphersuite to be used in communicating with a given authenticator.
Within PPP, the ciphersuite is negotiated within the Encryption Control
Protocol (ECP), after EAP authentication is completed. Within
[IEEE80211i], the AP ciphersuites are advertised in the Beacon and Probe
Responses, and are securely verified during a 4-way handshake exchange
after EAP authentication has completed."

I believe there is some redundancy here that makes things harder to
understand. Proposed resolution: delete the second paragraph.

Section 2.1

<>"Transient Session Keys (TSKs)
Session keys used to protect data which are appropriate for the
ciphersuite negotiated between the EAP peer and authenticator."

<>Clarify with
"Session keys used to protect data exchanged between the peer and the
authenticator after the EAP authentication has successfully completed.
TSKs are appropriate for the lower layer ciphersuite negotiated between
the EAP peer and authenticator."

Section 2.2

<>"Based on the long term credential established between the peer and
the server, EAP derives four types of keys:
[1] Keys calculated locally by the EAP method but not exported by the
EAP method, such as the TEKs.
[2] Keys exported by the EAP method: MSK, EMSK, IV
[3] Keys calculated from exported quantities: AAA-Key, AMSKs.
[4] Keys calculated by the Secure Association Protocol: TSKs."

<>I am sure that it is not EAP that derive the TSKs [4].
I am not sure that EAP is really responsible for AAA-Key and AMSK
derivation. Stricto sensu, TSKs are also derived from exported quantities.
Proposed rewording:
"Based on the long term credential established between the peer and the
server, EAP derives two types of keys:
[1] Keys calculated locally by the EAP method but not exported by the
EAP method, such as the TEKs.
[2] Keys exported by the EAP method: MSK, EMSK, IV
>From this keying material, two other types of keys may be derived:
[3] Keys calculated directly from exported quantities: AAA-Key, AMSKs.
[4] Keys calculated by the Secure Association Protocol from AAA-Key
(and/or AMSKs?): TSKs."

Section 2.3

<>I do not understand well the titles of [a] and [b]. Why not modify
them to:
[a] Secure key lifetime negotiation
[b] Key resynchronization

Section 2.3.2

"Attempting to manage the lifetime of the EAP-Key SA"

This is the first time that the term EAP-Key SA is introduced and it has
not been previously defined. Proposed resolution: insert a pointer to
section 3.2.

Section 2.3.3

"As a result, the lifetime of keys calculated from key material exported
by EAP methods can be no larger than the lifetime of the exported keying
material."

<>I'd say
""As a result, the lifetime of keys calculated from key material
exported by EAP methods cannot be larger than the lifetime of the
exported keying material."
but I am not a native English speaker...

In general, I find this paragraph and section confusing and difficult to
read. I'll work on refining why I get this feeling and I'll try to
propose some resolution. IINM, it boils down to: it is difficult to
negotiate key lifetimes and not much can be done, right?

This makes me think of IKEv2 that has simply dropped key lifetime
negotiation "A difference between IKEv1 and IKEv2 is that in IKEv1 SA
lifetimes were negotiated. In IKEv2, each end of the SA is responsible
for enforcing its own lifetime policy on the SA and rekeying the SA when
necessary."

Section 2.4

<>"AAA-Key Name
The AAA-Key is named by the concatenation of the string "AAA-Key", the
authenticator name (since the AAA-Key is bound to a particular
authenticator), and the name of the key from which the AAA-Key is
derived (MSK or AMSK Name)."

In appendix E, AAA-Key is shown to be derived either from MSK or EMSK
but not from AMSK... maybe we want to put more coherence here.

Section 3

"[1] EAP method SA. This SA is between the peer and EAP server. It
stores state that can be used for "fast resume" or other functionality
in some EAP methods."

RFC 3748 uses the term fast reconnect and not fast resume so my
suggestion is to replace resume by reconnect here and in other
occurrences of resume in the KMF document.

<>" Contents:
o Implicitly, the EAP method this SA refers to
o One or more internal (non-exported) keys
o EAP method SA name
o SA lifetime"

Proposed change: replace "o One or more internal (non-exported) keys"
by "internal (non-exported) cryptographic state"... since this SA may
store, for example, sequence counters and pseudonyms in addition to keys!

Section 3.2

IIRC this has already been said (see Issue 215
http://www.drizzle.com/~aboba/EAP/eapissues.html#Issue%20215) but I am
not sure that SA is an appropriate name for the EAP Key SA... but this
is not vital and I cannot think of better wording.

Section 3.3.1

"and to encrypt some attributes (such as the AAA-Key [RFC2548])"

I am not sure that referencing directly RFC 2548 (Microsoft
Vendor-specific RADIUS Attributes) is appropriate, perhaps RFC 3580
(which refers to RFC 2548 in its section 3.16) should also be mentioned
instead?

Section 3.4

" in IKE [RFC2409], the TSKs are bound to the IP addresses of the
endpoints and he negotiated SPI."

Since IKE is not a secure association protocol that (commonly) use EAP,
I suggest either deleting this sentence or referring to IKEv2.

Section 3.4.1

I suggest adding the obvious precision that:

<>"PMKSA is the Root service SA
PTKSA is a unicast service SA
GTKSA is a multicast service SA"

Section 4

" Within EAP"

I'd rather say "with EAP" since for instance the first mechanism
presented bypasses EAP ;-)

Although I very much like section 4 (which reminds me of
draft-aboba-802-context), I am not sure that it belongs to the key
management framework as such. I guess more work is needed here to
translate the clever but general considerations on handoff to precise
recommendations on the management of the keys. Proposed resolution: only
include in the KMF what is directly linked to key management
(generation, transport and usage), put the rest of (nice) considerations
on fast handoff in a separate document.

Section 5.1

There is a trade off between being self-contained and brief... my view
is that the definitions should not be restated but instead point to RFC
3748 (where they already appear IIRC) so something like "cryptographic
binding, cryptographic separation, key strength and mutual
authentication are defined in RFC 3748 and are used with the same
meaning here."

Section 5.7

Let's be incoherent with my previous remark on EAP-AKA and suggest here
to include a reference to draft-arkko-eap-service-identity-auth-00.txt.

Section 6

*"This section summarizes the security requirements that must be met by
EAP methods, AAA protocols, Secure Association Protocols and
Ciphersuites in order to address the security threats described in this
document. These requirements MUST be met by specifications requesting
publication as an RFC"*

<>This MUST does not sound like coming from an informational document,
does it?
Anyway, does the EAP WG have the power to impose those requirements on
(general) AAA protocols, SA protocols and cipher suites requesting
publication as an RFC? I don't think so... I guess we should wordsmith a
little bit here.

Section 6.1

"EAP methods export the MSK and EMSK and not Transient Session Keys"

EAP does not even derive TSKs so how could it export them?

"That is, knowledge of one substring MUST NOT help in recovering some
other substring without breaking some hard cryptographic assumption."

add non-overlapping after other and before substring ;-)

"The development and validation of key derivation algorithms is
difficult, and as a result EAP methods SHOULD reuse well established and
analyzed mechanisms for key derivation (such as those specified in IKE
[RFC2409] or TLS [RFC2246]), rather than inventing new ones. EAP methods
SHOULD also utilize well established and analyzed mechanisms for MSK and
EMSK derivation."

I find the last sentence redundant. Proposed resolution: delete it.

Section 6.1.1

"The EMSK MUST be unique for each session"

Do we have a definition of session? I guess it would be worth including
one. I'll try and post some proposition.

Appendix A

"TKIP, which requires a single 128-bit encryption key and a 128-bit
authentication key (used in both directions)"

<>I believe that the following text is more precise:
"TKIP, which requires a single 128-bit encryption key and a two 64-bit
authentication keys (one for each direction)"

" and WRAP, which requires a single 128-bit key (used in both directions)"

Remove this sentence: WRAP has disappeared long ago ;-)

Appendix B

" master_secret = TLS term for the MK"

MK is an old term that was in v2 of the KMF but has disappeared in this
v3 so to be consistent it should be removed here, so should be its
following occurrences. In appendix B, MK should simply be replaced by
master_secret.
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap