Thanks Jari The choice is very much based on the intended characteristics of ad hoc networks. In particular the property that you can add new participants to a network without letting anyone already in the network know you are doing this until they turn up in your neighbourhood discovery, and then only knowing their identities (e.g. IP address). And that there can be no online authority to consult about anything.
Of course you can achieve the above with a single shared secret key. But that's a lose one device (and we will not be surprised to do that) lose everything scenario. We're not proposing it for universal use. Christopher -- Christopher Dearlove Senior Principal Engineer, Information Assurance Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 | Fax: +44 1245 242124 chris.dearl...@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: Jari Arkko [mailto:jari.ar...@ericsson.com] Sent: 25 November 2014 15:21 To: Dearlove, Christopher (UK) Cc: Martin Thomson; draft-ietf-manet-ibs....@tools.ietf.org; adr...@olddog.co.uk; gen-art@ietf.org Subject: Re: [Gen-art] Gen-ART review of draft-ietf-manet-ibs-03 FWIW, I have followed this discussion. I have to say that IBS would not necessarily be my first choice of crypto solutions, particularly in a standards track spec. But it is interesting. I do not mind the definition of a new ICV with IBS. But it does have the issues Stephen and and Martin point out. I have balloted No-Obj. Jari On 30 Oct 2014, at 11:46, Dearlove, Christopher (UK) <chris.dearl...@baesystems.com> wrote: > I have a number of problems with this (including at some points not being > clear what exactly is being defined), but I'll start with the first major > one. X generates a public key related to SSK. But that's useless, Y does not > know it. The whole point is that X and Y can be in total ignorance of each > other until Y receives a message from X. There is no secure channel from X to > Y to distribute a public key (including not via A). So now how does Y > validate PVT? All Y knows about X is X's identity. > > So you may believe we can do better (this needs to be retaining the key > properties we have here). So far I do not. I don't expect to either, but > we'll see. Note that a system that distributes public keys is a different > tradeoff in the space. A valid one, but not the one here. (It is neither > absolutely better or worse, as each has advantages over the other.) > > I think you are mistaken about the issue with RFC 6507. The issue you have is > that the authority knows all. But we didn't sleepwalk into that. That's > completely known, and acceptable in some cases. This is for use in those > cases. The issue similarly applies to MIKEY-SAKKE (RFC 6509) that is what RFC > 6507 was issued to support. (It also applies to various people offering > IBE-based encryption schemes for email, but that's another story.) > > And it's up front in this draft. From the Introduction > > The disadvantage referred to is that the trusted authority has > complete authority, even more so than a conventional certificate > authority. > > (and the rest of that paragraph). And it's said again in the Security > Considerations section. > > -- > Christopher Dearlove > Senior Principal Engineer, Information Assurance Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearl...@baesystems.com | http://www.baesystems.com > > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, > Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 > > > -----Original Message----- > From: Martin Thomson [mailto:martin.thom...@gmail.com] > Sent: 29 October 2014 18:48 > To: Dearlove, Christopher (UK) > Cc: adr...@olddog.co.uk; draft-ietf-manet-ibs....@tools.ietf.org; > gen-art@ietf.org > Subject: Re: Gen-ART review of draft-ietf-manet-ibs-03 > > ----------------------! WARNING ! ---------------------- This message > originates from outside our organisation, either from an external partner or > from the internet. > Consider carefully whether you should click on any links, open any > attachments or reply. > Follow the 'Report Suspicious Emails' link on IT matters for instructions on > reporting suspicious email messages. > -------------------------------------------------------- > > On 29 October 2014 03:52, Dearlove, Christopher (UK) > <chris.dearl...@baesystems.com> wrote: >> Any objection that something better can be done needs to provide that >> something better, not just say "asymmetric, therefore something better". > > That's a totally fair comment. I was trying for expediency, since that is > fairly obvious to me. Here's a rough sketch: > > A has the same properties you describe: a secret that only it knows > (KSAK) and a paired public value (KPAK) that it can distribute. > > X generates a secret (analogous to SSK) and passes a signature over some > material (optionally its identity, as you note above, plus the paired public > value) to A. A provides X with a signature over the both the public value > and identity that X can subsequently use to claim that identity to others > with the KPAK (analogous to PVT). X is expected to keep that value secret > also. > > Then X can send message in the form (data || PVT || sig(SSK, data || PVT)), > and Y can validate both sig and PVT to establish that this is valid. > > I'm not saying that this is strictly better. It is more complex; RFC > 6507 seems to cleverly roll the identity of X into the public key it uses to > sign. But this has the property that private keys aren't shared. That means > that you can implement this using an HSM that enforces a strict containment > for keys. It also means that you can establish a parallel bases for trust to > the single authority. > > > I think that this highlights the reason we call out downrefs in the process. > As a standalone information RFC, the abstract presentation of RFC 6507 is > perfectly innocuous. But it's application to a standards track effort does > open questions about suitability. > > You claim that this is an improvement over the status quo, and that is quite > clear. The scheme prevents participants from impersonating each other, which > might not have been possible with a system based on a shared symmetric key. > It does however, require that all trust is placed in an authority. I believe > that we can do better. > > Maybe the property I'm describing here not valuable in the deployment context > this is designed for and maybe this can be addressed by establishing firm > expectations about applicability. Maybe a simple applicability statement > would suffice. That is above my pay grade to decide. I'll defer to the IESG > on this one. > ******************************************************************** > This email and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > ******************************************************************** > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art _______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
