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

From: [email-masked] (Tschofenig Hannes)
Date: Mon, 7 Jul 2003 10:34:02 +0200

hi bernard, 

thank you for your comments. 

> -----Original Message-----
> From: Bernard Aboba [mailto:[email-masked]]
> Sent: Friday, July 04, 2003 4:17 PM
> To: [email-masked]
> Subject: [eap] comments on draft-tschofenig-eap-ikev2-01.txt
> 
> 
> 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?

sure. unlike other methods eap-ikev2 actually provides both. the method is,
as such, applicable to a wide variety of environments. 

we noticed that some drafts add some framework aspects. we believe that this
is not really useful since eap allows the to be used in different scenario
(depending on the users / administrators choice). 

however, we it is true that the introduction still needs some work. 

> 
> Page 4, Message exchange:
> 
> When is the EAP Identity exchange necessary/useful in EAP 
> IKEv2?  IKEv2
> supports its own (protected) identity exchanges, and the method also
> allows nested EAP Identity exchanges.

it is true that eap-ikev2 provides user identity confidentiality for the
identities used in the tunneled eap exchange. 
however, the protection is only passive. if you stress one sentence (with
should not) in the ikev2 specification then you can use the eap identity
exchange and experience active user identity confidentiality for the
initiator. 

we have discussed this at the ipsec mailing list. however, user identity
confidentiality seems to be a minor issue for many people (strange enough). 

>  So you've got a lot of
> different (and potentially conflicting) identity information 
> available.

regarding the number of identities i guess there is no difference to other
tunneling drafts (if tunneling is used). 

we are open to simplifications (if possible).

> 
> Assuming that asymmetric IKEv2 features aren't used, can the 
> EAP server
> play the role of IKEv2 Initiator? This would save a round-trip, no?

in certain environments where you do not want to provide dos protection for
the responder and where you don't want to use legacy authentication that is
actually true. 

> 
> Page 6
> 
> "   Since the goal of this EAP method is not to establish an IPsec SA
>    some payloads used in IKEv2 are omitted. In particularly the
>    following messages and payloads are not required:
> 
>    - Traffic Selectors
>    - IPsec SA negotiation payloads
>      (e.g. CREATE_CHILD_SA exchange or SAx2 payloads)
>    - ECN Notification
>    - Port handling
>    - NAT traversal"
> 
> Yes, EAP IKEv2 need only carry out IKE SA creation. However, 
> a secure association
> does need to be subsequently negotiated. So there is the 
> question of how
> the IKE SA is subsequently bound to the (non-IPsec) Phase 2 SA.  Any
> thoughts on that?

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

> 
> Since address management is now supported within IKEv2, is 
> the intent to
> allow IP address assignment within EAP?

when we looked at securing the address configuration procedures in pana we
discussed a number of possible approaches. we also noticed that ikev2 offers
this functionality (not surprisingly since there was a long discussion about
it on the ipsec mailing list). this is a possible approach. still we think
that the pana-dhcp-bootstrapping approach provides a cleaner solution. 

> 
> Section 6
> 
> How is KEYMAT used to generate the MSK and EMSK?

we need to discribe this - thanks for pointing to it. 

> 
> Section 8
> 
> Does EAP IKEv2 utilize Notifications? If not, that should be stated
> explicitly.
> 
> It would be useful to have a discussion of error handling.  
> When does the
> method terminate with an EAP-IKEv2 method-specific error 
> message? Can an
> EAP Failure always be silently discarded prior to method completion?

true. we still need to provide proper error handling for the next version of
the draft. yoshi ohba already pointed us to this gap.

> 
> If the standard means of calculating IKEv2 MACs is used, then 
> the fields
> of the EAP header will not be covered.  Are there any security
> implications of this?

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

ciao
hannes

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

---

From: [email-masked] (Bernard Aboba)
Date: Mon, 7 Jul 2003 06:41:15 -0700 (PDT)

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

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

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