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

[Sean Turner <[e-mail]>]

> On Jan 23, 2019, at 23:57, Eric Rescorla <[e-mail]> wrote:
> 
> 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.

Alissa had a comment in the same vein so I hope to address both here.

In the future, routers may come with key material burned into them that the router can then use to securely communicate with the operator (e.g., brewski or something akin to what’s in s8), but the reality is that the routers arrive with nada on them.  So, s2 is about how the operator gets keying material into the router that it can then later use to secure communications with the operator.  There’s two ways to get this done and there’s an initial leap of faith that has to happen (i.e., there’s -no- security on first connect):

- the operator connects directly through the “craft” port and “squirts” the keying material in and configures the router to use SSH (or whatever) for future connections.  It’s also going to set up it’s AS number and whatever else goes in the config file to make the protocol run.

- the operator connects over a network port and squirts the keying material in and configures the router to use SSH (or whatever) for future connections.  But, chances are very high that the operator connects to the router via SSH, and probably with some generic lame pwd.

So while I agree we want to better specify what kind of protections this channel should provide I am unsure what to write if the router has no keying material whatsoever when the operator gets first it.

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

1st baed on somebody else’s comment we’re moving that paragraph to s5.1.  It’s out of place in s5.2 because If the operator can generate the key well they certainly have access to it.

The POP we’re getting is that the router has the key.	If there’s nothing in the CSR but the operator is the middle-man then the operator can tell the CA this CSR goes with this name though some other means.

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

You are right on the first part.  

The thing that is probably not well explained in s4 is that physical attacks are thwarted by initial operator configurations, e.g., setting pwd, require SSH cert auth, configuring the AS number, etc.  Granted this configuration is not going to is not going to stop nation state attackers, but we’re not trying to address that.  So, I am hoping that some additional words in s4 about additional configurations will address this, but I wanted to check with you before proposing a bunch of words that would miss the mark you’re aiming at.

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

The TA is installed as part of the set-up procedure in s4.

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

Again, this goes back to the operator configurations.  Once, the router has been configured with its ASN it will be able to check that the certificate used to sign the key includes that ASN.

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

This is just a consistency check and you are right what you would do is either check that the public sent in the CSR matches the one in the returned certificate if you saved the CSR or regenerate the public from the private and then check that it matches the one returned in the certificate if you did not save the CSR.

OLD:
  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.

NEW:
  If the operator has not saved the PKCS#10, it can check
  this correspondence by regenerating the public key from the
  private and then verifying the regenerate public key matches
  the public key returned in the certificate.

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

I guess maybe I am confused because I thought that’s what the entire bullet was about.  The operator is priming the CA with information that will allow the router to begin contacting the CA without the operator in the middle.

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

Changed to:

  Check that the certificate corresponds to the public
  key contained in the CSR sent to the CA; ...

> ----------------------------------------------------------------------
> 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"

ack

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

I agree it’s a little/lot shallow, but I am not sure what digging deeper is going to accomplish here especially in the intro.

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

Yeah I know, but honestly I am not sure how to fix this other than laying out all of the deployment options.  And, like I just do not have the energy for that.

> 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

I tweaked this based on BenK’s comment.  While it is true that some keep them in software not all do.  There was concern that if you’re running with a HSM that you couldn’t get the key out to put it in another router’s HSM.  And, yeah this is all kind of odd because you might be able to just move the HSM over or use a networked HSM.  But, that was the concern: that there would be a one-to-one relationship of key to router and if the router goes down you’re SOL. 

> 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

I will drop the '

> 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”

Couple of people noticed this.  Fixed.

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

This way predates 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.

Agreed, but somebody was adamant about including one way you could do this so I just left it in.

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

Ben had a similar comment so I tweaked it.

> 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?

Yes I think that was the intention.

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

Commensurate is probably the wrong word, I was shooting for "at least as good as."

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

Honestly, I was kind of poking fun at myself, but I get your point.  I changed it to:
 explain some of the PKI lingo in plainer language

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

ack

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

Fair point.  I will replace with:
r/multiple files: the private key and the public key
/one or more files for the private key and the public key

spt