The underlying cryptography is defined in RFC 6507. That is authored from CESG, who essentially stand in the same relationship to GCHQ as NIST do to the NSA. Experts in other words. Googling, you can find current CESG interest in implementing MIKEY-SAKKE (RFC 6509, of which RFC 6507 is a component). If there were a simple replacement with all the required properties, and not requiring trust in an authority, they (and at least one other expert I have communicated with) would be using that. So would I, and the other MANET WG members who have supported this draft.
I am not going to try to explain the underlying mathematics. See RFC 6507 and its references. It's an impossibility for me to try to say "it has to be this way". Any objection that something better can be done needs to provide that something better, not just say "asymmetric, therefore something better". Here is the key property that anything better also has to achieve. Authority A, users X and Y. A and X exchange information. It happens that this can be either one way (identity and key material A to X) or two way (identity X to A, key material A to X). But any (sensible) number of messages back and forth would be acceptable. This exchange mentions no other user than X. (In particular it can't mention Y, Y might not even exist at this point.) X now departs, and a similar exchange takes place between A and Y. No other user (including not X) is mentioned. The key material held by both X and Y is of fixed size, not dependent on the number of possible users, which is unbounded. (It might be acceptable to relax this last sentence constraint, depending on how it was relaxed.) Now X is capable of signing a message that Y can verify as being sent by an X who was keyed by A in the same way that Y was. (Specifically, based on the same master secret held by A, which is never revealed by this.) And vice versa. Note that in both cases X and Y have no a priori knowledge of even the existence of the other. This is most clearly so for Y to X, because X departed A before Y contacted A. This process does not require A to be present. (A may even not exist by this point, it is possible to destroy A after keying X and Y, which may be desirable to some, though it denies the possibility of later adding Z. There have also been people using identity based methods who have put A into tamper-resistant hardware to make reading the master secret hard.) It's clear that A must hold something independent of X and Y. That this is a master secret that allows the authority to do anything is, agreed, undesirable, but my understanding (not an expert, I just talk to them) is that this is the state of the art. (Actually the state of the art - of identity based cryptography in general, not necessarily the specific RFC 6507 realisation - may permit things like splitting A into A and B, but A and B could collude to act like a single A.) I would, as I have said, more than welcome something that removed this limitation. But whether it is an acceptable limitation depends on the user community. It will be acceptable for some, and this option is there for them. -- 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: 28 October 2014 23:41 To: Dearlove, Christopher (UK) Cc: [email protected]; [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 28 October 2014 06:37, Dearlove, Christopher (UK) <[email protected]> wrote: > 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. I'm not sure that I'll be able to close on this quickly, since all I have from Christopher's description is a distinct vibe of snake-oil, which is very unfair and almost certainly hugely inaccurate. I don't believe for a minute that this is what we're talking about, so I must be misunderstanding something. As I understand the information flow, new nodes acquire a private key from some trusted source, which is constructed in such a way that they are able to make assertions about their identity (an IP address, if I understand correctly) that will be accepted by other nodes who also trust that authority. I know just enough about crypto to know that something like this might be possible, but it's outside of my direct knowledge. What I was thinking was that if you go to the trouble of using asymmetric crypto, then you already have the pieces to build a system that doesn't require sharing of private keying material between any two parties. Then trust can be disconnected from the authority to some extent (you might trust X because of previous things X did, whereas now, you don't know for certain that X is the same X because the authority might have given the keys to a new X). All that requires is that there is a two way exchange with the authority rather than a one way exchange between the device and the authority. I freely admit that I don't understand whether there might be some restrictions on the construction of the private key such that it binds some additional information, maybe you can explain. (Small words, I'm not a cryptographer, I just use it.) ******************************************************************** 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
