Subject: [eap] Comments and questions on draft-ietf-eap-keying-03.txt

From: Florent Bersani <[email-masked]>
Date: Fri, 30 Jul 2004 14:20:51 +0200

Hi all,

Please find below my comments and questions on Extensible Authentication 
Protocol (EAP) Key Management Framework (draft-ietf-eap-keying-03.txt) 
which I refer to as KMF.

They come in chronological order while reading the document and I have 
tried to priorize them (I put in *bold* the one I think are important).

Hope this helps,

Florent, at least you know the reactions of naive reader while reading 
the KMF ;-)

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

"Since discovery is handled outside of EAP, there is no need to provide 
this functionality within EAP."

This might create confusion with EAP network discovery.
Proposed resolution:
"Since authenticator discovery is handled outside of EAP, there is no 
need to provide this functionality within EAP."

Section 1.3.2

"For example, a peer completing mutual authentication with an EAP server 
will not send data traffic over the link until the EAP server has 
authenticated successfully to the peer, and a Secure Association has 
been negotiated."

Just to make sure that we allow and are aware that security associations 
may use null transforms, e.g., when the peer authenticates over 802.3, 
typically after authentication, its traffic is sent in clear without any 
protection! I believe this is also frequent with PPP (although it is 
perfectly possible to protect the PPP traffic with ECP). So to me, it 
seems that the Unicast Secure Association (Phase 2a) is a way optional, 
isn't it? I don't like this phase being optional but it seems to reflect 
what may happen in the real world, doesn't it?

Section 1.3.3

" The Secure Association phase (phase 2) always occurs after the 
completion of EAP authentication (phase 1a) and key transport (phase 1b)"

If it occurs... see above.

I recommend putting [3] "Generation of fresh transient session keys 
(TSKs)" before [1]  Entity Naming.since [1] refers to TSKs which have 
not yet been defined in the document.

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

*"Extended Master Session Key (EMSK)*

Additional keying material derived between the peer and server that  is 
exported by the EAP method.  The EMSK is at least 64 octets in length, 
and is never shared with a third party."

<>I would like to better understand two things here:
1) "at least 64 octets": why not exactly 64 octets. 64 octets is already 
a lot of keying material and allowing multiple lengths for the EMSK 
leaves IMHO the door open for interoperability issues - A similar remark 
applies to the MSK. I guess we cannot do much as this has been included 
in RFC 3748 :-(, can we?
2) "and is never shared with a third party" I understand that this 
requirement comes from sound cryptographic practice that recommends that 
keys generally do not be shared among many parties but I am wondering 
here if by placing  such a limitation on the EMSK we preclude efficient 
yet possibly secure schemes. I'll elaborate on this point in a separate 
post but I just wanted here to express my interrogation on this 
requirement.

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

*"They remain valid only for the duration of the EAP conversation, and 
are lost once the EAP conversation completes."*

<>I find the requirement to delete the TEK hypocrite since if it is 
allowed to cache the TLS Master secret then IINM it is perfectly 
possible to rederive the TEK used by EAP-TLS for a particular 
conversation. So caching the TLS master secret is in a way more 
dangerous than caching the TEKs!
Though this requirement again comes from sound cryptographic practice, I 
find it here to be too stringent: it can preclude fast reconnect schemes 
within EAP methods. I would sth like: "TEKs caching is allowed although 
doing so raises security concerns:
[a] Insecure reuse of the TEK. The EAP method is responsible for 
ensuring that reusing the cached TEKs is done in a way that does not 
compromise security
[b] Compromise of the TEKs. In case, the peer or the server are 
compromised. The TEKs they have cached may also be compromised. Keying 
material is sensitive and caching some require special security care."

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

*"This key is created between the EAP peer and EAP server, and is 
uniquely named by the concatenation of the string "MSK", EAP Method 
Type, EAP peer name, EAP server name, EAP peer nonce, and the EAP server 
nonce."*

<>This imposes that all EAP methods exchange two nonces (one from the 
peer and one from the server) and identify uniquely the parties (i.e., 
no "group key" for an EAP method). While this seems pretty natural, I do 
not remember any text in RFC 3748 placing such requirements on EAP 
methods. It is only recommended, e.g. in RFC 3748 section 7.10: "A 
RECOMMENDED method is for each party to provide a nonce of at least 128 
bits, used in the derivation of the MSK and EMSK.". Seems like we are 
drifting from RECOMMENDED to MUST, aren't we? So as for the EAP state 
machine, if the KMF is informative (which I believe because I read 
"Category: informational" on the cover page of the KMF), we should make 
sure that we don't (normatively) exclude EAP methods (e.g. those that 
cannot name the MSK in the specified way). I bet this is worth more 
discussion.

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

Although I very much like EAP-AKA, I am not sure that we want to create 
a dependency between a WG document and an individual Internet-Draft 
(however since the reference to EAP-AKA is informative, this perhaps no 
big deal). Furthermore, this quotation could be interpreted as an 
approval by the EAP WG of EAP-AKA.

Proposed resolution: either remove this paragraph or have some discussion.

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 sth 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.2

*"Domino effect"*
 I guess I'd like more discussion on this one, since it seems to 
preclude IMHO inter-authenticator protocols for fast handoff without 
communication with a AAA. Are we sure that we want this?

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 EMSK MUST remain on the EAP peer and EAP server where it is 
derived; it MUST NOT be transported to, or shared with, additional 
parties, or used to derive any other keys."*

First I am not sure of this requirement and second, I guess we should 
have a clear definition of what another party is (e.g., we can have 
clusters of AAA for safe failover or we can have a wireless switch 
acting as a standalone authenticator that has multiple wireless 
termination points...)

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

"The EAP mechanism SHOULD provide a way of naming the EMSK"

What about the naming of the MSK?

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.

Appendix E and F

I think here there is some incoherence between these two appendixes: the 
EMSK is used for two different purposes:

<>1) derivation of AAA-Keys "AAA-Key-B = PRF(EMSK(0,63),"EAP AAA-Key 
derivation for multiple attachments", AAA-Key-A,B-Called-Station-Id, 
Calling-Station-Id,length)" in appendix E
2) derivation of AMSKs "AMSK = KDF(EMSK, key label, optional application 
data, length)" in appendix F

This needs to be fixed: more work is required. A possible fix would be 
to view AAA-Key as a specific AMSK...

Appendix F.1

IIRC we had a discussion whether the prf used to derive AMSK should be 
mandated or could be negotiated 
(http://mail.frascone.com/pipermail/eap/2004-March/002384.html). There 
is a trade off between the two options (simplicity & interoperability 
are in favor of mandating one but not putting a mandatory requirement on 
peers and servers favors allowing negotiation). This is not reflected in 
the current appendix. I'd like some more discussion on the matter....

_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap