Re: [Netconf] update to client/server drafts

Kent Watsen <kwatsen@juniper.net> Tue, 19 June 2018 21:13 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 26168130F2C for <netconf@ietfa.amsl.com>; Tue, 19 Jun 2018 14:13:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 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, 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 x8cO67rPK5Q6 for <netconf@ietfa.amsl.com>; Tue, 19 Jun 2018 14:13:29 -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 12183130E09 for <netconf@ietf.org>; Tue, 19 Jun 2018 14:13:29 -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 w5JL8UAL002709; Tue, 19 Jun 2018 14:13:28 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=PPS1017; bh=ok/zTZtr4gJKxH0fC/mFJOCPqg1NkJvSUAgrRHch//Y=; b=I/0klpOe+Mtb4aUFdxLh0LdkL8wFAVsfIy7U8uefL+u1DIURxNNlB3lXEKFhSpeEVkOk 25Zx18F8jTgR8DN3rbbKnwmVTPNp+mFUgJQF6MKEIxxyp95NgLSWdG8b8rC48YtveO3l qDyuWaA2mlpQx0RZGMA2y04qVn6ka0pMkuOdo3NFF+6USwVhFERtKYpXzPprS77vcxQy sUiOdp0VXBm9HhjOOBKGB8HO3/9mIfafpdi5Tb/N7ZdrR9gtkZYHfr2mJrSogMMbfvkM d5LF8TGqnUCYEdGKxxamHhwEUgYJK4aoLZESqOHwvtXzJr44nUp7g7KfX5ms/TWVEyEq CQ==
Received: from nam02-sn1-obe.outbound.protection.outlook.com (mail-sn1nam02lp0017.outbound.protection.outlook.com [216.32.180.17]) by mx0a-00273201.pphosted.com with ESMTP id 2jq7rj85e1-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 19 Jun 2018 14:13:28 -0700
Received: from BYAPR05MB4230.namprd05.prod.outlook.com (52.135.200.153) by BYAPR05MB4232.namprd05.prod.outlook.com (52.135.200.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.884.17; Tue, 19 Jun 2018 21:13:26 +0000
Received: from BYAPR05MB4230.namprd05.prod.outlook.com ([fe80::959d:9fbe:90e4:3cc]) by BYAPR05MB4230.namprd05.prod.outlook.com ([fe80::959d:9fbe:90e4:3cc%4]) with mapi id 15.20.0884.010; Tue, 19 Jun 2018 21:13:26 +0000
From: Kent Watsen <kwatsen@juniper.net>
To: Martin Bjorklund <mbj@tail-f.com>
CC: "netconf@ietf.org" <netconf@ietf.org>
Thread-Topic: [Netconf] update to client/server drafts
Thread-Index: AQHT/Geo6VNA3OVtn0motiIrMC2qnqRUrBwAgBM8voA=
Date: Tue, 19 Jun 2018 21:13:26 +0000
Message-ID: <8D604882-10F2-4017-9D5D-0E90554622D2@juniper.net>
References: <FEB7E46B-D28B-4C68-8B20-DB03BAB0FCC7@juniper.net> <20180607.132704.900255711945242973.mbj@tail-f.com>
In-Reply-To: <20180607.132704.900255711945242973.mbj@tail-f.com>
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; BYAPR05MB4232; 7:PaBZsfCM1YenssP1MO/0w9XGZ53+Qqly3juOB21YK9J6nD5mBhNjtWq3Ab6MMF3ZG4ivUUAc9pKhceUvxlHcmbIpladj984fQgo3i5BpQHsuhTkuy6Um6AP+xby6kf5ZB1zQwAAaEQWRek+NGZp6DLOLn9F0HIv7V+QJJnMEkwcvqg6Ww8BN6hdo7EDlKlrHXoBuvNyyZ7JmGvDjmkOSbdOLDestJDc8ssZsL1Kjy5c48W9F0novsBU1wS0IilVS
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: 1ce7e67c-47e0-464a-71c1-08d5d6297f94
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(711020)(48565401081)(2017052603328)(7153060)(7193020); SRVR:BYAPR05MB4232;
x-ms-traffictypediagnostic: BYAPR05MB4232:
x-microsoft-antispam-prvs: <BYAPR05MB42327FDE2D2BA7E31D710E44A5700@BYAPR05MB4232.namprd05.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(158342451672863)(166708455590820)(17755550239193);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(93006095)(93001095)(3231254)(944501410)(52105095)(10201501046)(3002001)(6055026)(149027)(150027)(6041310)(20161123564045)(20161123558120)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(6072148)(201708071742011)(7699016); SRVR:BYAPR05MB4232; BCL:0; PCL:0; RULEID:; SRVR:BYAPR05MB4232;
x-forefront-prvs: 07083FF734
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(39380400002)(366004)(376002)(346002)(396003)(199004)(189003)(54534003)(51444003)(25786009)(486006)(15650500001)(99286004)(7736002)(6506007)(2906002)(186003)(3660700001)(102836004)(76176011)(6116002)(2616005)(8936002)(3846002)(81156014)(446003)(81166006)(3280700002)(476003)(11346002)(33656002)(6916009)(316002)(305945005)(5660300001)(59450400001)(8676002)(83716003)(58126008)(14454004)(66066001)(6512007)(6306002)(4326008)(53936002)(82746002)(6246003)(2900100001)(106356001)(478600001)(966005)(105586002)(26005)(6486002)(36756003)(229853002)(68736007)(5250100002)(6436002)(86362001)(575784001)(97736004); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR05MB4232; H:BYAPR05MB4230.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
x-microsoft-antispam-message-info: Qn+Oa++zuQf5+F0gEUXkjNQbFCKLwCPaBciHNu14HHJdVMB21bdyarjDzZMRqonSbzYG0wMOYdY8RkfGgZBhxCwjCNOCbCv3XBD9w+S+omNn89K/DJUBcMzS+d26mAR8yDl83CQ2dW/WJs6Z0asNDpJ3Bz9KMpdRYSIeDXEK1zeytXFBL0S5JDzvKRhVkmalNkvrHxSgXqN9MbMDF9nvYY+Zhf4miPKBrKa5t3cwImU2fy438wN8Leh4gwiekigFNABw4j9DbStmsdT6fMx3JqYXEq00Yvb7p5BOH6aNEkvbdnW82AZeTw7x6N7k/xISci1+04U+cbvSVBe58bOliw==
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <40F17AF561B62740AA60CD24CBFF839C@namprd05.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: 1ce7e67c-47e0-464a-71c1-08d5d6297f94
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jun 2018 21:13:26.4010 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR05MB4232
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-06-19_10:, , 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=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1805220000 definitions=main-1806190228
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/tpmAeH9KLBWF0YglZ8CJmm4MW4o>
Subject: Re: [Netconf] update to client/server drafts
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.26
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: Tue, 19 Jun 2018 21:13:33 -0000


Hi Martin,

Thanks for diving into the questions right away!


>>  1) no regrets about trust-anchors being separate from keystore,
>>     right?
>
> Well, when the name was changed to trust-anchors, the idea was to
> remove keystore.  Now we have a config tree in keystore again, so the
> situation is a bit different.
>
> The alternative would be a single module with:
>
>     +--rw keystore
>        +--rw asymmetric-keys
>        +--rw pinned-certificates* [name]
>        +--rw pinned-host-keys* [name]
>
> or maybe:
>
>     +--rw keystore
>        +--rw asymmetric-keys
>        +--rw trust-anchors
>           +--rw pinned-certificates* [name]
>           +--rw pinned-host-keys* [name]
>
> BUT, I don't think we should overengineer this.  I don't have a strong
> opinion either way.

Balazs K and I had a non-committal exchange about this before.  Search for "I assume the trust anchors would be fully separated from this?" on this page: https://mailarchive.ietf.org/arch/msg/netconf/q3jrg1DW8xl64AfvIhxjH7em2wQ.  Did you see that exchange before?  Any additional thoughts?  




>>  2) are we happy with keystore's "local-or-keystore" groupings
>>     (not too complicated?)
>
> From a modelling pow it looks fine.  But what is the use case for the
> "local" case?  Should it have an "if-feature"?

For the use-case, search for "So my take would be that ietf-keystore should support using the same key from multiple protocols, and support separate keys for each protocol too." on this page: https://mailarchive.ietf.org/arch/msg/netconf/xYYf0NSeT9mgtJ1KH-h7SYLSmXA.  

Perhaps I jumped to a conclusion, as the keystore-mechanism can also support distinct keys per use as well but, after suggesting the local-or-external (now local-or-keystore) grouping, follow-ups from Balazs B, who conferred with Balazs L, and also Eric V, seem to suggest that they like the modularity.  

Taking a step back, I think that it's fair to say that keystore-based keys cover all use-cases (esp. the need to share a key across uses, and the need to use a system-provided key, e.g., IDevID), whereas local-keys are best for a) helping some servers avoid needing to implement the keystore mechanism (not sure if this is important, or even a good thing), and b) reinforcing that the key is definitely not being shared (not sure if this is important either).

Regarding having an "if-feature" statement for the "local" case, assuming we keep support for local keys, some thoughts:

a) Balazs and Balazs suggested the same before, I just missed it.  Search for "the cases are in features" on this page: https://mailarchive.ietf.org/arch/msg/netconf/t-QtmTs7gZoKd2Cm8tVpxDpeA2U.

b) I'm unsure about *if* a feature statement makes sense.  I hesitate because it seems that any code able to process a keystore key surely could process a local key; it is literally the same key structure, only its storage location varies.  It seems that "local" should always be possible, a server would never not implement it unless, of course, we remove the support for locally-defined keys.

c) I'm unsure about *how* to best introduce the feature statement.  Note that the "keystore-implemented" feature is defined in the keystore module, which makes perfect sense, either the keystore module is *implemented* or not; it's a global thing.  Whereas, the decision to support locally-defined keys seems like it might be more of a per-use kind of thing.  That is, rather than have an "if-defined 'not keystore-implemented'" (not the negation), each module that "uses" the grouping might instead augment-in an if-feature statement of its own. 




>>     and, if yes, should we have a similar
>>     ability for trust-anchors (e.g., a "local-or-trust-anchor"
>>     grouping like in the keystore module)?
>
> If there is a use case for non-central keys in keystore, I assume the
> same use case applies to trust anchors?

Yes, both issues can share the same fate.  And just like with keystore, centralized trust-anchors satisfy all use-cases (esp. the sharing of a large list of trust anchors), whereas locally-defined trust anchors are best for a) helping some servers avoid needing to implement the trust-anchors mechanism (this actually doesn't sound like a good thing to me), and b) reinforcing that some set of trust-anchors are not being shared (unsure if this is important).



>>  3) should some of keystore's groupings be moved to crypto-types?
>>     e.g., asymmetric-key-grouping isn't a keystore-specific
>>     concept.
>
> Seems reasonable.

I think so too, but I recall there being a little pushback before, I think mostly regarding the old top-level "notification" statement.  Now that notification statement has been made part of one of the groupings and so, if we move the groupings to ietf-crypto-types, we will again have the notification statement there.  My view is that this is okay, as being inside a grouping makes it acceptable.



>>  4) should trust-anchors include SSH host keys at all?  Maybe this
>>     draft should define two modules (x509-trust-anchors and
>>     ssh-trust-anchors)?
>
> I don't think that is necessary.  Maybe use features though.

Good idea, achieves the same with less  I just made this change to my local copy.



>>  5) should algorithm identities be moved from ssh/tls-client/server
>>     to crypto-types?
>
> Which identities do you mean?

I specifically mean the ones defined here:

  https://tools.ietf.org/html/draft-ietf-netconf-ssh-client-server-06#section-5.3

and here:

  https://tools.ietf.org/html/draft-ietf-netconf-tls-client-server-06#section-5.3

I already reached out to Gary Wu about this.  He went at it from a "what do the SSH and TLS protocols define" perspective.  But the reality is that, if the private key's structure is defined by what's currently in the keystore draft, then there needs to be some reconciliation between the alg-identities used to create the key and the alg-identities used within the protocol.




>>  6) should we add a "periodic" feature to the netconf/restconf
>>     client/server drafts, enablings the initiating peer to
>>     optionally support periodic connections? 
>
> I don't think it is necessary, but won't object to it being added.

I'd like to make a case for adding a feature for it, which is that, in my experience, periodic connections are not commonly implemented.  So, a feature would primarily be to accommodate that market trend.  That said, periodic connections are incredibly useful and, by not having a feature, we might nudge the industry into supporting them more.



> BTW, why does "persistent" have an idle timeout?  It seems to me it
> will just immediately reconnect after termininating the session due to
> idleness.

Hmmmm, I'm unsure how that got in there.  It looks like it goes back to draft-ietf-netconf-server-model-07 (note, that's the old draft, before the refactoring), and the change log says something about issue #51, which is a typo, should've been #54.  Looking at the issue is interesting: https://github.com/netconf-wg/server-model/issues/54.  AFAICT, I messed up.  I've now removed .../persistent/idle-timeout from ietf-[netconf|restconf-[client|server] (4 modules) in my local copy.
 


Kent // contributor