Terry, General comments only, I'm not going to attempt a point by point response on a beautiful autumn Sunday when my kids want to go play minigolf.
The combination of TLS and CMS was the result of advice the design group got from Steve Bellovin, Steve Kent, and Russ Housley when Randy and I asked them to review this protocol, back in 2007. The two mechanisms serve different purposes. We use CMS for authentication and authorization (is the entity requesting this action authorized to do so? etc). It's also intended to allow for audit: if one is paranoid, one can archive a copy of every CMS message and use it (along with archived PKI material) to prove at some later date that the action was properly authorized. So I view CMS as the main security mechanism here, and the one that's most closely aligned with the underlying semantics. TLS is present mostly to protect against replay attacks and other naughtiness. Our advisors saw our initial attempts to include replay protection in the CMS-signed XML messages and advised us to use existing technology (ie, TLS) instead, which makes some sense. TLS also provides privacy (which it's not clear we need), and helps to limit denial of service attacks to known entities. At this point, having written my own HTTPS implementation and seeing how weak (read: effectively nonexistant) the concept of a session is in HTTPS, I'm not convinced that TLS is providing all that much in the way of useful replay protection. At this point, though, we do have multiple interoperable implementations of this protocol using TLS, so unless it's actively harmful I'd just as soon leave it alone for now. FWIW, though, at least in my implementation, all the AAA logic is tied to CMS, not TLS. The PKI used for this (both CMS and TLS) is not the RPKI, it's a separate PKI (which the design group has been calling the "BPKI", because it mirrors the business relationships between certificate-generating entities). In the abstract, the BPKI can be anything that both parties to a particular conversation are willing to use, as this is only used in pairwise conversations and doesn't transit to third parties. The main thing is that the parent in a parent-child relationship gets to dictate the BPKI model to be used: this pretty much falls out of the hierarchical nature of the system. So my implementation, at least, has a particular model that I use when I'm the parent, and is (I hope) flexible enough to handle whatever model my parent might be using when I'm the child. I can go into more detail on the model I'm using, but I'm not sure that the WG really needs to sign off on that level of detail. The protocol nesting is tedious but straightforward: IP(TCP(TLS(HTTP(CMS(XML(up-down)))))) As far as different security models between this and the rest of the RPKI system: the difference is less extreme than it might at first appear. Other than the TLS wrapper discussed above, everything is object security, using either CMS or X.509-derived objects which were signed to begin with. Hope this helps. --Rob _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
