[Sidrops] Eric Rescorla's Discuss on draft-ietf-sidrops-rtr-keying-03: (with DISCUSS and COMMENT)

[Eric Rescorla <[e-mail]>]

Eric Rescorla has entered the following ballot position for
draft-ietf-sidrops-rtr-keying-03: Discuss

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/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D13996



DETAIL
S 2.
>   
>      Operators are free to use either the router-driven or operator-driven
>      method as supported by the platform.  Regardless of the method
>      chosen, operators first establish a protected channel between the
>      management system and the router.  How this protected channel is
>      established is router-specific and is beyond scope of this document.

This seems rather under-specified. Given that we know that people are
not careful about this, I think you need to specify some sort of
minimum requirements for this channel. That need not be a particular
protocol, but it needs to specify the security properties it provides.
I see you have some SHOULD-level language later, but I think you need
MUST level, and as noted below, I think the guidance is wrong.


S 5.2.
>      the BGP Identifier when it sends the CSR to the CA.
>   
>      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].

It's not clear to me what is being claimed in terms of PoP here. As I
understand it, the certificate is a binding between the AS number/BGP
identifier pair and the public key, but if neither of those is in the
PKCS#10 request, then they're not signed over by the private key, and
so PoP isn't really operative. The relevant question is whether if I
obtain the PKCS#10 request I can obtain a certificate for an identity
other than the intended one.


S 5.2.1.
>      ensure the returned private key did in fact come from the operator,
>      but this requires that the operator also provision via the CLI or
>      include in the SignedData the RPKI CA certificate and relevant
>      operator's EE certificate(s).  The router should inform the operator
>      whether or not the signature validates to a trust anchor; this
>      notification mechanism is out of scope.

I don't understand what security this is intended to provide. As I
understand it, the way this works is that the operator signs the
PKCS#8 package and then sends it to the router, which verifies the
signature. This verification is performed based on a key configured by
the operator, right? But in that case, if someone obtains operator
access to the router, they can just configure their own key, thus
bypassing the signature check.
Secondarily, I don't understand how this works if the RPKI CA
certificate is included in the SignedData, because then how do I
validate it against a trust anchor. Finally, how does the router know
which of the large number of EEs signed by the RPKI CA it should
accept signed PKCS#8 messages from.




S 6.
>      private key it holds corresponds to the returned public key.  If the
>      operator saved the PKCS#10 it can check this correspondence by
>      comparing the public key in the CSR to the public key in the returned
>      certificate.  If the operator has not saved the PKCS#10, it can check
>      this correspondence by generating a signature on any data and then
>      verifying the signature using the returned certificate.

It is not clear to me that this is correct. You seem to be assuming
that it given a key pair (K_priv, K_pub), it is not possible to
generate a new key K_pub' that will validate signatures made with
K_priv. This isn't ordinarily an assumption we make of digital
signature systems.


S 8.
>          the CA prior to operator initiating the router's CSR.  CAs use
>          authentication material to determine whether the router is
>          eligible to receive a certificate. Authentication material at a
>          minimum includes the router's AS number and BGP Identifier as
>          well as the router's key material, but can also include
>          additional information. Authentication material can be

Surely it also includes some information that allows the router to
prove it is entitled to a key with that AS and BGP identifier, but I'm
not seeing this here.


S 12.1.
>      CSR you sent; the certificate will include the subject name, serial
>      number, public key, and other fields as well as being signed by the
>      CA.  After the CA issues the certificate, the CA returns the
>      certificate, and posts the certificate to the RPKI repository.  Check
>      that the certificate corresponds to the private key by verifying the
>      signature on the CSR sent to the CA; this is just a check to make

This is not the right check. The CSR contains the public key. If you
want to check, make sure it is identical to the one in the cert.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

S 1.
>      These two methods differ in where the keys are generated: on the
>      router in the router-driven method, and elsewhere in the
>      operator-driven method.  Routers are required to support at least one
>      of the methods in order to work in various deployment environments.
>      Some routers may not allow the private key to be off-loaded while
>      others may.  While off-loading private keys would ease swapping of

Nit: "off-load" has multiple meanings. I would suggest "exported"




S 1.
>      operator-driven method.  Routers are required to support at least one
>      of the methods in order to work in various deployment environments.
>      Some routers may not allow the private key to be off-loaded while
>      others may.  While off-loading private keys would ease swapping of
>      routing engines, exposure of private keys is a well known security
>      risk.

This is a somewhat shallow treatment of this. Specifically:

1. There are multiple ways in which a device might allow a key not to
be exported. For instance, there might not be a command, but it might
be in unencrypted NVRAM. Or, it might be in an HSM. These have very
different security properties.

2. There are designs which allow a key to be moved from device to
device without exposure, e.g.,, a hardware token.


S 1.
>      In the router-driven method, the router generates its own
>      public/private key-pair.
>   
>      The router-driven method mirrors the model used by traditional PKI
>      subscribers; the private key never leaves trusted storage (e.g.,
>      Hardware Security Module).  This is by design and supports classic

This seems overly concrete. The router may or may not have an HSM, but
there are benefits even if it does not.


S 1.
>      ensure that no one can impersonate the subscriber.  For non-humans,
>      this method does not always work.  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.

I'm not following this explanation, as it's routine for Internet
servers to have keys in software and be able to transfer them from
device to device. This is, after all, what PEM files do


S 1.
>      acting as the intermediary.  Section 8 describes another method that
>      requires more capable routers.
>   
>      Useful References: [RFC8205] describes gritty details, [RFC8209]
>      specifies the format for the PKCS#10 certification request, and
>      [RFC8208] specifies the algorithms used to generate the PKCS#10's

Nit "The PKCS#10's signature" is not grammatical


S 2.
>      method as supported by the platform.  Regardless of the method
>      chosen, operators first establish a protected channel between the
>      management system and the router.  How this protected channel is
>      established is router-specific and is beyond scope of this document.
>      Though other configuration mechanisms might be used, e.g.  NetConf
>      (see [RFC6470]), the protected the protected channel between the

"the protected the protected"


S 3.
>      bis] to return the issued certificate,
>   
>      - Using FTP or HTTP per [RFC2585], and
>   
>      - Using Enrollment over Secure Transport (EST) protocol per
>      [RFC7030].

I'm surprised you don't list ACME.


S 5.
>      is sometimes referred to as a Certificate Signing Request (CSR), may
>      be generated by the router or by the operator.
>   
>      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.

This is generally not necessary. In most systems, the private key
syntax either includes the public key or the public key can be
generated from the private key.




S 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.

This doesn't seem like it's necessarily true. For instance, with ACME
the operator could provide the router with a credential sufficient to
authenticate the request.


S 5.2.1.
>   
>   5.2.1.  Using PKCS#8 to Transfer Private Key
>   
>      A private key can be encapsulated in a PKCS#8 Asymmetric Key Package
>   
>      [RFC5958] and should be further encapsulated in Cryptographic Message

SHOULD?


S 10.
>      Private key protection in transit: Mistakes here are, for all,
>         practical purposes catastrophic because disclosure of the private
>         key allows another entity to masquerade as (i.e., impersonate) the
>         signer; transport security is therefore strongly RECOMMENDED.  The
>         level of security provided by the transport layer's security
>         mechanism SHOULD be commensurate with the strength of the BGPsec

I'm not sure "commensurate" is what's needed here. For instance, the
transport channel might be much more secure than the router key (e.g.,
P-521 and AES-256 with a RSA-2048 router key).

More generally, it's not clear to me that these are really connected
at all, as the threat environments are totally different. As noted
above, I believe you should just specify a minimal level.


S 12.1.
>      and integrity and replay protection.
>   
>   Appendix B.  The n00b Guide to BGPsec Key Management
>   
>      This appendix is informative.  It attempts to explain all of the PKI
>      technobabble in plainer language.

 All fields have jargon, but generally deriding another field's
language as "technobabble" doesn't seem that helpful.


S 12.1.
>      BGPsec speakers send signed BGPsec updates that are verified by other
>      BGPsec speakers.  In PKI parlance, the senders are referred to as
>      signers and the receivers are referred to as relying parties.  The
>      signers with which we are concerned here are routers signing BGPsec
>      updates.  Signers use private keys to sign and relying parties use
>      the corresponding public keys, in the form of X.509 public key

They're not in the form of public key certificates, they are carried
in certificates.


S 12.1.
>      that will generate the key pair for the algorithms referenced in the
>      main body of this document; consult your router's documentation for
>      the specific commands.  The key generation process will yield
>      multiple files: the private key and the public key; the file format
>      varies depending on the arcane command you issued, but generally the
>      files are DER or PEM-encoded.

Actually, it may or may not generate multiple files. That's
implementation specific.