Gorry, I've restructured the Privacy Considerations with https://github.com/anima-wg/anima-brski-prm/pull/151
I split it up into two subsections.
The diff is not too useful for this email, but the resulting section looks like
this:
# Privacy Considerations {#priv_cons}
The privacy considerations of {{!RFC8995}} also apply for BRSKI-PRM.
Two architectural changes in this document require some additional
consideration:
* the introduction of the additional component Registrar-Agent
* no TLS between Registrar-Agent and pledge
As logging is recommended to better handle failure situations, it is necessary
to avoid capturing sensitive or personal data.
Privacy-preserving measures in logs SHOULD be applied, such as:
* Avoid logging personally identifiable information unless unavoidable.
* Anonymize or pseudonymize data where possible.
## Registrar-Agent identity Privacy Considerations
The credentials used by the Registrar-Agent to sign the data for the pledge
SHOULD NOT contain any personal information about the owner/operator of the
Registar-Agent.
So for instance, issuing an EE certificate to the Registrar-Agent that has a
Subject DN saying something like "Frank Jones' Commissioning Tablet" would be a
problem.
Therefore, it is recommended to use an EE certificate associated with the
commissioning device instead of an EE certificate associated with the service
technician operating the device.
This avoids revealing potentially included personal information to any
eavesdroppers on the Registrar-Agent/Pledge communication.
Along the Registrar-Agent/Registrar communication path, if TLS 1.2 is used, the
client certificate details will be revealed to any on path passive attacker.
This is one of the advantages of using TLS 1.3.
## Registar-Agent/Pledge communications
The communication between the pledge and the Registrar-Agent is performed over
plain HTTP.
HTTPS can not be used as the Pledge's long-term IDevID certificate does not
contain a SubjectAltName that {{?RFC9525}} DNS-ID verification can use to
validate the certificate.
In order for this connection to be more secure, the Registrar-Agent would need
to know precisely which devices (down to the serial number) it expects to
onboard.
There are some very constrained cases where this might be the case, but for
many installations, it is not practical.
An active on-path attacker {{onpath}} could trivially impersonate the Pledge at
the network layer, which is exactly the same situation when not using TLS.
For many installations, a physical cable may be invoved (such as ethernet over
USB), or a very low power wireless network will be used.
Any active on-path attacker would have to be physically present at the site of
the device.
Such a physically present attacker could learn the identity of the Pledge by
simply pretending to be a Registrar-Agent, and asking the device for it's
identity.
It could equally do this over TLS/HTTPS.
An active on-path attacker can not replace the signed objects that the Pledge
and Registrar-Agent exchange.
Depending on the requests and responses, the following information is disclosed:
* the Pledge product-serial-number is contained in the trigger message for the
PVR and in all responses from the pledge.
This information reveals the identity of the devices being bootstrapped and
allows deduction of which products an operator is using in their environment.
As the communication between the pledge and the Registrar-Agent may be
realized over wireless link, this information could easily be eavesdropped, if
the wireless network is not encrypted.
Even if the wireless network is encrypted, if it uses a network-wide key,
then layer-2 attacks (ARP/ND spoofing) could insert an on-path observer into
the path.
* the Timestamp data could reveal the activation time of the device.
* the Status data of the device could reveal information about the current
state of the device in the domain network.
{{tpvr}} describes to optionally apply TLS to protect the communication between
the Registrar-Agent and the pledge.
The following is therefore applicable to the communication without the TLS
protection.
--
Michael Richardson <mcr+i...@sandelman.ca> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list -- anima@ietf.org To unsubscribe send an email to anima-le...@ietf.org
