[OPSAWG] Benjamin Kaduk's Discuss on draft-ietf-opsawg-sdi-11: (with DISCUSS and COMMENT)

[Benjamin Kaduk via Datatracker <[e-mail]>]

Benjamin Kaduk has entered the following ballot position for
draft-ietf-opsawg-sdi-11: 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-opsawg-sdi/



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

I support Roman's discuss.

I don't think this document is sufficiently clear about the limits of
the scope of what it's trying to do.

An ideal solution in this space would protect both the confidentiality
of device configuration in transit and the authenticity (and
authorization status) of configuration to be used by the device.  This
document makes no real effort to do the latter, with the device
accepting any configuration file that comes its way and is encrypted
to the device's key (or not encrypted, as the case may be), and with no
attempt to keep the device's public key secret (which is just as well).
I would expect some disucssion of this being highly desirable, but also
requiring more complicated machinery (per, e.g., BRSKI and other
voucher-based methods) and that this document aims to provide something
much simpler, at the cost of only providing limited protection.
However, even the confidentiality protection has only a limited realm of
applicability, and it seems to fall apart in some plausible threat
models.

The security considerations rightly note that an attacker with physical
access can likely extract the device private key, retrieve the encrypted
configuration file, and decrypt the configuration contents.  However, I
don't think this possibility is necessarily limited to an attacker with
physical access.  An attacker on the network in the IXP/POP has several
routes to getting attacker-controlled configuration on the device,
whether by uploading to the configuration server, spoofing the DHCP
response to point to the attacker's configuration server, rewriting
traffic between the device and the configuration server, etc.  Once the
attacker has configuration on the device, they have a foothold by which
to gain remote access and use whatever interfaces the device provides
for decrypting configuration files and learning their contents
(potentially even by installing a "backdoor-type" access mechanism and
then running the normal install process for the legitimate encrypted
configuration, and using the backdoor to return and retrieve the
plaintext configuration information).

While this level of attacker control taking over a device in the process
of being installed is not a new attack with the encrypted configuration,
it does still limit the extent to which confidentiality protection for
configuration data is actually achievable, and I don't think the current
document text provides an accurate description of the risk and what
protection is provided.


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

Per the discussion in the DISCUSS section, the incremental improvement
offered by this mechanism is quite limited, to the extent that I wonder
if it's worth putting effort into at all.

Abstract

The first paragraph implies that there is not currently a secure way to
initially provision the device ("if there were"), but the second
paragraph implies that there are such mechanisms ("extends existing";
"more secure").  Which is true?

(Also, I'm reluctant to describe the procedure outlined by this document
as a "secure way" to do anything; it's better to talk about the
(limited) protection that is provided for the confidentiality of
sensitive configuration data, as other aspects of security are unchanged
by this mechanism.)

Section 1

   is it intended to solve all use-cases - rather it is a simple
   targeted solution to solve a common operational issue where the
   network device has been delivered, fibre laid (as appropriate) but
   there is no trusted member of the operator's staff to perform the
   initial configuration.

nit: the sentence structure here doesn't seem quite right -- the comma
before fibre sets us up for a list, but the "but" doesn't conclude a
list.  Perhaps replace the comma with "and"?

Section 2

   [RFC2131]).  The device then contacts this configuration server to
   download its initial configuration, which is often identified using
   the devices serial number, MAC address or similar.  This document

nit: "device's"

   [RFC4122]), but this will likely make it somewhat harder for
   operators to use (the serial number is usually easy to find on a
   device, a more complex system is likely harder to track).

nit: comma splice

Section 2.1

   discovers that it has not yet been configured.  It enters its
   autoboot state, and begins the DHCP process.  Operator_A' DHCP server

nit: "Operator_A's".

Section 3.1

   Each devices requires a public-private key keypair, and for the

nit: "device" singular.

   During the manufacturing stage, when the device is initially powered
   on, it will generate a public-private keypair.  It will send its
   unique device identifier and the public key to the vendor's
   Certificate Publication Server to be published.  The vendor's
   Certificate Publication Server should only accept certificates from

side note: in an X.500 or PKIX context this would likely be known as a
"directory server" rather than a "Certificate Publication Server".

   the manufacturing facility, and which match vendor defined policies
   (for example, extended key usage, extensions, etc.)  Note that some
   devices may be constrained, and so may send the raw public key and
   unique device identifier to the certificate publication server, while
   more capable devices may generate and send self-signed certificates.

Don't we need to give some guidance for integrity protecting the public
key data in transit from manufacturing facility to CPS?  The existing
text about only the manufacturing facility being authorized to do so is
helpful, but perhaps incomplete in this regard.

Section 3.2

   The certificate publication server contains a database of
   certificates.  If newly manufactured devices upload certificates the
   certificate publication server can simply publish these; if the
   devices provide the raw public keys and unique device identifier, the
   certificate publication server will need to wrap these in a
   certificate.

What should we say about the signing key used to sign such certificates?
Should it be in anything's trust store?  (No, obviously, but...)  They
clearly cannot be self-signed, since only the public key is sent to the
CPS...


I guess there also needs to be some logic in the baked-in device
firmware about where to publish the self-signed certificate that it
generates, which might contribute some operational fragility (but since
that environment is going to be pretty controlled anyway, probably not
much).

Section 4.2

   of the device).  The operator SHOULD fetch the certificate using a
   secure transport (e.g., HTTPS).  The operator will then encrypt the

It seems like the important part of "secure" transport here is the
source authenticity (and the integrity protection it depends on) --
without that the chain of custody that ties the device serial number to
the device key/certificate is broken.  Confidentiality protection may
not be as critical (though can still provide tangible benefit).

Section 4.3

   process, or will repeat this process until it succeeds.  When
   retrying, care should be taken to not overwhelm the server hosting
   the encrypted configuration files.  It is suggested that the device

(Wouldn't this apply equally to a server hosting unencrypted
configuration files?)

Section 5.2

   technique to install the device), or the device could prefer the
   operators installed key.  This is an implementation decision left to
   the vendor.

nit: either "operator's installed key" or "operator-installed key".

Section 5.3

   Increasingly, operations is moving towards an automated model of
   device management, whereby portions (or the entire) configuration is

nit: "portions of"

Section B.1.1

No love for ECC?

Section B.1.2

I expect that not all readers are familiar with the openssl '.' syntax
for DN entry and it's easy to miss next to the ":".  (Also, it's
possible to automate the process so that you don't get prompted for all
the irrelevant fields.)

Section B.1.3

   $ openssl req -x509 -days 36500 -key key.pem -in SN19842256.csr -out
   SN19842256.crt

Note that RFC 5280 says:

% To indicate that a certificate has no well-defined expiration date,
% the notAfter SHOULD be assigned the GeneralizedTime value of
% 99991231235959Z.

which may be preferable to arbitrarily claiming a 100-year lifetime.

Section B.2.2

CMS best practice would be AuthEnvelopedData rather than just
EnvelopedData, though the openssl cli doesn't support that yet
(https://github.com/openssl/openssl/pull/8024).

Section B.3.2

   $ openssl smime -decrypt -in SN19842256.enc -inform pkcs7\
     -out config.cfg -inkey key.pem

Do you need another space after the continuation line to avoid the
"-inform pkcs7-out" parse error?