Re: [Sidrops] Benjamin Kaduk's No Objection on draft-ietf-sidrops-rtr-keying-03: (with COMMENT)

[Sean Turner <[e-mail]>]

> On Jan 21, 2019, at 12:27, Benjamin Kaduk <[e-mail]> wrote:
> 
> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-sidrops-rtr-keying-03: No Objection
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-sidrops-rtr-keying/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> I know the intended status has been beaten to near death already, but I
> could see this as Informational as well as BCP.

This horse has been flogged.  I will do whatever I’m told :)

> Section 1
> 
>                                      For example, when an operator
>   wants to support hot-swappable routers, the same private key needs to
>   be installed in the soon-to-be online router that was used by the the
>   soon-to-be offline router.  This motivated the operator-driven
>   method
> 
> As the secdir review notes, there is no need to copy private keys to hot-swap routers
> (unless there is something special about the "hot-swap" case that nullifies
> the arguments he made?).
> 
> It rather seems that we should avoid framing this behavior as justified by
> a need for hot-swapping, but rather as something that people do to work
> around processes that do not admit the more secure workflow, as an
> operational reality.

Would something like the following work:

   The operator-driven model is motivated by ensuring the network operates.
   In some deployments, the same private key needs to
   be installed in the soon-to-be online router that was used by the the
   soon-to-be offline router (i.e., operators need to support hot-swappable
   routers.

BTW - I am totally open to wording suggestions.


> Section 2
> 
>   (see [RFC6470]), the protected the protected channel between the
> 
> nit: duplicate "the protected”

fixed

> Section 5
> 
>   The PKCS#10 request SHOULD be saved to enable verifying that the
>   returned public key in the certificate corresponds to the private
>   used to generate the signature on the CSR.
> 
> I mostly assume this is done by the party that generates the CSR, though
> perhaps one could read it as being done on the router always.  (I guess
> later on we do recommend both the operator and router to do this
> verification.) This could be reworded, though, either to remove the 2119
> language ("Retaining the CSR allows for verifying that [...]" or to apply
> to the actual verification as opposed to just the saving.

I am all about dropping 2119-lang where we can so will reword as suggested:

   Retaining the CSR allows for verifying that the
   returned public key in the certificate corresponds to the private
   used to generate the signature on the CSR.

> Section 5.1
> 
>   NOTE: If a router were to communicate directly with a CA to have the
>   CA certify the PKCS#10 certification request, there would be no way
>   for the CA to authenticate the router.  As the operator knows the
>   authenticity of the router, the operator mediates the communication
>   with the CA.
> 
> nit: I think that the thing we care about here is the CA's ability to show
> that the request is authorized.  The operator is assumed to have an
> account/relationship with the CA and a channel via which to authorize
> cert-signing requests.

Yes

>  In particular, "no way" is a rather strong
> statement, and would seem to deny the possibility of a three-party workflow
> where the router sends the CSR to the CA but the operator logs in to the CA
> independently and is presented with a list of pending requests to approve.
> (It would also preclude the operator from delegating their authorization at
> the CA to the router, as described in Section 8.)

Okay fair point.  Maybe we reword it to say:

  NOTE: The CA needs to now that the router-generated CSR is authorized.
  The easiest way to accomplish this for the operator to mediate the
  communication with the CA.  Other workflows are possible, e.g.,
  where the router sends the CSR to the CA but the operator logs in to the CA
  independently and is presented with a list of pending requests to approve.

Again, totally open to word smithing.

> Section 5.2 ("Operator-Generated Keys")
> 
>   Even if the operator cannot extract the private key from the router,
>   this signature still provides a linkage between a private key and a
>   router.  That is, the operator can verify the proof of possession
>   (POP), as required by [RFC6484].
> 
> This paragraph seems a bit of a non-sequitur -- if the operator just
> generated the key, it sure isn't going to need to extract the private key
> from the router to sign something using it!

Yeah if they just made it they certainly have access to it.  The concern was really more about router-driven models where there’s now way to get the private out so this paragraph ought to move to s5.1.

> Section 6
> 
>   In the operator-generated method, the operator SHOULD extract the
>   certificate from the PKCS#7 certs-only message, and verify that the
>   private key it holds corresponds to the returned public key.  If the
> 
> nit: "private key it holds" is the one the operator holds, not the PKCS#7
> certs-only message.  It's probably worth disambiguating, here.

I think you are suggesting the following:
r/private key it holds corresponds to the returned public key/
private key the operator holds corresponds to the returned public key in the PKCS#7 certs-only message.

> Section 7
> 
>   NOTE: The signature on the PKCS#8 and Certificate need not be made by
>   the same entity.  Signing the PKCS#8 permits more advanced
>   configurations where the entity that generates the keys is not the
>   direct CA.
> 
> Why are we talking about PKCS#8 (asymmetric key transport) signatures here
> at all?  This is the section about installing certificates!  I guess I am
> not terribly familiar with the RPKI, but in the Web PKI at least it's quite
> uncommon for the CA to be generating the private keys, so mentioning these
> together is a non sequitur to me.

In the WebPKI it’s really uncommon, but it is done in lots of other places, e.g., little devices with no human interface.  Some entity creates the keys enmass, farms ‘em out when requested, and these farmed keys are verified to make sure they come from the trusted key generation source.

But more to the point, the note is there because we do discuss PKCS#8 in s5.2.1 and it seemed like a good place to say hey - don’t assume the signatures are from the same place.  In most cases they will be but not necessarily.

> Section 8
> 
>   More PKI-capable routers can take advantage of this increased
>   functionality and lighten the operator's burden.  Typically, these
> 
> nit: most readers will not bind "this" to the right thing and will instead
> be left confused.

I am thinking I could just strike the ”this”.

> Why do we not mention the need to get the manufacturer-installed key
> material (or information thereof) to the operator?

But, I thought that’s what the entire 1st paragraph is about?

>   When a router is so configured, the communication with the CA SHOULD
>   be automatically re-established by the router at future times to
>   renew or rekey the certificate automatically when necessary (See
>   Section 9). This further reduces the tasks required of the operator.
> 
> Mentioning renewing certificates is natural, as they have a stated end time
> to prepare for.  Re-keying certificates is something of a different matter,
> and it would be nice to provide (a link to) some guidance on what
> timescales at which to rekey, if we're mentioning rekeying here.
> (draft-ietf-sidrops-bgpwec-rollover provides some related guidance, but I
> did not see much concrete on this point.)

We’d end up in a circular reference point then since they point to our document.  The thing here is that the lifetimes of the keys are entirely dictated by the PKI CPs and there’s more than one place to point.  Not sure I have good fix for this one.

Randy/Keyur?

> Section 9.4
> 
>   Currently routers often generate private keys for uses such as SSH,
>   and the private keys may not be seen or off-loaded from the router.
>   While this is good security, it creates difficulties when a routing
>   engine or whole router must be replaced in the field and all software
>   which accesses the router must be updated with the new keys.  Also,
> 
> This seems to be talking about key management for keys other than
> BGPsec-signing keys.  Isn't that out of scope for this document?

On the one hand yes, but on the other hand no.  Because this section is about overall router security we felt it ought to be included and I do not think that it hurts to keep it.  And, like people screw this up regularly.

>   any network based initial contact with a new routing engine requires
>   trust in the public key presented on first contact.
> 
>   To allow operators to quickly replace routers without requiring
>   update and distribution of the corresponding public keys in the RPKI,
>   routers SHOULD allow the private BGPsec key to be inserted via a
> 
> Making this a SHOULD is perhaps an overstatement, since AFAICT this
> functionality is not useful for the stated purpose unless the operator has
> access to private keys directly (whether by virtue of the operator having
> generated the keys or an extraction interface on the current routers).
> This is an inherent tradeoff, as stated, between the delay in
> update/distribution of public keys in the RPKI vs. reducing the risk of
> unauthorized key access.  I'm not making this a Discuss point because it's
> not exactly my tradeoff to make, but I do want to be sure that this is
> actually the tradeoff that SIDROPS wants to present to the community.

It’s definitely been in the draft for a while now.  I guess folks can speak up if they think it’s wrong.

Randy/Keyur?

>   protected channel, e.g., SSH, NetConf (see [RFC6470]), SNMP.  This
>   lets the operator escrow the old private key via the mechanism used
>   for operator-generated keys, see Section 5.2, such that it can be re-
>   inserted into a replacement router. The router MAY allow the private
>   key to be to be off-loaded via the protected channel, but this SHOULD
>   be paired with functionality that sets the key into a permanent non-
>   exportable state to ensure that it is not off-loaded at a future time
>   by unauthorized operations.
> 
> This last sentence is a somewhat different topic and could probably stand
> alone as its own paragraph.  This would also provde the opportunity to
> clarify that this offload interface is intended for use in conjunction with
> key generation, and the permanent non-exportable state to be applied
> thereafter.

How about:

   The router MAY allow the private key to be to be off-loaded via the
   protected channel after key generation, but this SHOULD be paired
   with functionality that sets the newly generated key into a permanent non-
   exportable state to ensure that it is not off-loaded at a future time
   by unauthorized operations.

> Appendix A
> 
> I agree with Mirja about the duplication of content and thus non-need for
> normative language.

Agreed. I removed the 2119-language from Appendix A.

spt