Benjamin Kaduk via Datatracker <[email protected]> wrote: > I don't think this document is sufficiently clear about the limits of > the scope of what it's trying to do.
I would generally agree: the scope needs more work.
For instance, deploying a new device into your cabinet/cage, where there is
no opportunity for external connectivity, or where the device only retrieves
it's configuration from the MGMT interface would make sense.
In such a situation, the encryption of the configuration file protects the
operator against remote-hands doing nefarious things with the contents of the
configuration file.
For instance, retrieving "encrypted" password hashes from the file.
(I would mount this attack via compromises of the remote-hands order entering
system... Probably involving some social engineering at some point)
> 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
I think that a key thing here is whether the device can be configured to not
accept an unencrypted file. That would improve the situation a lot, I think.
> 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.
How much can we get from this simpler situation, aimed at operators.
This mechanism advances the state of the art, normalizes provision of
certificates into all devices. It does not specify a way to retrieve the
certificate/public-key for encryption, or really nail down a specific format
for encryption.
A configuration file could contain, for instance:
brski-est-bootstrap fe80::1234%ge0
That could be done with a future document that interacts with the BRSKI-MASA
protocol: the certificate/public-key being a new kind of nonce-less voucher.
The point is to provide a baby-step for vendor and operator towards BRSKI,
without commiting them to running a local CA.
> 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).
The key ought to be in a TPM, so I think that the key can remain safe, but I
agree that there is potential for such an attacker to get access to the
encrypted configuration file this way.
Many IXPs make it rather hard to do attacks in this way, as the often lock
down all the layer-2 stuff. That's not universal yet, but it is increasingly
common.
> 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.
--
Michael Richardson <[email protected]>, Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
