Martin Thanks you for your comments.
There are various contexts where an authority having access to the keys is acceptable - I will just refer to the company I work for as working in a possible field (as do several other MANET participants). If this were being offered as the only way to do things, I agree that would not be acceptable, but instead it's there as an option for those people (and the WG feedback indicated there were a number) for whom this is a suitable solution, with other options also supported. (Which to use in your network is a management issue. A draft on MANET management is in the system somewhere, it should - I haven't checked if it currently does - mention this.) I am also not aware of a solution that overcomes this problem without introducing different limitations, so it is a question of tradeoffs. This is one point in that tradeoff space. If anyone has a clearly superior solution that both avoids the need to trust an authority, and without introducing other limitations, then there are many of us in the ad hoc network community (and elsewhere, as just one example, to improve on 6507) who would like to see it. Note that all of the previously specified options (in RFC 7182) rely on keys shared by all participants, which is clearly weaker in some regards (but acceptable to many, hence also a valid option). Revocation is enabled by this, but we are not, I believe, in a position to specify that. It would, in any applications I'm aware of, be necessary to either include a trusted (to revoke, at least) authority in the fielded network (which defeats part of the point here) or rely on an out-of-band process to, for example, distribute a blacklist of identities. There is also the option to incorporate time (in some manner) into identity and let identities expire without renewal - not as good as revocation, but with some value. But I believe this to be beyond the scope of this draft. In particular it cannot simply be fitted into this framework, as it raises new questions about how to trust the revocation. (Revocation is not discussed in 6507 either.) That said, I will look again at what is said about revocation in order to see if any additional comments (e.g. one saying you could maintain an out of band distributed blacklist, if you have a trustworthy distribution mechanism, but that is beyond the scope of this document) are appropriate in the security considerations section. I would plan to collect all IETF LC comments first. And fix that nit! 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 [email protected] | 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:[email protected]] Sent: 24 October 2014 03:36 To: [email protected]; [email protected] Subject: 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. -------------------------------------------------------- I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at < http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-manet-ibs-03 Reviewer: Martin Thomson Review Date: 2014-10-23 IETF LC End Date: 2014-10-27 IESG Telechat date: (if known) Summary: Ready with questions. The language is quite clear and precise. I did find that comprehension required a non-trivial amount of digging into other documents, but nothing was particularly hard to find. This has a downref to 6507 (I see this in the shepherd writeup). Questions: The security considerations notes that the trusted authority has access to private keys. That would seem to defeat much of the benefit of using asymmetric crypto here. Why is this considered acceptable in this context? (I'd have thought it to be unacceptable in any context when superior alternatives exist.) The document mentions revocation, but does not seem to specify anything. If that is intentional, shouldn't the draft be more forward about that? (I only skimmed 6507 and the other docs, so I apologize if I missed something. Nits: S4.1: duplicate "in in" S5: It's probably not necessary to amend the reserved codepoints in the registry: that rots quickly. ******************************************************************** 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 [email protected] https://www.ietf.org/mailman/listinfo/gen-art
