>From my perspective, and with support shown in the WG, this is an option that >several people want. The need for a trusted authority is a minus point, but >acceptable by some users and should not be blocked because it is not ideal for >everyone. (The only other so far standardised options, based on shared keys, >also are not ideal for everyone.) If there were a method that retained all of >the advantages of this approach and removed the need to trust the authority, >that would be a different matter, but I do not believe such a method is known. >Note that this approach has at least one advantage Martin had not picked up on.
-- 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: Adrian Farrel [mailto:[email protected]] Sent: 28 October 2014 13:02 To: [email protected]; [email protected] Cc: [email protected] 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. -------------------------------------------------------- All, This document has completed IETF last call, but it seems to me that this conversation may not be complete yet. Please continue it and try to reach resolution. The document is on the IESG telechat for 11/25 and I am confident that you will reach some agreement (if only agreement to disagree) by then. Until that time I will enter a Discuss ballot to track this as an open issue. Thanks, Adrian > ________________________________________ > From: Dearlove, Christopher (UK) > Sent: 27 October 2014 10:04:41 (UTC) Dublin, Edinburgh, Lisbon, London > To: Martin Thomson > Cc: [email protected]; [email protected] > Subject: RE: Gen-ART review of draft-ietf-manet-ibs-03 > > I didn't say this, and perhaps I should have, but while signature uses > the private > key, verification uses the sender's identity (included in the > packet/message) and > the user-independent public information only. > > -- > 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: Dearlove, Christopher (UK) > Sent: 27 October 2014 09:42 > To: 'Martin Thomson' > Cc: [email protected]; [email protected] > Subject: RE: Gen-ART review of draft-ietf-manet-ibs-03 > > > I'm not 100% clear on the architecture here, but I've inferred that participating > nodes receive a private key from the trusted authority and a set of > public keys for > other trusted nodes. > > No, and that's where the win is here. You receive a private key (which includes > some public information). You have no advance knowledge of what other > nodes there are, and no key state that depends on other nodes. You can > even field a node (thus cutting any connection with the authority) > when which other nodes are to be trusted hasn't even been decided. > Each node is keyed independently (except for the requirement to have > unique identities) and in a O(1) operation, > not O(N), where N is the number of nodes. This is appropriate to some > ad hoc networks. > > A node of course has a public key - but it's its identity (e.g. IP address). And just > to forestall an obvious point, the security does not depend on the > size of the identity space. > > -- > 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 19:31 > To: Dearlove, Christopher (UK) > Cc: [email protected]; [email protected] > 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 24 October 2014 11:17, Dearlove, Christopher (UK) > <[email protected]> wrote: > > 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). > > It's fairly obvious that any entity that is trusted to assert identity > can arbitrarily > impersonate. But PKIX doesn't require that end entities share private > keying material with certification authorities. > > I'm not 100% clear on the architecture here, but I've inferred that participating > nodes receive a private key from the trusted authority and a set of > public keys for > other trusted nodes. This could work equally well if the nodes were > able to instead distribute their own public key to the authority. > > I'm OK with making revocation out of scope, but it's not particularly prominent, > and that decision is a major constraint on the operational approach > you need when deploying something like this. > ************************************************************** > ****** > 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
