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

"Joel M. Halpern" <> Tue, 02 October 2018 20:06 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6CCB91310AB; Tue, 2 Oct 2018 13:06:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 iQtVikfWfYFS; Tue, 2 Oct 2018 13:06:37 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B4974130FF0; Tue, 2 Oct 2018 13:06:37 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 96A1A1C040A; Tue, 2 Oct 2018 13:06:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=2.tigertech; t=1538510797; bh=hevd1REdMoVykcFAStM2DCVxDMn/oeww/1WH7NXP5dA=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=bSK1L2kgKsE91gkVFyUwGIrb6pWIdOdCU75sXZERVhdBWQY9DcmPgZm/x8JkVZWYT 1CZVrToCA/3BaHPuB7ICM8vpxAIVc2tec2EF5kXqVKkhZY45FYxsPSttLYRSU1ZH05 NY53qCoRcWsJcvo8AVBy5QWg4FlMj3NeJisXjHJA=
X-Virus-Scanned: Debian amavisd-new at
Received: from Joels-MacBook-Pro.local ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id DA29F1C00E2; Tue, 2 Oct 2018 13:06:35 -0700 (PDT)
To: Brian E Carpenter <>, Michael Richardson <>, Randy Bush <>
Cc:, Christian Huitema <>, Eliot Lear <>,, Security Directorate <>
References: <> <> <> <> <> <> <> <> <2555.1538506845@localhost> <>
From: "Joel M. Halpern" <>
Message-ID: <>
Date: Tue, 2 Oct 2018 16:06:34 -0400
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: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
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: Tue, 02 Oct 2018 20:06:40 -0000


It sounds from you rnote like either:
1) Anima admission process is seriously underspecified in a way that 
affects itneroperability, or
2) BRSKI is actually irrelevant to ANIMA, and should be reviewed and 
advanced (if desired) by some other working group.

I doubt either is your intention.
And statements such as Eliot's ill-formed comment that no one would do 
that do not help the case for the Anima WG having thought this through.


On 10/2/18 3:46 PM, Brian E Carpenter wrote:
> On 2018-10-03 08:00, Michael Richardson wrote:
>>      lear> I think we've lost sight of what we're talking about.  We're talking
>>      lear> about a completely automated method for a local trust anchor to be
>>      lear> installed on a device, and a kick to EST for the device to receive a
>>      lear> local credential.  For that to happen there needs to be a trusted
>>      lear> introduction, and the device manufacturer or its agent is in the best
>>      lear> position to do that.
>> Randy Bush <> wrote:
>>      > no.  the owner's trust controller is.
>> Cool.  It's a relief to know that we've missed something obvious.
>> Could you please explain things more?
>> We call the owner's trust controller the "Registrar", or sometimes the
>> Join-Registrar/Coordinator.  I don't mind calling it a trust controller, but
>> maybe your term has a different meaning.
> There's a point that close followers of Anima may know and that others
> don't. There is a topic intentionally missed out of the BRSKI document,
> which is how the registrar decides whether a particular device, let's
> say device X12345, is allowed to join the secure domain in question.
> This point is skated over in the draft; in fact there is a text glitch
> in section 5.2 where it should be stated, already known to the authors.
> (Sorry, but we didn't find that text glitch soon enough to fix it before
> the IETF Last Call.)
> The actual authorization mechanism - "X12345 is allowed to join" - is
> not part of BRSKI. It is, as Randy rightly implies, not the business
> of the manufacturer.
> The MASA is used only to verify that X12345 is in fact X12345. It's
> part of the trust model, not the authorization model.
> 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.
>      Brian
> _______________________________________________
> Anima mailing list