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

Eliot Lear <> Mon, 01 October 2018 12:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D50AA130DDC; Mon, 1 Oct 2018 05:47:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.956
X-Spam-Status: No, score=-14.956 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.456, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ms_lOneKxQGs; Mon, 1 Oct 2018 05:47:44 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 29497130E60; Mon, 1 Oct 2018 05:47:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=14564; q=dns/txt; s=iport; t=1538398064; x=1539607664; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=VCIfZGsz71B8emzO/ZgrodXUtQgirjlmUhgr68FuHoM=; b=QEKmvICQih7NL+jexVolUzt6/oIPj/9AewM7Dhq2chkUrwpNuxQkz+eQ l0u6Sqgr8JBzWKEFymIQQBjA4Zgty0SWUCBRNpR2Juv7tIEcLZUOrMucj R+m3IWFpbBxwqk0NJtBsylfSHsRa5TiICZVyFDFnpEgNy46I7/1ARvbV0 o=;
X-Files: signature.asc : 488
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AZAADyFrJb/xbLJq1aGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBVINeEoQciHSNKi2RG4VTgWYIA4RsAoQxNxUBAwEBAgE?= =?us-ascii?q?BAm0ohTgBAQEBAgEjVgULCxgqAgJXBgEMCAEBgx0BgXkIpByBLh+JXA+CbYV?= =?us-ascii?q?OdhCBWIIAgRIngmuEOggWgyeCVwKIYxuTXE8JhAGBZoNqhl0GF4kFhkqVMYF?= =?us-ascii?q?YIoFVMxoIGxU7gm2QVT2KagEkB4IgAQE?=
X-IronPort-AV: E=Sophos;i="5.54,327,1534809600"; d="asc'?scan'208,217";a="6921976"
Received: from (HELO ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 01 Oct 2018 12:47:32 +0000
Received: from [] ( []) by (8.15.2/8.15.2) with ESMTP id w91ClVkx019355; Mon, 1 Oct 2018 12:47:31 GMT
To: Christian Huitema <>, Randy Bush <>
Cc:, IETF Rinse Repeat <>,, Security Directorate <>
References: <> <> <>
From: Eliot Lear <>
Openpgp: preference=signencrypt
Autocrypt:; prefer-encrypt=mutual; keydata= xsBNBFMe1UQBCADdYOS5APDpIpF2ohAxB+nxg1GpAYr8iKwGIb86Wp9NkK5+QwbW9H035clT lpVLciExtN8E3MCTPOIm7aITPlruixAVwlBY3g7U9eRppSw9O2H/7bie2GOnYxqmsw4v1yNZ 9NcMLlD8raY0UcQ5r698c8JD4xUTLqybZXaK2sPeJkxzT+IwupRSQ+vXEvFFGhERQ88zo5Ca Sa1Gw/Rv54oH0Dq2XYkO41rhxQ60BKZLZuQK1d9+1y3I+An3AJeD3AA31fJZD3H8YRKOBgqe ILPILbw1mM7gCtCjfvFCt6AFCwEsjITGx55ceoQ+t5B5XGYJEppMWsIFrwZsfbL+gP31ABEB AAHNJUVsaW90IExlYXIgPGxlYXJAb2Zjb3Vyc2VpbXJpZ2h0LmNvbT7CwJEEEwECADsCGwMC HgECF4ACGQEWIQSY0L2QRh2wkqeyYR2HtmtG2dJ6MwUCWxJwMwULCQgHAgYVCAkKCwIEFgID AQAKCRCHtmtG2dJ6MyMyCACXvtFjAYGMtOkD9MD4nI3ifFpkrj8xTMbXjrv5hdqmzRmQ0wqA 1U/OlZux+P/NaVMiZNZc8zw0nsx/INAqDOVd4/tLWF+ywTkeRFR0VnaUxLwCReZAZOaRS+md +52u/6ddoFja2RnjZ43qbbuvVUARQVIyMJz+GbR6mEZQHR0psD7dDYZDyrpivCxm8zHQwmB6 AZUlO7OJgljDvVPVDCabg/ZnJw1qS0OzSiNb0MySk1D5A7FdwDgeKxuMYUOOoVVTTMWNWcME UkRX9LxElswEt0PQWiz/j3FYXTxiFfl/1vKcHx4pM+E5C5mhTbrdFUFLJC3Y5fLID7stK/Ch aEaBzsBNBFMe1UQBCAC0WV7Ydbv95xYGPhthTdChBIpPtl7JPCV/c6/3iEmvjpfGuFNaK4Ma cj9le20EA5A1BH7PgLGoHOiPM65NysRpZ96RRVX3TNfLmhGMFr5hPOGNdq+xcGHVutmwPV9U 7bKeUNRiPFx3YdEkExddqV2E8FltT0x2FSKe2xszPPHB6gVtMckX5buI9p1K3fbVhXdvEkcY Y/jB0JEJGyhS5aEbct5cHUvDAkT81/YFK5Jfg8RRwu1q1t1YuIJSOWAZQ9J9oUsg6D9RpClU +tIFBoe3iTp1AUfJcypucGKgLYKtpu/aygcpQONHYkYW5003mPsrajFhReVF5veycMbHs4u5 ABEBAAHCwF8EGAECAAkFAlMe1UQCGwwACgkQh7ZrRtnSejOSuQgA27p2rYB7Kh20dym6V8c6 2pWpBHHTgxr/32zevxHSiXl6xvUCg5T8WUwfUk8OvgDcBErK/blDAMXQzSg3sp450JhR8RnX HXF5Zz2T04X7HnlIVJGwf2CjnwyEAJCqMzaCmI+g3Imvg/8L4nyBFvhlFHDv+kIvMiujyycj PAu7xxKplBs1/IEwmDoAMjneFmawvfeQnwdMhSKK8PjKSuzGU5uUmxj3GBfRqvTM0qpmhMPF OmDhJSmH55HLAky2MlmqJYXJPt/9EfSEhFiua1M6gLiuNEuPkp+8jcnHQqKr0IeHt8UqcwLt 2mGfIyl0FVdF9hvWPjNRzGbgqoT1Di03RQ==
Message-ID: <>
Date: Mon, 1 Oct 2018 14:47:30 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="gJihEWo3W3olZEykyEyFxsUWi3BreJY3D"
Archived-At: <>
Subject: Re: [secdir] Secdir last call review of draft-ietf-anima-bootstrapping-keyinfra-16
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 01 Oct 2018 12:47:48 -0000

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

> 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