Hi Rob,
On 2/11/09 5:46 AM, "Rob Austein" <s...@isc.org> wrote: > > 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 Ack. > 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. Right, I also have a similar PoV. Although, and it may be an academic distinction - my reading is that if the XML operations are not truly idempotent then the 'CMS Signing Time' would have been a more pragmatic implementation. Was that analysis done? (apologies if it was, I quickly checked list archives but couldn't see if the question had been asked) > > 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 o.k. BTW is the rescerts-provisioning-05 RFC4346 is specified. RFC4346 is obsoleted by RFC5246. So if you do authentication and authorisation in the CMS, why do you need 2 way identification at the HTTPS layer if it's just for privacy? ie authentication of both parties versus server authentication with an unauthenticated client? (RFC5246 App F.) > existing technology (ie, TLS) instead, which makes some sense. ... I'm not sure why though.. :-( Maybe you can explain that to me over a beer. > TLS > also provides privacy (which it's not clear we need), and helps to > limit denial of service attacks to known entities. ummm Does it? > > 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. Maybe just a refocus on ''why'' TLS is used, and to what extent, given other architecture parts. > > FWIW, though, at least in my implementation, all the AAA logic is tied > to CMS, not TLS. Yes.. and having run your code I see that, which is why I ask some of the questions. > > 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", Maybe a clarification then required so people don't start trying to plug RPKI certs into provisioning engines for CMS? > 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. I think something, at some stage, might need to be documented given that the BPKI (as you put it) seems to be a first order layer for the conversation. (although note my comments above about the necessity for 2-way identification given the authentication/authorisation is done in CMS) > > The protocol nesting is tedious but straightforward: > > IP(TCP(TLS(HTTP(CMS(XML(up-down)))))) So, given that ASN.1 is fully capable of describing the data going back and forth (up/down). Why add the extra XML blob? btw, I think the draft needs to also reference the ITU' (nee CCITT) Recommendation X.208: Specification of Abstract Syntax Notation One (ASN.1). > > 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. thinking from a different point of view - noting that the draft is using HTTPS with identification of server and client, for replay and privacy - why not consider the W3Cs XML Signature Syntax? > > Hope this helps. > Sure does. Hope you had fun playing mini-golf. Terry _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
