Re: [sidr] #11: Nit Report - provisioning protocol

["sidr issue tracker" <trac at tools.ietf.org>]

#11: Nit Report - provisioning protocol
-----------------------------------+----------------------------------------
 Reporter:  gih at …                  |       Owner:     
     Type:  defect                 |      Status:  new
 Priority:  medium                 |   Milestone:     
Component:  rescerts-provisioning  |     Version:     
 Severity:  In WG Last Call        |    Keywords:     
-----------------------------------+----------------------------------------

Comment(by gih at …):

 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

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/sidr/trac/ticket/11#comment:1>
sidr <http://tools.ietf.org/sidr/>