Re: [netconf] ietf crypto types - permanently hidden

tom petch <ietfc@btconnect.com> Sat, 04 May 2019 11:55 UTC

Return-Path: <ietfc@btconnect.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 DC1E6120044 for <netconf@ietfa.amsl.com>; Sat, 4 May 2019 04:55:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.248
X-Spam-Level:
X-Spam-Status: No, score=0.248 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RATWARE_MS_HASH=2.148, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.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 ERzBJQco4y_r for <netconf@ietfa.amsl.com>; Sat, 4 May 2019 04:55:29 -0700 (PDT)
Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70139.outbound.protection.outlook.com [40.107.7.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA92F120026 for <netconf@ietf.org>; Sat, 4 May 2019 04:55:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=dMAs39RJJswQsVJcXC7TwDpPHHRynrGQckG7g8hw28I=; b=T5QEWVxE5KsrLQrlFWsXI+sWkr1ezHWHfh6FwTCSftx0FfG4ziX2U37Usz3k9ZWb32/CMVTIR+zosbx6fqZ4ZoDRmlCkYMRgdQkeO6KT5t6CoV+kMcGj3iQlaPC5Hyvpmp+ZRZrd6ZwVohpqClM84UOj+T0+E44E6boR3aRRX00=
Received: from VI1PR07MB3118.eurprd07.prod.outlook.com (10.175.242.156) by VI1PR07MB4160.eurprd07.prod.outlook.com (20.176.6.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1878.13; Sat, 4 May 2019 11:55:25 +0000
Received: from VI1PR07MB3118.eurprd07.prod.outlook.com ([fe80::41a4:68a9:d620:d42b]) by VI1PR07MB3118.eurprd07.prod.outlook.com ([fe80::41a4:68a9:d620:d42b%3]) with mapi id 15.20.1878.004; Sat, 4 May 2019 11:55:25 +0000
From: tom petch <ietfc@btconnect.com>
To: "Rob Wilton (rwilton)" <rwilton@cisco.com>, Martin Bjorklund <mbj@tail-f.com>
CC: "netconf@ietf.org" <netconf@ietf.org>
Thread-Topic: [netconf] ietf crypto types - permanently hidden
Thread-Index: AQHVAZ25vWzSND4r/0+wKWIH0SB1HQ==
Date: Sat, 4 May 2019 11:55:25 +0000
Message-ID: <01ea01d5026f$c5196960$4001a8c0@gateway.2wire.net>
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> <435aee7585f1425c9ed1c7a07c216dd0@XCH-RCD-007.cisco.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-clientproxiedby: LO2P265CA0277.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:a1::25) To VI1PR07MB3118.eurprd07.prod.outlook.com (2603:10a6:802:20::28)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com;
x-ms-exchange-messagesentrepresentingtype: 1
x-mailer: Microsoft Outlook Express 6.00.2800.1106
x-originating-ip: [86.139.215.234]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 20559873-cb95-4ab6-5861-08d6d08764f2
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:VI1PR07MB4160;
x-ms-traffictypediagnostic: VI1PR07MB4160:
x-ms-exchange-purlcount: 1
x-microsoft-antispam-prvs: <VI1PR07MB4160CC4E7C6A7A832FC3C3A4A0360@VI1PR07MB4160.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0027ED21E7
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(136003)(39860400002)(396003)(346002)(376002)(13464003)(199004)(189003)(71200400001)(71190400001)(14496001)(486006)(68736007)(66066001)(62236002)(44716002)(446003)(99286004)(6306002)(86152003)(61296003)(81686011)(6246003)(4720700003)(53936002)(76176011)(316002)(81816011)(110136005)(52116002)(6512007)(9686003)(66446008)(66946007)(73956011)(66556008)(64756008)(66476007)(84392002)(6116002)(3846002)(229853002)(25786009)(2906002)(4326008)(1556002)(44736005)(6436002)(305945005)(6486002)(476003)(8936002)(8676002)(7736002)(81156014)(50226002)(81166006)(186003)(26005)(6506007)(102836004)(53546011)(5024004)(14444005)(256004)(45080400002)(478600001)(14454004)(386003)(966005)(86362001)(5660300002)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR07MB4160; H:VI1PR07MB3118.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:0; MX:1;
received-spf: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: OavfRBhJOm6yhKTYBdCEvQzAW0a18ucjfPgQ+HvyLofych38U+yE/AYTAw69ZB8Ti38tNHUwgAM3pse0Gsrc4L+O9ltxvBjPx/JaNcH+skkG9DUl2kn1BYC5A2YqjBAVZWAHw538HYhSlcrgSOzAFrlPqd1v9G+Fkj1JvjPkzP2y+p3mZaCcT7TVx13u4/J1oDpnwRCO/nhxgsiz7ZFmwVLqrP+cgJHyo4ST8T9cv/bJlv/30/wwlZRaIdlsHdnfm1mzH5xnXNVrXDebHKPbVohE2L94JyTUuMn8V9mB06ur+cP9wzKKTCgbC3f5XK2ICbW5uGGr8kC9IptaY42p5FYvP2ttKijLyG7tmmhbycwPc/oEOHSWHvPY86jNoVdUcXRXBvvgWUIh40XP/gUgIkdMVCGflaui8qDy9E2g828=
Content-Type: text/plain; charset="utf-8"
Content-ID: <51191CDEB6D55A48BE7331CF8460CCCC@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 20559873-cb95-4ab6-5861-08d6d08764f2
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 May 2019 11:55:25.7886 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: cf8853ed-96e5-465b-9185-806bfe185e30
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB4160
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/L2-x3DhlER1CSt-Rk0B4gAYahR0>
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: Sat, 04 May 2019 11:55:32 -0000

----- Original Message -----
From: "Rob Wilton (rwilton)" <rwilton@cisco.com>;
To: "tom petch" <ietfc@btconnect.com>;; "Martin Bjorklund"
<mbj@tail-f.com>;
Cc: <netconf@ietf.org>;
Sent: Friday, May 03, 2019 2:46 PM

> > -----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? ūüėČ

Rob

I am wanting an action, generate key pair, that I can invoke, as opposed
to e.g. install hidden key.

The scenario I describe is an operational one, the user has a
configured, working device but the network it is now going to be used on
requires that a certificate be generated, which, yes, comes under the
general heading of OAM but is to me a different kind of configuration
compared to the initial configuration or updates driven by other
changes.

And I did comment earlier that I find the references to hidden and to
generate hidden misleading.  What I see generated is always a key pair,
not one half of a key pair. I do find the terminology mutating in a way
that seems unclear to me, something I may comment on once the
functionality has been agreed.

Tom Petch
>
> 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
> > > > >
> > >
> > >
>
>