Hi Violeta, On Jan 12, 2012, at 8:41 PM, Cakulev, Violeta (Violeta) wrote:
> 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. > 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 many times in IETF. 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. > > -Violeta > > > -----Original Message----- > From: Hannes Tschofenig [mailto:hannes.tschofe...@gmx.net] > Sent: Thursday, January 12, 2012 12:43 PM > To: Cakulev, Violeta (Violeta) > Cc: Hannes Tschofenig; Tschofenig, Hannes (NSN - FI/Espoo); emu@ietf.org > Subject: Re: [Emu] draft-cakulev-emu-eap-ibake > > 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 > > On Jan 12, 2012, at 5:57 PM, Cakulev, Violeta (Violeta) wrote: > >> 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:hannes.tschofe...@nsn.com] >> Sent: Thursday, January 12, 2012 10:23 AM >> To: Cakulev, Violeta (Violeta); emu@ietf.org >> Subject: RE: [Emu] draft-cakulev-emu-eap-ibake >> >> 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 >> >>> -----Original Message----- >>> 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); emu@ietf.org >>> Subject: RE: [Emu] draft-cakulev-emu-eap-ibake >>> >>> 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:hannes.tschofe...@nsn.com] >>> Sent: Thursday, January 12, 2012 2:08 AM >>> To: Cakulev, Violeta (Violeta); emu@ietf.org >>> Subject: RE: [Emu] draft-cakulev-emu-eap-ibake >>> >>> Hi Violeta, >>> >>> What problem are you trying to solve with this EAP method? >>> >>> Ciao >>> Hannes >>> >>>> -----Original Message----- >>>> From: emu-boun...@ietf.org [mailto:emu-boun...@ietf.org] On Behalf >> Of >>>> ext Cakulev, Violeta (Violeta) >>>> Sent: Wednesday, January 11, 2012 10:16 PM >>>> To: emu@ietf.org >>>> 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: >>>> 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 >>>> _______________________________________________ >>>> Emu mailing list >>>> Emu@ietf.org >>>> https://www.ietf.org/mailman/listinfo/emu >> _______________________________________________ >> Emu mailing list >> Emu@ietf.org >> https://www.ietf.org/mailman/listinfo/emu > _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
