Re: [netconf] ietf crypto types - permanently hidden

"Rob Wilton (rwilton)" <rwilton@cisco.com> Fri, 03 May 2019 13:46 UTC

Return-Path: <rwilton@cisco.com>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D0F212002F for <netconf@ietfa.amsl.com>; Fri, 3 May 2019 06:46:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.502
X-Spam-Level:
X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 iQlhmoQG6r4c for <netconf@ietfa.amsl.com>; Fri, 3 May 2019 06:46:45 -0700 (PDT)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F77D120100 for <netconf@ietf.org>; Fri, 3 May 2019 06:46:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5892; q=dns/txt; s=iport; t=1556891205; x=1558100805; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=7DFPHUL+1KvxHBGCRV/vx37y8obFNM48LBpT2QdrX1g=; b=LtdncqmRz4rBQRUqgFRIvcPQbw49PSyHWlVLwY8HvRtD0tFbufFc33aO wtR/msLW8llIRw0vCgr1W6OLBUFiSe5jzTIRDyTODWrejYcuKrVqnnqSf G469L4VIbZhmUjon71XYW2CgGvUImhuQdtlipaqaDYy7cBljr2mByoI20 w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AKAABvRcxc/4MNJK1lGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBUwMBAQEBCwGCEGmBBCgKhAaVJJhSgXsOAQEYC4QERgIXgW8?= =?us-ascii?q?jNgcOAQMBAQQBAQIBAm0cDIVKAQEBAwEBASEROgsMBAIBBgIRBAEBAwImAgI?= =?us-ascii?q?CJQsVCAgBAQQBDQUIE4MIgXsPD5Ikm2WBL4oygQsnAYoKgUMXgUA/hCM+gmE?= =?us-ascii?q?BAYFLgyCCWASDNYdfgj2EbJR1CQKCCZI9I5VIg26ILYsdiUwCERWBMCYDLoF?= =?us-ascii?q?WcBU7gmwJghIXg0yFFIU/QTGQH4EhAQE?=
X-IronPort-AV: E=Sophos;i="5.60,425,1549929600"; d="scan'208";a="552639476"
Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 03 May 2019 13:46:43 +0000
Received: from XCH-RCD-009.cisco.com (xch-rcd-009.cisco.com [173.37.102.19]) by alln-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id x43Dkh3g010177 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 3 May 2019 13:46:43 GMT
Received: from xch-rcd-007.cisco.com (173.37.102.17) by XCH-RCD-009.cisco.com (173.37.102.19) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 3 May 2019 08:46:42 -0500
Received: from xch-rcd-007.cisco.com ([173.37.102.17]) by XCH-RCD-007.cisco.com ([173.37.102.17]) with mapi id 15.00.1473.003; Fri, 3 May 2019 08:46:43 -0500
From: "Rob Wilton (rwilton)" <rwilton@cisco.com>
To: tom petch <ietfc@btconnect.com>, Martin Bjorklund <mbj@tail-f.com>
CC: "netconf@ietf.org" <netconf@ietf.org>
Thread-Topic: [netconf] ietf crypto types - permanently hidden
Thread-Index: AdTf8DCbvspujhISQkyURJOX9ReFpAhxAf5w
Date: Fri, 3 May 2019 13:46:42 +0000
Message-ID: <435aee7585f1425c9ed1c7a07c216dd0@XCH-RCD-007.cisco.com>
References: <20190430161223.cwqfsyyxbtnkqbl7@anna.jacobs.jacobs-university.de> <20190501.230622.158012882760210627.mbj@tail-f.com> <e30aa60f31ba40e8abc9cfaeffad7802@XCH-RCD-007.cisco.com> <20190503.084757.791827158808672980.mbj@tail-f.com> <016d01d5019d$3c85e9c0$4001a8c0@gateway.2wire.net> <1107e4a1b2cc4b1199a328bccbf1b42f@XCH-RCD-007.cisco.com> <01cb01d501a3$49229d80$4001a8c0@gateway.2wire.net>
In-Reply-To: <01cb01d501a3$49229d80$4001a8c0@gateway.2wire.net>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.63.23.60]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Outbound-SMTP-Client: 173.37.102.19, xch-rcd-009.cisco.com
X-Outbound-Node: alln-core-1.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/5pejvSa3DdOqK_WFZLRtf7E-LEY>
Subject: Re: [netconf] ietf crypto types - permanently hidden
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 03 May 2019 13:46:47 -0000

Hi Tom, 

> -----Original Message-----
> From: tom petch <ietfc@btconnect.com>;
> Sent: 03 May 2019 12:32
> To: Rob Wilton (rwilton) <rwilton@cisco.com>;; Martin Bjorklund <mbj@tail-
> f.com>
> Cc: netconf@ietf.org
> Subject: Re: [netconf] ietf crypto types - permanently hidden
> 
<snipped>
> > > >
> > > > What did I miss; what makes this case special so that it can't be
> > > > handled like other config?
> > >
> > > If I configure an interface, I am providing at least part of the
> > > information and anything that the device generates - interface name,
> MTU,
> > > privacy address - I can then see and may or may not be able to
> change.
> > >
> > > When I generate a key pair, yes I want to see the public key but I
> have no
> > > interest in the private key.  I want the device, and it is the
> device not
> > > an individual user, to be able to do things with the private key,
> notably
> > > to generate a certificate for the device; I now see organisations
> where
> > > every device that is attached to the network must have its own
> certificate
> > > regardless of what the device is, who owns it, who is logged onto it
> etc.
> > >
> > > So generate a key pair, keep the private private, use it for a
> certificate,
> > > but I will never change it, don't want to know it is, I just want it
> > > securely hidden - and it is unlikely that the notepad, smartPhone,
> laptop
> > > etc will have a TPM.
> > >
> > > This is the policy of the most security-conscious organisation I
> know, the
> > > only one whose passwords would meet the criteria laid down in RFC,
> but it
> > > has only been around for a year or so so I expect others will follow
> suit.
> >
> > This is all fine and sounds sensible to me.
> >
> > The public key can be published in <operational>.
> >
> > But why does there need to be a separate YANG action required to
> generate the public/private key pair on the device?
> 
> How else is the key pair going to come into existence?  The device is not
> shipped with one (although it is the sort of the thing that a Microsoft
> might organise if it becomes the norm).  A user (with suitable
> credentials) brings in his device, the organisation says 'generate key
> pair', and certificate, and the user is then good to go for however long
> they use the organisation's network, could be years; and yes, the public
> key, and certificate, must persist in the device across restarts but not,
> of course, if the hardware is replaced by fresh hardware - it is a device
> certificate, not a user certificate.

Sorry, I still don't get it, I'm missing something ūüėČ

list crypto-keys {
  config true;
  key "name";
  leaf "name" { type string; }
  choice key-type {
     case explicit {
        leaf private-key { type binary; }
        leaf public-key { type binary; }
     }
     case auto-generated {
        leaf auto-generated { type boolean; default false; }
        leaf public-key { type binary; config false; }
     }
  }
}

If the client configures an entry in the list with explicit keys then that is what the server uses.

However, if the client configures an entry in the list with leaf "auto-generated" set that the device generates a public/private key pair and persists them internally.  The public-key is available via the config false leaf.  The private key is kept private.  No separate YANG action is required to instantiate the keys - it happens automatically due to the configuration.  What is the obvious step that I am missing as to why this doesn't work? ūüėČ

Thanks,
Rob


> 
> Tom Petch
> 
> > Why is the configuration intent of "I want you to use a securely
> allocated public/private key pair" (which could be in the configuration)
> not sufficient?
> >
> > If the issue is that these keys need to persist over device restart,
> then I would think that the solution is for the device to securely persist
> these keys independently of the YANG configuration.
> >
> > Thanks,
> > Rob
> >
> >
> > >
> > > Tom Petch
> > >
> > > > /martin
> > > >
> > > > _______________________________________________
> > > > netconf mailing list
> > > > netconf@ietf.org
> > > > https://www.ietf.org/mailman/listinfo/netconf
> > > >
> >
> >