RE: Issue 9: Identity Protection Closed

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

sounds good to me. 

> -----Original Message-----
> From: Yoav Nir [mailto:ynir@CheckPoint.com]
> Sent: Thursday, July 03, 2003 11:49 AM
> To: Tschofenig Hannes; '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
> 
> 
> I agree.  This should either be omitted or else rephrased:
> 
> "Note that if IKE passes an indication of initiator identity 
> in message 3 of
> the protocol, EAP based prompts for Identity MAY be omitted."
> 
> Can we agree on this phrasing?
> 
> -----Original Message-----
> From: Tschofenig Hannes [mailto:hannes.tschofenig@siemens.com]
> Sent: Thursday, July 03, 2003 10:45 AM
> To: 'Yoav Nir'; '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
> 
> 
> 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
> >
>