Subject: [Emu] draft-cakulev-emu-eap-ibake

From: "Cakulev, Violeta (Violeta)" <[email-masked]>
Date: Wed, 11 Jan 2012 14:16:15 -0600

All,
Back in IETF 80 we presented EAP-IBAKE. The link to the I-D is provided below:
http://tools.ietf.org/html/draft-cakulev-emu-eap-ibake-01

This EAP method is based on the Identity-Based Authenticated Key Exchange  (IBAKE) protocol.  IBAKE is a protocol for mutual authentication and key agreement between two or more endpoints. It is based on a public-key based authentication mechanism, where each message is encrypted with the public key of the corresponding endpoint, as per the Identity Based  Encryption (IBE) principles.  As a result of the IBAKE protocol, a shared symmetric key is generated by each endpoint.

EAP-IBAKE is specified in ETSI TS 102 690 (stage 2) and ETSI TS 102 921 (stage 3) as a method for access network independent device and gateway bootstrapping.
Both specifications are approved and are awaiting publication of EAP-IBAKE (among other things).

While this document could be of interest to emu WG, it would probably require changes to the WG charter.

Group's opinion about specifying EAP-IBAKE in emu WG as well as possible changes to the WG charter is highly appreciated.

Thanks,
-Violeta

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Thu, 12 Jan 2012 09:07:40 +0200

Hi Violeta, 

What problem are you trying to solve with this EAP method? 

Ciao
Hannes

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> ext Cakulev, Violeta (Violeta)
> Sent: Wednesday, January 11, 2012 10:16 PM
> To: [email-masked]
> Subject: [Emu] draft-cakulev-emu-eap-ibake
> 
> All,
> Back in IETF 80 we presented EAP-IBAKE. The link to the I-D is
provided
> below:
> This EAP method is based on the Identity-Based Authenticated Key
> Exchange  (IBAKE) protocol.  IBAKE is a protocol for mutual
> authentication and key agreement between two or more endpoints. It is
> based on a public-key based authentication mechanism, where each
> message is encrypted with the public key of the corresponding
endpoint,
> as per the Identity Based  Encryption (IBE) principles.  As a result
of
> the IBAKE protocol, a shared symmetric key is generated by each
> endpoint.
> 
> EAP-IBAKE is specified in ETSI TS 102 690 (stage 2) and ETSI TS 102
921
> (stage 3) as a method for access network independent device and
gateway
> bootstrapping.
> Group's opinion about specifying EAP-IBAKE in emu WG as well as
> possible changes to the WG charter is highly appreciated.
> 
> Thanks,
> -Violeta
> _______________________________________________
> Emu mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/emu

---

From: "Cakulev, Violeta (Violeta)" <[email-masked]>
Date: Thu, 12 Jan 2012 09:16:42 -0600

Hannes,
Thanks for the interest.

IBAKE was proposed and adopted as a method for device bootstrapping in ETSI M2M.
IBAKE is especially suitable in this setting as it is a method that provides mutual authentication and key agreement without the need to rely on third parties such as certificate authorities.
So the specific problem that is being solved in ETSI M2M with EAP-IBAKE is device bootstrapping that is access network independent.

Obviously, as an EAP method EAP-IBAKE can address many other problems (as numerous other EAP methods can).

Regards,
-Violeta

-----Original Message-----
From: Tschofenig, Hannes (NSN - FI/Espoo) [mailto:[email-masked]]
Sent: Thursday, January 12, 2012 2:08 AM
To: Cakulev, Violeta (Violeta); [email-masked]
Subject: RE: [Emu] draft-cakulev-emu-eap-ibake

Hi Violeta,

Ciao
Hannes

provided
endpoint,
of
921
gateway

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Thu, 12 Jan 2012 17:23:07 +0200

Hi Violeta, 

I believe it would be useful to solicit comments from a working group
like CORE, who works on this smart object space. In that group folks had
come up with their ideas on how to bootstrap security for these types of
devices. Of course, it has nothing to-do with identity based
cryptography. 

If you want to hear my personal opinion: I don't think that identity
based cryptography solves any real problems. 

Ciao
Hannes

> From: ext Cakulev, Violeta (Violeta) [mailto:violeta.cakulev@alcatel-
> lucent.com]
> Sent: Thursday, January 12, 2012 5:17 PM
> To: Tschofenig, Hannes (NSN - FI/Espoo); [email-masked]
> IBAKE is especially suitable in this setting as it is a method that
> provides mutual authentication and key agreement without the need to
> rely on third parties such as certificate authorities.
> So the specific problem that is being solved in ETSI M2M with
EAP-IBAKE
> is device bootstrapping that is access network independent.
> 
> > Both specifications are approved and are awaiting publication of
EAP-
> > IBAKE (among other things).
> >
> > While this document could be of interest to emu WG, it would
probably
> > require changes to the WG charter.
> >

---

From: "Cakulev, Violeta (Violeta)" <[email-masked]>
Date: Thu, 12 Jan 2012 09:57:01 -0600

Hannes,
Thanks for the comments/opinions.

While soliciting comments from CORE on EAP-IBAKE and bootstrapping in general would be most certainly helpful, ETSI M2M already concluded discussions on the choice of bootstrapping methods.
Both stage 2 (ETSI 102 690) and stage 3 (ETSI 102 921) are frozen and new methods will not be taken into consideration for rel. 1.

Given that EAP-IBAKE is a bootstrapping method in these specifications, we are trying to ensure appropriate review and timely publication of EAP-IBAKE I-D.

Regards,

-Violeta

-----Original Message-----
From: Tschofenig, Hannes (NSN - FI/Espoo) [mailto:[email-masked]]
Sent: Thursday, January 12, 2012 10:23 AM
To: Cakulev, Violeta (Violeta); [email-masked]
Subject: RE: [Emu] draft-cakulev-emu-eap-ibake

Hi Violeta,

Ciao
Hannes

EAP-IBAKE
EAP-
probably

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 12 Jan 2012 19:43:28 +0200

Hi Violeta, 

I am unfortunately familiar with the details of the ETSI Machine-to-Machine specifications to judge whether your draft meets their design requirements and fits into their architecture. I am sure lots of experts in ETSI have looked at this problem and have made a thoughtful decision. I wish them good luck deploying all their stuff. 

Having said that I feel that you are likely going into a problem that I have observed many times in the IETF: folks typically want to understand the problem they are trying to solve and they tend to be unsatisfied with the response "ETSI needs it.". 

Luckily things are looking good for you: If you do not seek publication of this EAP method as a Standards Track RFC then the process is fairly simple. In fact, you do not even go through the IETF to get a method ID. You can just dump the draft text into the appendix of the ETSI specification, drop IANA a mail, and you are done with it. 

The story is quite different if you want to get this standardized as a Standards Track RFC (which is what your draft currently says). 

Ciao
Hannes

---

From: "Cakulev, Violeta (Violeta)" <[email-masked]>
Date: Thu, 12 Jan 2012 12:41:20 -0600

Hannes,
Indeed the I-D currently states Standards Track RFC, but as my original email stated, we are trying to get WG's comments and opinion on the direction we should take. Certainly, if emu WG is not interested we will change the intended status.

As for 'where to specify it', other standard bodies are still looking to IETF to publish IP-based protocols/methods instead of specifying it in the appendix, which is the reason you've observed it many times in IETF.

-Violeta

-----Original Message-----
From: Hannes Tschofenig [mailto:[email-masked]]
Sent: Thursday, January 12, 2012 12:43 PM
To: Cakulev, Violeta (Violeta)
Cc: Hannes Tschofenig; Tschofenig, Hannes (NSN - FI/Espoo); [email-masked]
Subject: Re: [Emu] draft-cakulev-emu-eap-ibake

Hi Violeta,

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 15 Jan 2012 18:17:03 +0200

Hi Violeta, 

> Indeed the I-D currently states Standards Track RFC, but as my original email stated, we are trying to get WG's comments and opinion on the direction we should take. Certainly, if emu WG is not int…
I personally believe that you will not get the necessary support from the EMU working group to get the charter changed and the group interested in IBE. 
I can tell you that I will not spend my time on it. 

My reasons are being less excited are: 
* Identity based crypto as a technology does not really solve a problem. (In case you are going to ask: "yes" I looked it some time ago when I tried to figure out what value it provides for some IETF protocols. And guess what - I couldn't find any benefits.)
* "ETSI wants it" is not a good reason for me todo anything.
* I have so many other great documents to review. 
* The IPR situation with identity based crypto makes me feel uneasy. 

> As for 'where to specify it', other standard bodies are still looking to IETF to publish IP-based protocols/methods instead of specifying it in the appendix, which is the reason you've observed it…

For specifications where the policies for extending protocol requires you to come to the IETF then you should obviously do that. In case of EAP methods that is not needed. That's great - you should be celebrating. If you look around there are a couple of other technologies ETSI has been working on where the IETF was not involved, such as extensions to Diameter in form of new AVPs and new Diameter applications. They had no problems with that either. 

I would even say that specifications should only be published in the IETF stream if there is interest by IETF participants. An example from a different area: I have seen requests for MIKE key exchange protocols coming to the IETF where there was absolutely not interest in the IETF but the policy for new MIKEY extension required IETF Standards Track specifications. This lead to the publication of specifications that barely anyone reviewed and nobody wants (other than the authors). Needless to say that I have my doubts about the bright deployment future of these protocols. 

Ciao
Hannes

PS: Consider my public feedback as a friendly advice that will help you save a few years of work.