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

Brian E Carpenter <brian.e.carpenter@gmail.com> Tue, 02 October 2018 19:46 UTC

Return-Path: <brian.e.carpenter@gmail.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 4A7D21310B0; Tue, 2 Oct 2018 12:46:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 2jyutI7u_Mx9; Tue, 2 Oct 2018 12:46:30 -0700 (PDT)
Received: from mail-pf1-x443.google.com (mail-pf1-x443.google.com [IPv6:2607:f8b0:4864:20::443]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03B1A1310AB; Tue, 2 Oct 2018 12:46:30 -0700 (PDT)
Received: by mail-pf1-x443.google.com with SMTP id c25-v6so158816pfe.6; Tue, 02 Oct 2018 12:46:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=RBJ1d0Y2FJ0NRy3aQO7xTgD4YIJfWRJgJmVbmoZdjok=; b=ZFV2IWrUXXfXHgIC1iZUhmRqaIbd/JlWUJGc//FMLjPO0hJJqdeTYg82Jc2PykC+3c jiNNOU5TH0awX8FALYAlVej1jRFXnvdQAhGqMCZGY3ckonaDRgFNGLwVgu66QLE/j0Uh SS01XG1iAKhaRTYBQaL5vNm8DaWEtmG/QGOA7VXsRK5R9A2uR1vncPKqF6/fRjT98KkB 1uac0LeszzJV1Jp32qbvJdA0wCgMQrzgJmAsIOAUll8yM8WstIfX/oBPvdVoJed/GqDo QZu5zA6GdkoMwwwiP91ul6yoyLvJUecV3T+CfJn4OAX16Zu7EqeJBwsX7Yv6o73hz0pG uTpQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; 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=RBJ1d0Y2FJ0NRy3aQO7xTgD4YIJfWRJgJmVbmoZdjok=; b=YYELoNQiQElnXi0cW47KIfqVj3PYoZ9LdtGrmjXdkQCDrf1bZR6zZvkAMN2z4HYV1f nfu6eKEt5x6U4padSRazm4ct4J8IlToTxJ+otb0xMFOc02toLj5NogvRDe+wbx5nNfyz XciGJDft17DlHQVTGIM43weaT4Sddky+K3JCY8G43grEDsIKw2RENpVtpZz75sbxo8WV b6ZwMnkg8sa5lZQnkwAia6om7+q8ZaYZ6w0hjP3+99T41MzVSxjqHBN7A/+8wKkYi4jx TIHFRqZqufNH9FCruy9ETcRXXJp8z+RIs3uKrqv1WpsbBHJYcG+N1BCfDQQbMImLk8Ps GBLA==
X-Gm-Message-State: ABuFfojgTPvKE3hFyAD6PMhJFnU9sterNRw9LOA9TNMfKJFHDzVwed/w CmYLVwMk6DfdxU4YXr8dsvQfkf8a
X-Google-Smtp-Source: ACcGV61PochD+3zjYIIuWVPtWqBAUu9VZrKLLBytR5u+YoypAtGY4kZK7Wgrux61JYZ8kOQwrNya6g==
X-Received: by 2002:aa7:83cb:: with SMTP id j11-v6mr13844945pfn.91.1538509589229; Tue, 02 Oct 2018 12:46:29 -0700 (PDT)
Received: from [192.168.178.30] ([118.148.76.40]) by smtp.gmail.com with ESMTPSA id w23-v6sm22499056pgi.18.2018.10.02.12.46.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 02 Oct 2018 12:46:28 -0700 (PDT)
To: 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>, anima@ietf.org, Eliot Lear <lear@cisco.com>, 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>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Message-ID: <6b2f2b80-5e9e-101f-4aac-f182f638f8b1@gmail.com>
Date: Wed, 3 Oct 2018 08:46:17 +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: <2555.1538506845@localhost>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/qtft57BTibVWYqF8NCoso9iglE4>
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 19:46:32 -0000

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