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

Brian E Carpenter <> Wed, 03 October 2018 00:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5F538131161; Tue, 2 Oct 2018 17:46:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id a18_4sl5p5ky; Tue, 2 Oct 2018 17:46:16 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::62e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DB45D131160; Tue, 2 Oct 2018 17:46:15 -0700 (PDT)
Received: by with SMTP id w14-v6so2556557plp.6; Tue, 02 Oct 2018 17:46:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=14+vZkBR0q65GO8kRo7KL5vDp5jlXDx0kwvB33wsH64=; b=gQfAcsnc9YD9Lbl9FShiLWx+/MXfiwWPz9ifBTulWer9Gaz0hXdY3Gys/dH+vWd9iS /eMRWoUnl6PCWLXAFuOxwZRqt7wi1ik/zqiyca43I9Fp8pxIaYyhjPebDfglQO2zdNab hUerckumv5HpD0bziG+T47nSeY5L+sttq6yHwgZrJiWqUSbDW1m0xc+6yPRr/WYt0/M7 TFDRmW3VKzs1lshZnRKIHc4DGS3ye51HXDi6PALIhKh+8JIf8FeMfwQI1OnW/DL77nU9 REcg4BiIT2RsC9r43sQzPKgeo6Gxgq7UvjxEJvucwRID/qlsHSbR34I+r+Ub+mo61xVK V4EA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=14+vZkBR0q65GO8kRo7KL5vDp5jlXDx0kwvB33wsH64=; b=L6MGFJbL1OYI/D7pMf21OEixLPBi0BaN8hHSHV2usslEhKJiV6l/OijpDOZ4u68q3C HKQN7LdLXZOe19gnWMlh9XHVbkUiK1fKsyMA+AGRaoWNWTntQFCAv9pTR1SeqEX/P3k7 qeF8xfc2Wf0JSbRV8lmdcU+Y0yJYHdOWbYC/4ilKErVBHTPB89VlgW1s552FAs1d60Cc cAhzNHOLXVNYdOuFUdjgWnX6VG2Q0cplUKXpiMGCeMw99v3MiHO85Gf9dy/AJXedGJhX z/Oqnu4g3Hx6WKEJvUDmhND6vv+AmNKJJZxUNef/G1JWzHNRsFTpnCWI4yEJPUcOe0V5 x42w==
X-Gm-Message-State: ABuFfogPXl4LxJLg8zk+32B8TNnQwMrUQEF+1hfU3dT+wFxoiZh1d4VZ L4Yh/QzK8aZ4dW4F5c2r6CqBgwH3
X-Google-Smtp-Source: ACcGV62ztK5YmRSKBb/bccG6Vzu+IVXdNmwpk4MQaLh33on3bpCicp5DTxM4I6hc0dYX0TAqmh4gJw==
X-Received: by 2002:a17:902:f096:: with SMTP id go22mr19254125plb.235.1538527574985; Tue, 02 Oct 2018 17:46:14 -0700 (PDT)
Received: from [] ([]) by with ESMTPSA id f15-v6sm22080442pgv.66.2018. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 02 Oct 2018 17:46:14 -0700 (PDT)
To: Michael Richardson <>,, Security Directorate <>
References: <> <> <> <> <> <> <> <> <2555.1538506845@localhost> <> <23133.1538520783@localhost>
From: Brian E Carpenter <>
Message-ID: <>
Date: Wed, 3 Oct 2018 13:46:09 +1300
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <23133.1538520783@localhost>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [secdir] [Anima] 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: Wed, 03 Oct 2018 00:46:19 -0000

On 2018-10-03 11:53, Michael Richardson wrote:
> Brian E Carpenter <> wrote:
>     > If I had my wishes, the MASA would be optional, with a local voucher
>     > store in the registrar as the alternative. But that wasn't the WG
>     > consensus.
> So you speak of non-expiring nonceless vouchers with wildcard for the domain
> owner, that would come with the device?  I.e. a bearer voucher/token on a QR code.
> We decided that such a thing was fraught with issues.
> So we painted around it, and declared that version out of scope for now,
> because we didn't think we were smart enough to figure out the security
> implications of it. (We did this in RFC8366, btw)
> In particular, we did not think it had a place in the medium to high-value
> devices that we expect ANIMA ACP BRSKI to deal with.
> [i.e. routers, VM hosts, NAS boxes... not light bulbs]

There are issues with not doing it too. I think the thing right now is that
the draft doesn't explain itself properly, hence this discussion.

I'm still gnawing on my original bone: if I was running a highly secure,
personnel-safety-critical network, like the particle accelerator control
network I used to run for a living, I *would not* allow it to rely on, and it would be physically impossible to do so because
there would be no physical link anyway. I would get my vouchers some
other way. This is not light bulbs either.

I believe this can be fixed by clearer scoping of the document, and
by renaming the "lower security" section as "alternative trust models"
or something.


> I think that there are better ways to deal with a bearer voucher,
> and that a layer of intermediation would help with the issues possible
> with a bearer token.  This may suit "ship and mostly forget" situation,
> but I also think it's squarely an IoT application, rather than appropriate
> for BFRs.
> --
> Michael Richardson <>ca>, Sandelman Software Works
>  -= IPv6 IoT consulting =-
> _______________________________________________
> Anima mailing list