Re: Secdir last call review of draft-ietf-anima-bootstrapping-keyinfra-16

[Eliot Lear <lear@xxxxxxxxx>]

Hi Christian,

On 01.10.18 07:42, Christian Huitema wrote:

If the manufacturer is willing to issue "good until time=X" vouchers,
then in theory you could provide the voucher to your buyer, provided the
time limit of the voucher has not elapsed. If the manufacturer signs a
voucher "good until infinity", then the device can in theory be sold and
resold forever. But that's probably not true in practice, because the
voucher is written for a specific domain, and includes the certificate
of the domain for which the voucher is good. You may be able to play
games with some kind of certificate chain and make it work, but I will
believe that when I see it.

IMHO it should be possible as an option to not pin the domain.  In that case, a voucher could be a scannable label or BOM that can be handed off directly with the device.  Obviously that's a nonceless option as well.  Think of it as a file that one simply uploads to the registrar.  The key thing here is that the manufacturer needs to make the decision for which devices it wants to do this.  This would also solve [6] in your list of issues.  However, this mitigation will not always be appropriate, particularly for devices that may transit from one network to another, or where it is simply inconvenient to retain a label.

Addressing some more of your LC comments:

1) Denial of service against the vendor MASA service. Adversaries could mount an
attack against the service at a critical time, preventing real-time issuance of
nonced vouchers. This could for example prevent the deployment of autonomic networks
during emergencies.

This can be mitigated by onboarding devices in inventory before the emergency.  It could also be mitigated as per the above.

2) Compromise of the vendor's public key. This would allow attackers to get
"ugly ducklings" imprinted in the domain.

Let's be clearer, because there are two separate threats:

1. A compromised end point inappropriately being onboarded in order to attack a network; where the registrar is validating the signature and certificate; and
2. A perfectly fine endpoint being inappropriately onboarded to an unauthorized network; where the endpoint is validating the signature and certificate.
   

Also, I think you are referring to the private key associated with a vendor certificate.  [1] can be mitigated by the registrar by the vendor reissuing the voucher signing cert and checking a CRL.  [2] requires a bit more care and a backup certificate of some form.

3) Rotation of the vendor's public key. This could prevent old devices from
joining the domain, or from verifying the new vouchers.

Old certificates never die.  They just fade away.  More seriously, if the cert is used, it should be kept available, unless a backup is also provided.

7) The closest to ship and forget is a MASA service configured to always
issue vouchers, regardless of the device ID and the registrar domain. I would
expect that to be popular with some manufacturers. It is mentioned in
section 6.4, which recommend that manufacturers should not do that. What
are the consequences if they still do? 

In a wireless scenario this could be problematic, since the device could imprint on the first network seen.  This presumes something like draft-lear-eap-teap-brski.txt.  We haven't gotten that far, but it is clearly an issue and something we want to discuss in Bangkok.  In a wired environment this is less of an issue, although there are still risks.

8) Attacks by the device. What happens if a device refuses to be imprinted?

It will not be able to trust the local environment, and may not be able to retrieve a local certificate.  I presume lots of issues would crop up from there.

11) Attacks by the MASA. What happens if the MASA refuses to provide a voucher,
or provides a wrong voucher? 

Same as above.  There is a mitigating factor against this behavior: the cost of a support call.

12) Device implementation of random numbers. The draft discusses management of 
time in a drop ship device, but what about the management of random numbers? For
example, what if poorly manufactured devices always generated the same nonce,
or a predictable nonce?

Then we have bigger fish to fry.  The device's crypto is broken.

13) Device individualization. The drop ship model assumes that devices are
shipped with factory default, but BRSKI also assumes that devices come with
individuals ID and certificate. This requires a specific per device step in
the manufacturing process. Some makers of inexpensive devices don't do that,
and ship devices that are all strictly identical. How does that affect the
BRSKI process?

It's a prerequisite, so...

14) Privacy considerations. Third parties will be able to observe traffic
between domain registrar and service provider MASA. They will at a minimum
be able to learn that domain X is a customer of provider Y. Can they do more?
The communication is protected by TLS. How much is revealed by clear
text components like the SNI? How much can be obtained by traffic
analysis?

This could be mitigated by using unpinned vouchers that come with the device.

Eliot

Attachment: signature.asc
Description: OpenPGP digital signature