Re: [Netconf] Adoption poll for crypto-types and trust-anchors

Kent Watsen <kwatsen@juniper.net> Thu, 03 May 2018 16:59 UTC

Return-Path: <kwatsen@juniper.net>
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 8B2B412EA6A for <netconf@ietfa.amsl.com>; Thu, 3 May 2018 09:59:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.71
X-Spam-Level:
X-Spam-Status: No, score=-0.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, 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=juniper.net
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 PBBhPF33FY94 for <netconf@ietfa.amsl.com>; Thu, 3 May 2018 09:58:58 -0700 (PDT)
Received: from mx0b-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (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 244C912EA55 for <netconf@ietf.org>; Thu, 3 May 2018 09:58:58 -0700 (PDT)
Received: from pps.filterd (m0108157.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w43Gji4x028768; Thu, 3 May 2018 09:58:55 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : content-type : mime-version; s=PPS1017; bh=nTEYlRp+f+pWtZEbSdj81O6pdrAI9IDZjIXeiD5Fb1k=; b=ZjPOI6dNHX1eEDyTMRM9zM+Wlv0cE9p0YgxAdFfU30AnsRsDuwc0cZCSMzAVC8tF1jt6 zXTqyffEnDsjEkU311WcI/ABpfkVH4uI8Y7jJlLs0oReda9LPPmVYcwXCWmwIYWUiCo7 rz8Ofd+Y7cqvb5/6pwzJAanz9WItwcSTc77lSwlXC+zbbQd5wFJF5CKyaaBkTyKii/vZ q5x8xfw30SMxCHrh6HhMLNzXP7NBlrjZBU6rlId2mWdkAPyRop4mF+QgOjt4Acip9PSd RZF5C5qDvfqSVc2VuRWD4BAeUqX3Rh011s/Q21b9jnFCbxZ028MQsU7L5kBJOx+6bScy GA==
Received: from nam02-cy1-obe.outbound.protection.outlook.com (mail-cys01nam02lp0048.outbound.protection.outlook.com [207.46.163.48]) by mx0a-00273201.pphosted.com with ESMTP id 2hr4p9883q-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 03 May 2018 09:58:54 -0700
Received: from BYAPR05MB4230.namprd05.prod.outlook.com (52.135.200.153) by BYAPR05MB4135.namprd05.prod.outlook.com (52.135.199.156) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.735.12; Thu, 3 May 2018 16:58:52 +0000
Received: from BYAPR05MB4230.namprd05.prod.outlook.com ([fe80::44ac:d4a9:49d0:101e]) by BYAPR05MB4230.namprd05.prod.outlook.com ([fe80::44ac:d4a9:49d0:101e%13]) with mapi id 15.20.0735.006; Thu, 3 May 2018 16:58:52 +0000
From: Kent Watsen <kwatsen@juniper.net>
To: Balazs Lengyel <balazs.lengyel@ericsson.com>, Balázs Kovács <balazs.kovacs@ericsson.com>
CC: "netconf@ietf.org" <netconf@ietf.org>
Thread-Topic: [Netconf] Adoption poll for crypto-types and trust-anchors
Thread-Index: AQHT4wADJ2ALQ9zNKkqYEk+Kq3yYtA==
Date: Thu, 03 May 2018 16:58:52 +0000
Message-ID: <30074620-B60A-420D-8805-80C9EF1E1BDC@juniper.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/f.20.0.170309
x-originating-ip: [66.129.241.14]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BYAPR05MB4135; 7:xbsi1CRSQNpIgXsikqUPpfefAaPHprD5PhyrRcyTxI+lb3RGs1c99WA6JKScNbDjts5n1xfRXGGoyhDWcon6rsZRXoaEvQalO3qDbbVgzIubmmN1rm0CXM9HYXDZcDT0/TR/z7wxl3T3Y+BvdHWu/QqnwngtAudHFMIjR375c0U+9Ni+EtqHScuVLXSjPErNZfSxklTPGtbvKfCSWHodTpcqcYyRu/GTonG63ctTaFw+Z28I1RRJbHeU4oarzddy
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(48565401081)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:BYAPR05MB4135;
x-ms-traffictypediagnostic: BYAPR05MB4135:
x-microsoft-antispam-prvs: <BYAPR05MB4135CDBF5E4AD527740F2B3CA5870@BYAPR05MB4135.namprd05.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(37575265505322)(28532068793085)(158342451672863)(10436049006162)(192374486261705)(138986009662008)(788757137089)(21748063052155);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3231254)(944501410)(52105095)(10201501046)(3002001)(93006095)(93001095)(6055026)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123564045)(20161123560045)(20161123562045)(6072148)(201708071742011); SRVR:BYAPR05MB4135; BCL:0; PCL:0; RULEID:; SRVR:BYAPR05MB4135;
x-forefront-prvs: 066153096A
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(396003)(366004)(39860400002)(39380400002)(346002)(252514010)(189003)(199004)(13464003)(105586002)(14454004)(476003)(7736002)(2616005)(68736007)(66066001)(6436002)(606006)(86362001)(575784001)(97736004)(110136005)(36756003)(478600001)(8936002)(2906002)(81166006)(81156014)(6116002)(3846002)(966005)(83716003)(58126008)(25786009)(8676002)(486006)(3280700002)(316002)(54896002)(6306002)(4326008)(6512007)(5250100002)(6246003)(82746002)(3660700001)(33656002)(53936002)(561944003)(229853002)(236005)(5660300001)(106356001)(6486002)(2900100001)(6506007)(59450400001)(26005)(186003)(99286004)(102836004)(53546011); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR05MB4135; H:BYAPR05MB4230.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
x-microsoft-antispam-message-info: o8+5vGG/RE6N45Lbh674xKcOl6C+5YDylvbZdvGIKdiuccmQEga6rgyLwSC6O3vLXtApgc79dTrZszCLeKiSDw9r6efeRiRNgKVxjkb4MsdSiPbF+gi71z2qNyp9juiKgHSFcyGze6s3YDgxeZjYkSPajTrzgi1ZZBAZvIi3pgLfWrvsLxiEgCjJlZ8gLf2k
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_30074620B60A420D880580C9EF1E1BDCjunipernet_"
MIME-Version: 1.0
X-MS-Office365-Filtering-Correlation-Id: 491ca1d4-548b-4f7f-722a-08d5b117262e
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: 491ca1d4-548b-4f7f-722a-08d5b117262e
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 May 2018 16:58:52.4954 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR05MB4135
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-05-03_07:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1805030147
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/yi44lNXydxvL9xRNem4j-PcAwVw>
Subject: Re: [Netconf] Adoption poll for crypto-types and trust-anchors
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Configuration WG mailing 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: Thu, 03 May 2018 16:59:04 -0000

Hi Balazs, and Balazs,

Thanks for permission to forward this thread to the list.  All, please be sure to read the message below too.

Yes, I'm aware and familiar with various key protection strategies.  The current ietf-keystore module was modeled after MacOS's "keychain access", but it didn't define a protection layer (e.g., internally encrypted and with an access-controlled API), though one could be added later.  The keystore module is very much in-line with what you write and, for that, I think it counts as a "no/do not support" of sorts.

The reason why we're proposing to move away from the keystore module was prompted by Juergen, who questioned if any implementations of SSH or TLS use a KMS and are we creating unnecessary complexity.  As it stands, the current proposal still has SSH/TLS implementations referencing a global "trust-anchors" store, so there is still "complexity", at least in terms of there being a dependency.

The current proposal moves the storage of private keys from being in a centralized keystore (where they can be leafref-ed) to each instance of a ssh/tls client/server.  By doing so, we think that it is less complexity, though I'm not convinced, since the definition of the private key itself is the same, it's just now not leafref-ed.  Perhaps this is an incremental step, whereby we next abandon using the private-key groupings altogether for SSH-specific and TLS-specific variants.  This is very possibly needed, and I might add that no one has implemented any of these modules, AFAIAA.

Adding to this discussion, I was yesterday wondering, with the two new drafts, how a client would configure a server to use a TPM-protected private key and its associated IDevID certificate.  Note that this key and cert are "configured" by the manufacturer and thus, somehow, must be *referenced* (not stored locally) by the ssh/tls client/server modules.   I was able to find a way to reference the private key (via its public key), but I was never able to figure out how to reference the DevID cert (IDevID or LDevID?).    I was thinking that, if we don't go back to using the keystore module, we might be able to modify the private-key grouping definition to enable it to either be locally stored  or be a reference to some future TBD thing.  I haven't tried to do this yet, but being able to do this seems important, and therefore may sway my support for disbanding the keystore module/draft…

Kent // contributor


On 5/3/18, 7:08 AM, "Balazs Lengyel" <balazs.lengyel@ericsson.com<mailto:balazs.lengyel@ericsson.com>> wrote:


Hello Kent,
I would like to add that in Ericsson the preferred solution is central storage for keys. It makes administration and enforcement of good security practices simpler for the operator.
regards Balazs Lengyel
(Feel free to forward this to the list.)

-------- Forwarded Message --------
Subject:

FW: [Netconf] Adoption poll for crypto-types and trust-anchors

Date:

Thu, 3 May 2018 11:15:57 +0200

From:

Balázs Kovács <balazs.kovacs@ericsson.com><mailto:balazs.kovacs@ericsson.com>

To:

Balázs Lengyel <balazs.lengyel@ericsson.com><mailto:balazs.lengyel@ericsson.com>



Bocs, bcc lemaradt



-----Original Message-----

From: Balázs Kovács

Sent: Thursday, May 03, 2018 11:16 AM

To: Kent Watsen <kwatsen@juniper.net><mailto:kwatsen@juniper.net>

Subject: RE: [Netconf] Adoption poll for crypto-types and trust-anchors



Hi Kent,



I know you might prefer me sending this to the list, but I try this way first. I was a bit away from keystore works and did a quick check. I see you have the below poll ongoing, and I've seen the presentation you had in London.



I must say it was a bit surprising to me backing out from centralized keystore model and the statement of centralized keystore being uncommon. Storage of keys is a security sensitive and problematic area. Secret keys at rest usually need to be encrypted. The provisioning or storage of secret encryption keys, the secure storage, and rotation of keys are a complicated enough matter so that it justifies centralized key store implementations. There are centralized key management systems such as Hashicorp Vault, Azure Key Vault, Google Cloud KMS, OpenStack Barbican, etc.. that solve the above matters. These SW can be used by an implementation to outsource the key management issues, and even if it is outsourced, outsourcing from a central implementation does give benefit since the client usually also needs some client credential that is access controlled on KMS server side.



The other aspect I saw as benefit in centralized keystore was on the YANG interface side. As long as only machines are assumed to operate on these IETF modules, I assume distributed management of keys doesn't matter much, but when it starts to drive human interfaces directly then the configurations of protocols that import and use these security groupings become quite complex. Ok for this one you still have the trust anchors, but for keys the central model was dismissed, but for management aspect, I really don't see why is the difference.



Can you clarify? Have you considered KMS implementations when making this proposal of removing keystore?



Br,

Balazs



-----Original Message-----

From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Kent Watsen

Sent: Tuesday, May 01, 2018 11:57 PM

To: netconf@ietf.org<mailto:netconf@ietf.org>

Subject: Re: [Netconf] Adoption poll for crypto-types and trust-anchors





[I'll get the ball rolling, please, others chime in too]



I support the adoption of these two drafts to replace the existing keystore draft.



Regarding the "certificate-expiration" notification defined in ietf-crypto-types, I would like to discuss removing it, or moving it to be a descendent of the "certificates-grouping" grouping (also in ietf-crypto-types) and maybe also place a copy of the notification in the ietf-trust-anchors module.  That said, I don't like having several otherwise identical notifications in different namespaces, but I do like how the server can incrementally add support for expirations on a feature-by-feature basis.



Kent // contributor





===== original message =====



This is the start of a *two* week poll for adopting the following two drafts as working group documents, specifically to replace draft-ietf-netconf-keystore, which would be removed as a working group document:



  draft-kwatsen-netconf-crypto-types-00

  draft-kwatsen-netconf-trust-anchors-00



This call for adoption is the result of the Keystore draft presentation given in London.  When the various options were discussed, most preferred to move forward with these two drafts, as opposed to looking to do more factoring or extending to scope to include things not needed by our various client/server drafts.  No one expressed interest in moving forward with draft-ietf-netconf-keystore.  While we could separately confirm this result again on the list, we believe that an adoption call more efficiently achieves two goals at once.



Please send email to the list indicating "yes/support" or "no/do not support".  If indicating no, please state your reservations with the document.  If yes, please also feel free to provide comments you'd like to see addressed once the document is a WG document.



Kent (and Mahesh and Ignas)









_______________________________________________

Netconf mailing list

Netconf@ietf.org<mailto:Netconf@ietf.org>

https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netconf&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=qXS002RrOOkzqTDm70cWjg7eJeWqtpC_anWUcc9a_3I&s=1W689R8ht-U3FoffJ5uTT24SAPRtiQ9a9B3VxQxM_Wg&e=





_______________________________________________

Netconf mailing list

Netconf@ietf.org<mailto:Netconf@ietf.org>

https://www.ietf.org/mailman/listinfo/netconf<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netconf&d=DwMD-g&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=dy-Dg3ToTuGVBuY3XcOLDkV_tW3vuQDSz6i1wawzjjM&s=4zwr17et_2w1it4jlw_k1ksQ-q-v7_iTSKUI4E_yK4g&e=>

--

Balazs Lengyel                       Ericsson Hungary Ltd.

Senior Specialist

Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com<mailto:Balazs.Lengyel@ericsson.com>