RE: Issue 9: Identity Protection Closed

[Tschofenig Hannes <hannes.tschofenig@siemens.com>]

hi yoav, 

i initially requested to drop the following sentence from section 3.16 of
ikev2-v8: 

"Note that since IKE passes an indication of initiator identity in message 3
of the protocol, EAP based prompts for Identity SHOULD NOT be used." 

if you allow to eap as it is (with the eap identity exchange) then
everything is fine. to me it seems that the SHOULD NOT prevents you from
performing an eap identity exchange and you have to use the identity
provided with message (3) from the initiator.

ciao
hannes


> -----Original Message-----
> From: Yoav Nir [mailto:ynir@CheckPoint.com]
> Sent: Thursday, July 03, 2003 8:48 AM
> To: 'Yoshihiro Ohba'; 'Barbara Fraser'
> Cc: ipsec@lists.tislabs.com; tytso@mit.edu; angelos@cs.columbia.edu;
> 'Tero Kivinen'
> Subject: RE: Issue 9: Identity Protection Closed
> 
> 
> It is possible to have some convention, like sending an empty 
> ID_KEY_ID from
> the client, or even adding a new ID type ID_ANON_USER.  In 
> this case, the
> gateway will do a full EAP, including the EAP-Identity 
> request/response.  If
> the user sends its ID in some other form, the gateway will 
> only do the short
> version of EAP (less two packets).
> 
> This will give users a trade-off between speed and identity 
> protection, and
> it does not require a change to the IKEv2 draft.
> 
> -----Original Message-----
> From: owner-ipsec@lists.tislabs.com 
> [mailto:owner-ipsec@lists.tislabs.com]On
> Behalf Of Yoshihiro Ohba
> Sent: Wednesday, July 02, 2003 11:21 PM
> To: Barbara Fraser
> Cc: ipsec@lists.tislabs.com; tytso@mit.edu; 
> angelos@cs.columbia.edu; Tero
> Kivinen
> Subject: Re: Issue 9: Identity Protection Closed
> 
> 
> Hi,
> 
> I'm working mainly in PANA WG and EAP WG and I recently joined this
> list.  Please allow me to send this email after only rough reading of
> the thread on this issue.
> 
> First of all, I agree that there is no need to change IKEv2 protocol
> behavior to support identity protection from active attacks.
> 
> One way to address this is to use an anononymous identifier in IKEv2
> ID payload sent by initiator and use a real identifier in an
> EAP-Identity exchange (or an identity exchange that may be defined in
> a particular EAP authentication method in IKE_AUTH exchange).
> 
> If fact, a similar approach already exists.  For example, some
> EAP-TTLS implementation allows an EAP peer to use an anonymous
> identity (e.g, anonymous@foo.bar.com) in the EAP-Identity
> request/response carried outside the TLS tunnel, and use a real
> identity (realname@foo.bar.com) in the EAP-Identity request/response
> performed inside the TLS tunnel.
> 
> On the other hand, the following sentence in section 3.16 of the
> ikev2-08 draft seems to be a bit restrictive (if the above solution is
> valid)
> 
>    "Note that since IKE passes an indication of initiator identity in
>    message 3 of the protocol, EAP based prompts for Identity 
> SHOULD NOT
>    be used."
> 
> So, I'd like to suggest either removing the sentense or revising the
> sentense to:
> 
>    "Note that since IKE passes an indication of initiator identity in
>    message 3 of the protocol, EAP based prompts for Identity 
> SHOULD NOT
>    be used if the initiator identity passed from IKE is used as the
>    EAP peer identity."
> 
> 
> Regards,
> Yoshihiro Ohba
> 
> 
> 
> On Wed, Jul 02, 2003 at 10:58:07AM -0700, Barbara Fraser wrote:
> > Hi folks,
> >
> > Ted and I would like to officially state that the issue of 
> addressing
> > identity protection against active attacks is not going to 
> be included in
> > the base IKEv2 document. This decision was made months ago. 
> There are ways
> > to address this outside the IKEv2 base specification, 
> should folks want to
> > start up a new working group.
> >
> > Thanks,
> > Barb and Ted
>