> 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
