On 2.3.2015, at 21.34, Michael Behringer (mbehring) <[email protected]> wrote: >>> Then one can always discuss what kind of information could go into each >> protocol after bootstrap. Perhaps what we actually need is a new bootstrap >> security protocol (not only for homenet), and that this is where the >> emphasis should be. >> >> Possibly. However, even if we had one, bootstrap protocol does not lead >> easily to widely shared PSKs, and that’s what routing protocols require. >> >> E.g. anima bootstrap stuff is focusing only on enrolling certificates. If I >> had a >> certificate, I am not sure how it helps with PSK IS-IS scheme. > > Well, draft-pritikin-anima-bootstrapping-keyinfra-01 describes a way to > bootstrap a certificate infrastructure, zero touch. Once every device in a > domain has a domain certificate, two devices can directly authenticate each > other, without PSK. Then you can also authenticate a key negotiation scheme > such as IKE, to negotiate a PSK which you can then use in your "normal" > authentication scheme. Obviously, would be nice if protocol supported certs > directly, but it’s not required.
IKE provides just symmetric crypto key between two parties. Typical network has more (and routing protocols use multicast). Multiparty IKE is more or less dead (or undead?). Remember, we need whole network to agree on the keys, or at least everyone on the link if any multicast is used in a way that requires authentication or confidentiality. (HNCP is designed to avoid transmitting anything important over multicast; are routing protocols? For most part, I think not.) I might be wrong, hopefully some points me at some asymmetric crypto enabled multi-party authentication method for _some_ routing protocol.. Only way I could imagine this working is by firing up metric shitload of on-demand (e.g. GRE) tunnels on top of IPsec (based on some yet undefined on-link peer detection scheme), then running some RP over them in p2p mode. Then we realize that all security needed is really in the peer-detection (which can be conservative, very rate limited and so on) and the IPsec, and we would require no security features from the routing protocol itself. > I still think that the above draft is a very good way to bootstrap a > certificate infrastructure, which can be leveraged in many different ways. It is relatively heavy in terms of number of protocols to the functionality I would want, but I agree that on the paper[1] it does what it advertises it does, but it is not enough to make routing protocols work in and of itself, see above. Cheers, -Markus [1] I have yet to see an implementation; I have heard one exists. _______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
