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

Brian E Carpenter <brian.e.carpenter@gmail.com> Wed, 03 October 2018 00: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 5F538131161; Tue, 2 Oct 2018 17:46:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
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: 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 a18_4sl5p5ky; Tue, 2 Oct 2018 17:46:16 -0700 (PDT)
Received: from mail-pl1-x62e.google.com (mail-pl1-x62e.google.com [IPv6:2607:f8b0:4864:20::62e]) (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 DB45D131160; Tue, 2 Oct 2018 17:46:15 -0700 (PDT)
Received: by mail-pl1-x62e.google.com 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; d=gmail.com; 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; d=1e100.net; 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 [192.168.178.30] ([118.148.76.40]) by smtp.gmail.com with ESMTPSA id f15-v6sm22080442pgv.66.2018.10.02.17.46.12 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 02 Oct 2018 17:46:14 -0700 (PDT)
To: Michael Richardson <mcr+ietf@sandelman.ca>, 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> <23133.1538520783@localhost>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Message-ID: <acea1a3a-b2ec-5381-128c-b13e903c1158@gmail.com>
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: <https://mailarchive.ietf.org/arch/msg/secdir/PjOKTU3CPlb9ysD0hLzN8wFhUlU>
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: Wed, 03 Oct 2018 00:46:19 -0000

On 2018-10-03 11:53, Michael Richardson wrote:
> 
> Brian E Carpenter <brian.e.carpenter@gmail.com>; 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
masa.vendor.com, 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.

   Brian

> 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 <mcr+IETF@sandelman.ca>;, Sandelman Software Works
>  -= IPv6 IoT consulting =-
> 
> 
> 
> 
> 
> _______________________________________________
> Anima mailing list
> Anima@ietf.org
> https://www.ietf.org/mailman/listinfo/anima
>