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

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

Return-Path: <jmh@joelhalpern.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CCB91310AB; Tue, 2 Oct 2018 13:06:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iQtVikfWfYFS; Tue, 2 Oct 2018 13:06:37 -0700 (PDT)
Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4974130FF0; Tue, 2 Oct 2018 13:06:37 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 96A1A1C040A; Tue, 2 Oct 2018 13:06:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; 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 b2.tigertech.net
Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id DA29F1C00E2; Tue, 2 Oct 2018 13:06:35 -0700 (PDT)
To: Brian E Carpenter <brian.e.carpenter@gmail.com>, Michael Richardson <mcr+ietf@sandelman.ca>, Randy Bush <randy@psg.com>
Cc: draft-ietf-anima-bootstrapping-keyinfra.all@ietf.org, Christian Huitema <huitema@huitema.net>, Eliot Lear <lear@cisco.com>, anima@ietf.org, Security Directorate <secdir@ietf.org>
References: <153826253306.18743.9250084704876465818@ietfa.amsl.com> <m2sh1qkebi.wl-randy@psg.com> <057bd957-06b4-824e-a7c8-214383819621@huitema.net> <m2murxi8ws.wl-randy@psg.com> <b4a32733-c2df-6bea-17d2-4d45ee4d5136@cisco.com> <m2wor0h9vu.wl-randy@psg.com> <1fd9c9d5-508f-901e-818c-3cc87725c331@cisco.com> <m2d0ssh661.wl-randy@psg.com> <2555.1538506845@localhost> <6b2f2b80-5e9e-101f-4aac-f182f638f8b1@gmail.com>
From: "Joel M. Halpern" <jmh@joelhalpern.com>
Message-ID: <e23fefe6-fcad-6c5c-fbef-9dac9270b42c@joelhalpern.com>
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: <6b2f2b80-5e9e-101f-4aac-f182f638f8b1@gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/pxWPTgWFL5B4rjVKPuNr8M-wQKM>
Subject: Re: [secdir] [Anima] Secdir last call review of draft-ietf-anima-bootstrapping-keyinfra-16
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Oct 2018 20:06:40 -0000

Off-list:

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.

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 <randy@psg.com>; 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
> Anima@ietf.org
> https://www.ietf.org/mailman/listinfo/anima
>