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

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

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6B390131160; Tue, 2 Oct 2018 17:33:30 -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 yqAevghqzOql; Tue, 2 Oct 2018 17:33:27 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::531]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BFDB11310E0; Tue, 2 Oct 2018 17:33:27 -0700 (PDT)
Received: by with SMTP id n31-v6so712830pgm.7; Tue, 02 Oct 2018 17:33:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=lGHesTmntO24QfXW32IfliD4vnz12JRxKcYPYF2b0sY=; b=s//ZP/JYqpRgkxwSaZBdKX/zHsLv8gbuHbsK8e9LUzPrnlP7DUnR3p4oa/LmXIiNGU irgTlE0wuQmkeW0mQ12wTTJrwQBw0d7RX1B8SFMjSL7nFpvHF4UL+a7EhADXp/ldI5X7 CazI+dXeJ8/H20GpaZ6+EDTGA0uhTwxeeG0fb6Wt2101JMU5VFP+nh8hkSutoMFcO5VS ztKdBeQaZuPfXvV1abIGUlfecySyQ5RozKd9wzufZlmyGA+ehSMmbvLfQXxOENI10wk7 hnPZ4vUESVSJ5vRPqqF1btYC+Nniksxqtn1gHy00Ap1+1Qv1oMK2Y/NjMGZJZfsbSZs7 Xp4A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=lGHesTmntO24QfXW32IfliD4vnz12JRxKcYPYF2b0sY=; b=ajnfkgE2dTQUgwfAwjMegxue+7Dn/PQv1WczB43eWIFYbuhpbjzHFis9M7BvP/xrsj e2yFcI9fBsTnY7aAt7duKTsVqMytahTXbmMIruFCivprmMXxzF86sDE9M1gXmqr5JAzD MKxPSO9uW4vdaacfTJUsOGcr3EETzRH1WG+96JRYENP1kWp4al3XNXWBY6pJ8HzYcnzd 7gHwXD4FzATnqDKiMinVKGOo9UJ+pYSip4vN++djtFpGxNtq3pCf/50WCDVJb2i/mOpJ d/10DIFMSJ1m7/AJNeVWCSJ5eKpco6v0Qpz942o/IqiH/jkgXq13uJBflEEe2VCv8rnM Y53A==
X-Gm-Message-State: ABuFfog0KqiLD6LdEPwyxLnwbNgEnYANyWcYK5//HywcS8hdCG+bKrin AL++UYXtKxZYuyxrc+QjT9Vzdxfl
X-Google-Smtp-Source: ACcGV60f2v0qyJQb4VUbBJ28XlFiOVUndAV1T2Hq+AJkGKBu2X0nK3iU8LUxInYsXioVTIjXO3dxxw==
X-Received: by 2002:a63:2106:: with SMTP id h6-v6mr16232693pgh.161.1538526806849; Tue, 02 Oct 2018 17:33:26 -0700 (PDT)
Received: from [] ([]) by with ESMTPSA id p17-v6sm22837086pfk.186.2018. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 02 Oct 2018 17:33:25 -0700 (PDT)
To: "Joel M. Halpern" <>, Michael Richardson <>, Randy Bush <>
Cc:, Christian Huitema <>, Eliot Lear <>,, Security Directorate <>
References: <> <> <> <> <> <> <> <> <2555.1538506845@localhost> <> <>
From: Brian E Carpenter <>
Message-ID: <>
Date: Wed, 3 Oct 2018 13:33:19 +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: <>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
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:33:30 -0000

On 2018-10-03 09:06, Joel M. Halpern wrote:
> Off-list:
> It sounds from you rnote like either:
> 1) Anima admission process is seriously underspecified in a way that 
> affects itneroperability, or

No, it's *intentionally* underspecified w.r.t. authorization. The registrar
is part of a specific autonomic networking implementation, so I think it's
OK that this is not standardized. Once there is established practice, it
might be time to revisit this.
> 2) BRSKI is actually irrelevant to ANIMA, and should be reviewed and 
> advanced (if desired) by some other working group.

I think BRSKI has the misfortune of being potentially quite general, but
it is in fact required by Anima as the basis for the initial secure

> I doubt either is your intention.

Indeed not.

> 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.

I think it's been thought through but badly articulated. In that sense,
the Last Call is doing its job.


> Yours,
> Joel
> 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
> .