Re: [Anima] Adam Roach's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)

"Joel M. Halpern" <jmh@joelhalpern.com> Mon, 15 July 2019 04:45 UTC

Return-Path: <jmh@joelhalpern.com>
X-Original-To: anima@ietfa.amsl.com
Delivered-To: anima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F313120046; Sun, 14 Jul 2019 21:45:15 -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 GuG4VBcqGBgK; Sun, 14 Jul 2019 21:45:13 -0700 (PDT)
Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (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 46441120020; Sun, 14 Jul 2019 21:45:13 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 45n9tx1NCrzkYjv; Sun, 14 Jul 2019 21:45:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1563165913; bh=MgMDT5FZxHILjeJdZI02Tpv0xsDsPhiVGZ/iHET+ohM=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=fOHqmIeMXb6Igg3oWloKHlm/qB4DlSruBBxABIvhhqxNDmEDtcuG2Wwd+uNcQStue KLO9x7b+kdNom82rLjGc8wNEiHER1arUv7geZ7k68hMCLM41vpOinkVWCqXRJWSjlR fSoUHBcUtiDevD45wmjQytVDAxJhp3Bz1uu53O2E=
X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net
Received: from [172.20.7.244] (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 maila2.tigertech.net (Postfix) with ESMTPSA id 45n9tv4Hf9zkXWj; Sun, 14 Jul 2019 21:45:11 -0700 (PDT)
To: Michael Richardson <mcr+ietf@sandelman.ca>, Eliot Lear <lear@cisco.com>
Cc: draft-ietf-anima-bootstrapping-keyinfra@ietf.org, Adam Roach <adam@nostrum.com>, anima-chairs@ietf.org, The IESG <iesg@ietf.org>, Toerless Eckert <tte+ietf@cs.fau.de>, anima@ietf.org
References: <156282703648.15280.17739830959261983790.idtracker@ietfa.amsl.com> <17580.1562874933@localhost> <ACEB4033-707F-47AF-B58A-5227B444BEAB@cisco.com> <E2DA8D30-805E-478D-925D-534C04A0727F@cisco.com> <8869.1563140002@dooku.sandelman.ca>
From: "Joel M. Halpern" <jmh@joelhalpern.com>
Message-ID: <cedc515e-22ab-94a9-e6ef-c55b345687ba@joelhalpern.com>
Date: Mon, 15 Jul 2019 00:45:08 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
MIME-Version: 1.0
In-Reply-To: <8869.1563140002@dooku.sandelman.ca>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/YcQdxN5hDRMoWzdKoRwJ368nXQg>
Subject: Re: [Anima] Adam Roach's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)
X-BeenThere: anima@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Autonomic Networking Integrated Model and Approach <anima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/anima>, <mailto:anima-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/anima/>
List-Post: <mailto:anima@ietf.org>
List-Help: <mailto:anima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/anima>, <mailto:anima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 15 Jul 2019 04:45:15 -0000

I presume I am missing something basic.
I have tried to follow this discussion, as it seems to be about a 
critical aspect of whether the BRSKI work is acceptable.

I have assumed that what we needed is the ability for a buyer, who has 
physical possession of the device, and possibly some simple (non 
cryptographic) credentials provided by the seller to force the device to 
reset what it thinks it is part of, and to emit in some accessible form 
the information the buyer needs to be able to make this device part of 
his network, using his authentication servers, etc.

Have I got the wrong end of the stick?
Joel

On 7/14/2019 5:33 PM, Michael Richardson wrote:
> 
> Eliot Lear <lear@cisco.com> wrote:
>      > Whether such a voucher would be pinned is something we do not have to
>      > specify, with the risks of it not being pinned being born by the owner.
> 
> I beg to differ!
> I think that the security properties are vastly different.
> It's why we decided when creating RFC8366 not to do bearer tokens.
> We simply didn't think we were competent enough to specify it tightly enough
> to not become a security disaster.
> 
> An unpinned voucher is some kind of bearer token, and if disclosed has
> significant operational risk.  As such, keeping it around/online is a serious
> issue.
> 
> A voucher pinned to the public part of a keypair whose private key is
> kept offline (to be turned over to a new owner) is different because there
> are potentially far fewer things to keep private.  Worse case, it's perhaps
> the same, I would agree.
> 
> The bigger problem is that I don't see a way to define such an artifact in a
> timely fashion, nor do I know which WG we'd do it in.
> 
> 
> _______________________________________________
> Anima mailing list
> Anima@ietf.org
> https://www.ietf.org/mailman/listinfo/anima
>