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

From: [email-masked] (Tschofenig Hannes)
Date: Tue, 8 Jul 2003 11:28:10 +0200

hi bernard, 

> Introduction
> 
> Typically an introduction provides an overview of the 
> problem, the general
> approach taken to solving it and the reasoning behind selection of the
> solution approach.
> 
> Reading this draft, I am unsure whether the objective is to create a
> single EAP method utilizing basic IKEv2 modes (certificate, pre-shared
> key) or whether the goal is to create another tunneling 
> method. Can you
> clarify?

jari gave us a comment on the previous version of the draft regarding the
missing/unclear introduction. i thought that i corrected it by copying a
proposal of dirk into the new version. 

unfortunately this change got lost somehow. this makes you comment
concerning the missing introduction much clearer. you are certainly right -
i should correct that. 

>> which non-IPsec security association would you like to create?

> IEEE 802.11 encrypted communications with TKIP or AES CCMP, or in the
> future, IEEE 802 LINKSEC.

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. 

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

>> you mean the eap header ouside the eap-ikev2 method? the eap payload
inside
>> ikev2 is protected.

> Right, the EAP header (Code, Identifier, Length, Type).

yoshi ohba pointed me to this problem with regard to fragmentation and the
eap success message. 

this sounds like a more general discussion. after some exchanges you have a
session key available which would possible allow you to protect the headers
(and some other payloads such as messages related to fragmentation). we
wanted to discuss the problem of protecting fragmentation specific messages
next sunday.  

thanks again for pointing us to open issues. 

ciao
hannes

---

From: [email-masked] (Bernard Aboba)
Date: Tue, 8 Jul 2003 05:47:12 -0700 (PDT)

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

> parts are missing at the moment).

Yes -- the IV is optional, I believe.