Subject: [eap] comments on draft-tschofenig-eap-ikev2-01.txt

From: [email-masked] (Tschofenig Hannes)
Date: Tue, 8 Jul 2003 16:35:08 +0200

hi bernard, 

thanks for raising russ's requirements on key derivation. 

the current text in the eap-ikev2 key derivation section suggests to reuse
the key derivation function proposed in section 2.17 of ikev2. this is the
key derivation function which is used for creating ipsec sas. without pfs
(which i assume is not necessary of eap-ikev2) the key derivation function
is : KEYMAT = prf+(SK_d, Ni | Nr)

ikev2 (and hence eap-ikev2) only include nonces (the SK_d key is again based
on nonces only) and does not something like cookies, id payloads of the two
parties, etc. into the key derivation. we will update the key derivation
function to incorporate these payloads if necessary. 

reading russ's requirements i had the impression that his main concern is
primiarly towards the protocol which uses the keys (key material)
afterwards. this might be, for example, link layer encryption (or better a
protocol for establishing the security association which are used to provide
link layer security). 

actually we had a number of questions during the process of working on pana
/ dhcp bootstrapping. we looked at the existing documents which address this
problem e.g. your "EAP Keying Framework" draft, the "AAA key distribution"
draft and russ's slides from the last ietf. when we tried to write down a
key derivation function which fullfills the requirements we thought that
there might be a need to illustrate the security properties a little bit
more. we hope to get more details on it during the next ietf.

ciao
hannes

> -----Original Message-----
> From: Bernard Aboba [mailto:[email-masked]]
> Sent: Tuesday, July 08, 2003 2:47 PM
> To: Tschofenig Hannes
> Cc: [email-masked]; Kroeselberg Dirk
> Subject: RE: [eap] comments on draft-tschofenig-eap-ikev2-01.txt
> 
> 
> > if i understood eap and the keying framework correctly (i 
> hope so :-)) then
> > the actual usage of the session keys derived with eap 
> should be independent
> > of the eap method itself. wouldn't it defeat the purpose of 
> the keying
> > framework if everyone specifies how to derive keys for 
> these particular
> > environments. please correct me if i am wrong.
> 
> EAP methods do not derive sessions keys. They derive keying 
> material --
> much as IKE Phase 1 derives the keying material used to subsequently
> derive IKE Phase 2 SAs.
> 
> To satisfy Russ's requirements an EAP equivalent of IKE Phase 2 is
> subsequently necessary, and the question is how EAP methods 
> (Phase 1) bind
> their keying material to the Phase 2. This is what Russ referred to as
> "key naming".  In order to know which EAP Phase 1 keying 
> material is to be
> used to form the Phase 2 SA, presumably the EAP method needs to export
> a "key name" of some kind.
> 
> During the EAP WG meeting at IETF 57 we'll try to get some 
> clarity about
> exactly what the "key name" is.  Most existing EAP methods 
> have something
> equivalent to this.  For example, in EAP TLS, TTLS or PEAP it is the
> "sessionid" + Client/Server identities -- this uniquely describes the
> session, and therefore the keying material arising from it.  
> In EAP IKEv2,
> I believe that the equivalent is the IKE Cookies + the ID 
> payloads of the parties.
> 
> The "key name" needs to be provided to the NAS along with the "keying
> material" by AAA, and then used by the NAS in the Phase 2 key 
> exchange in
> order to inform the peer what keying material is being used 
> to derive the
> transient session keys as part of the Phase 2 exchange.
> 
> I'd note that there may be other alternative possiblities for 
> providing
> the "key name", but they tend to involve lots of computation 
> on the EAP
> peer.  For example, a hash of the keying material can be sent 
> by the NAS,
> but that divulges a lot of information about the key itself, 
> and may not
> meet Russ's requirement for algorithm independence.  Also, if 
> there are a
> lot of potential keys (as there might be say, where fast handoff is
> supported), then the EAP peer might have to go through quite a few
> computations in order to find keying material that matches a 
> particular
> hash.  For example, the keying material for AP C might be 
> derived from the
> EMSK derived during an exchange at AP B, or it might be a 
> transferred PMK
> from AP A or AP B, or...  With a unique "key name" things are much
> simpler (and faster) because the EAP peer just looks up the 
> key in the key
> cache using the key name.
> 
> > hence with regard to the keying framework the eap-ikev2 
> would export the
> > msk, emsk and the iv only. these keys have to be derived 
> from the ike-sa (as
> > mentioned by you the draft needs to be more specific at 
> that place - some
> > parts are missing at the moment).
> 
> Yes -- the IV is optional, I believe.
>

---

From: [email-masked] (Bernard Aboba)
Date: Tue, 8 Jul 2003 07:44:06 -0700 (PDT)

> is : KEYMAT = prf+(SK_d, Ni | Nr)

Russ's requirements are that compromise of a single NAS not result in
compromise at other NASes.  I think this requires cryptographic
independence between keying material at each NAS.

There is also a requirement for freshness both in the keying material and
in the transient session keys.  Typically a nonce exchange in both phases
will accomplish this.

> function to incorporate these payloads if necessary.

I don't think that the "key name" needs to be part of the key derivation
to qualify -- it's just an identifier that uniquely identifies the
security association -- much as the SPI and dest address do for IPsec
(phase 2 SAs).

The answer to the question "what is the key name?" is usually provided by
asking the question "if I wanted to continue the exchange, or do a rekey,
how would I identify what SA is to be continued/rekeyed?"

> protocol for establishing the security association which are used to provide

Yes, most of the requirements are satisfied in the Phase 2 protocol
(freshness of transient session keys, secure capabilities negotiation,
mutual authentication, replay protection, binding of transient session
keys to the secure association, key synchronization).  However, there is a
requirement for "key naming" which is critical in linking the EAP (Phase
1) exchange to the subsequent secure association (Phase 2) exchange.

So far, this aspect has been neglected because the link was fairly trivial
-- the Phase 2 always occurred between the same parties as Phase 1 and
there was only one Phase 2 SA possible between a peer and NAS.

However, with roaming and things like LINKSEC on the horizon, things get a
lot more complicated.  The Phase 2 SA may be generated from a Phase 1
(EAP) conversation run over a different NAS;  the Phase 2 SA could be
generated from an MSK or an EMSK; there could be more than one Phase 2 SA
generated from a Phase 1 SA, each with different security parameters.

To make sure that the system works in these scenarios the requirement for
"key naming" is critical -- otherwise there is no way to make it clear to
the peer what key is relevant to a particular Phase 2 conversation.

> more. we hope to get more details on it during the next ietf.

I think this is a very good discussion to have during IETF 57, during the
Thursday session.  I am not sure we will end up with a lot of answers, but
at least we will have identified the questions.

---

From: [email-masked] (Joseph Salowey)
Date: Tue, 8 Jul 2003 09:28:45 -0700

> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Tschofenig Hannes
> Sent: Tuesday, July 08, 2003 7:35 AM
> To: 'Bernard Aboba'
> the current text in the eap-ikev2 key derivation section 
> suggests to reuse the key derivation function proposed in 
> section 2.17 of ikev2. this is the key derivation function 
> which is used for creating ipsec sas. without pfs (which i 
> assume is not necessary of eap-ikev2) the key derivation 
> function is : KEYMAT = prf+(SK_d, Ni | Nr)
> 
> ikev2 (and hence eap-ikev2) only include nonces (the SK_d key 
> is again based on nonces only) and does not something like 
> cookies, id payloads of the two parties, etc. into the key 
> derivation. we will update the key derivation function to 
> incorporate these payloads if necessary. 
> 
> reading russ's requirements i had the impression that his 
> main concern is primiarly towards the protocol which uses the 
> keys (key material) afterwards. this might be, for example, 
> link layer encryption (or better a protocol for establishing 
> the security association which are used to provide link layer 
> security). 
> 
> actually we had a number of questions during the process of 
> working on pana / dhcp bootstrapping. we looked at the 
> existing documents which address this problem e.g. your "EAP 
> Keying Framework" draft, the "AAA key distribution" draft and 
> russ's slides from the last ietf. when we tried to write down 
> a key derivation function which fullfills the requirements we 
> thought that there might be a need to illustrate the security 
> properties a little bit more. we hope to get more details on 
> it during the next ietf.

[Joe] You might also want to look at 

http://www.ietf.org/internet-drafts/draft-salowey-eap-key-deriv-01.txt

This draft outlines a way to consistently derive keys from the EMSK for
different applications to maitain separation and avoid conflicts. 

> (Phase 1) 
> > bind their keying material to the Phase 2. This is what 
> Russ referred 
> > to as "key naming".  In order to know which EAP Phase 1 keying
> > material is to be
> > material" by AAA, and then used by the NAS in the Phase 2 
> key exchange 
> > in order to inform the peer what keying material is being used
> > to derive the
> _______________________________________________
> eap mailing list
> [email-masked]
> http://mail.frascone.com/mailman/listinfo/eap
>