Re: [netconf] updates to client/server drafts

Andy Bierman <andy@yumaworks.com> Sat, 15 June 2019 15:46 UTC

Return-Path: <andy@yumaworks.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 4892612003F for <netconf@ietfa.amsl.com>; Sat, 15 Jun 2019 08:46:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.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 P5-rGg-2yfuu for <netconf@ietfa.amsl.com>; Sat, 15 Jun 2019 08:46:15 -0700 (PDT)
Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com [IPv6:2a00:1450:4864:20::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDF9D12000F for <netconf@ietf.org>; Sat, 15 Jun 2019 08:46:14 -0700 (PDT)
Received: by mail-lj1-x22b.google.com with SMTP id i21so5312242ljj.3 for <netconf@ietf.org>; Sat, 15 Jun 2019 08:46:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5tIyNQhIBfpu9YwxTE1jXvEzo549wM+yNLjMUxDrArM=; b=dcMLqgn1q9K82UO7f/6bZJ1Qqr+5RKD5P1uy4BH2WvX57/xb64/ru6Ga4oY/6X7hyF mi7TebWTIDItgLRWWeOudHoTWasvg+v11ibGUpBqa3l+r0dyAbD6p8Pz2CufLxE18HL5 FrCo2xBASl2G11OoXog4vI2IG5skUCME6BKhfwpsDlyXdutCJ5dh24UKnyIzn/GHOPv4 o4HtKz8eFcR87yoyEdAnjUbwVIjFGmHt1MraO/Ta+i90Yz7UowCy0+6HJTz0P5BHw/bl 2nYHbJcM7ORGK3aaaWbyzeGhdcWsQjdR/bsATs/TnWVEFOKetdQXokwF7t0yn5m+Y79U lQoQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=5tIyNQhIBfpu9YwxTE1jXvEzo549wM+yNLjMUxDrArM=; b=piwpChyl44IB0UtarihgJ6Y48QVHhFqmelCATMTzr+hz4qPKr1khXOxCUcQ8OJwKF2 ugwzJEcSaec8QN+8DxNRjzlJVvK4IkL9LCHElVL+ncLagpyVBcFXelPB/p26aA7RmzJ+ xxsp3XgkBbvZFamCMU2xbmhY13fIdTHKgIBWPv8o2oVd67+6zndq88oWInZ7EtshUFGi nqRKa3jKHRqwVEDVA9+8Pp7zXXNa6bVVulU+NnPYLvZOr+4XYV8+AX7L0n8rDT6pxyI8 36QrefcuNNyYr4gXCbOyvNqVbhx7cs5oddUCn2C5VkVy/f0KjcuL1/mgcPtpxc9hJy5V ihEw==
X-Gm-Message-State: APjAAAVuZyhK4YEoQRVZZwAQ8t069el9+CkrhvsmmWYV/pXkoAOJ082J /WOzDZhZ/BhCEVcgBdSi7ABHUrVEqn/4cga5rfhSOQ==
X-Google-Smtp-Source: APXvYqx2pC7GPvqnRfAYIphE64J+cEYgZ/yYtHGDE+u1eYTOm11ekdxMOS902ABGP2PdPWaEb3AszfP+7AI4ibn6ayc=
X-Received: by 2002:a2e:934e:: with SMTP id m14mr26900332ljh.116.1560613572756; Sat, 15 Jun 2019 08:46:12 -0700 (PDT)
MIME-Version: 1.0
References: <20190613.130024.515576855897220606.mbj@tail-f.com> <20190613111023.ngllkl22zj2vsowp@anna.jacobs.jacobs-university.de> <0100016b5158eba2-6c8348a2-aacc-48c6-adf9-aab39b0ef3a9-000000@email.amazonses.com> <20190613.174326.268927196019178879.mbj@tail-f.com> <BYAPR11MB263110FD55EB83BF76A3E9AFB5EE0@BYAPR11MB2631.namprd11.prod.outlook.com>
In-Reply-To: <BYAPR11MB263110FD55EB83BF76A3E9AFB5EE0@BYAPR11MB2631.namprd11.prod.outlook.com>
From: Andy Bierman <andy@yumaworks.com>
Date: Sat, 15 Jun 2019 08:46:01 -0700
Message-ID: <CABCOCHQgT=L3-e7GR05uG5UbuxHQ3W8GYYMpSEe7StidX9YR7A@mail.gmail.com>
To: "Rob Wilton (rwilton)" <rwilton@cisco.com>
Cc: Martin Bjorklund <mbj@tail-f.com>, "kent+ietf@watsen.net" <kent+ietf@watsen.net>, "netconf@ietf.org" <netconf@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000a2e153058b5ea939"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/xrSzIRuX83i30H284t8ca8H-znw>
Subject: Re: [netconf] updates to client/server drafts
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, 15 Jun 2019 15:46:19 -0000

On Fri, Jun 14, 2019 at 10:30 AM Rob Wilton (rwilton) <rwilton@cisco.com>
wrote:

> Hi Martin, Kent,
>
> > -----Original Message-----
> > From: netconf <netconf-bounces@ietf.org> On Behalf Of Martin Bjorklund
> > Sent: 13 June 2019 16:43
> > To: kent+ietf@watsen.net
> > Cc: netconf@ietf.org
> > Subject: Re: [netconf] updates to client/server drafts
> >
> > Kent Watsen <kent+ietf@watsen.net> wrote:
> > >
> > > >>> I am strictly against hiding actions by encoding 'verbs' in an
> > > >>> ad-hoc data format. I rather not support creation of keys on the
> > device.
> > > >>
> > > >> Remember we had this cases:
> > > >>
> > > >> 1.  upload of keys
> > > >> 2a. generation of keys on the box that will go into hardware
> > protected
> > > >>    storage (and never be accessible) 2b. generation of keys on the
> > > >> box that will be stored on disk
> > > >>    (and never be accessible over the mgmt interface) 3.  generation
> > > >> of keys on the box that become (protected) configuration
> > >
> > > This list is missing cases #1 and #3 described here:
> > > https://mailarchive.ietf.org/arch/msg/netconf/eRDvDhOHikEq4fRJJGj8dD7u
> > > Icc
> > >
> > <
> https://mailarchive.ietf.org/arch/msg/netconf/eRDvDhOHikEq4fRJJGj8dD7uIcc
> > >.
> >
> > #1 (pre-existing key in hw) is orthogonal to the pain points we have
> here;
> > it should be possible to handle this case.
> >
> > #3 (upload of hidden key) should also be straight forward with an action.
> >
> >
> > > Also, we currently make no distinction between (2a) and (2b) - hidden
> > > is hidden, however it's implemented.
> >
> > I know, but the discussion seems to imply that this would be useful and
> it
> > seems trivial to support.
> >
> >
> > > >> I think the previous version of the draft (with YANG actions)
> > > >> handles
> > > >> 1 and 2 (a and b with trivial updates).
> > > >>
> > > >> It is only (3) that we don't have a solution for that everybody
> > > >> accepts.
> > > >>
> > > >> So perhaps we should solve 1 and 2a and 2b, and publish that, and
> > > >> leave 3 for the future?
> > > >
> > > > This may be a way to move forward. In 2a and 2b, will there be a way
> > > > to remove a generated key via the mgmt interface or do I have to
> > > > take a bigger hammer to accomplish this?
> > >
> > > I object to reverting to the approach that doesn't have the key's
> > > 3-tuple (algorithm, public key, private key) marked as mandatory true,
> > > our doing that before was unhelpful.
> >
> > I need to go back and re-read (again, I just read all threads on this
> > issue) some mails to understand what this means.
> >
> >
> > > I was hoping that the "verbs"
> > > approach could leap over the impasse but, if Juergen is strictly
> > > against it, then we should go back to the approach described here:
> > > https://mailarchive.ietf.org/arch/msg/netconf/P-xcpHqUNq3LfX5meOCpNQMJ
> > > usY
> > > <https://mailarchive.ietf.org/arch/msg/netconf/P-xcpHqUNq3LfX5meOCpNQM
> > > JusY>, for which a draft was never published.
> > >
> > > In the previous link, search for "Now let's discuss what this action
> > > does" and note the two options: (1) is more user-friendly, but one
> > > that Martin appears to be strictly against
> >
> > Yes, and Andy and Rob (at least).  And I do not agree that it is user
> > friendly at all!
>
> I don't think that I'm necessarily against having an action (or RPC) that
> generates a pair of keys and writes them to configuration as a special type
> of configuration update.  But I would very much regard this as a special
> case that is designed as a combined action/RPC solely to make life easier
> for clients rather than the defacto approach.  I.e., I would like there to
> be an equivalent mechanism that works, is just as secure and complete,
> using regular NETCONF <edit-config> config operations and normal
> semantics.  Then the question becomes: If we can do this using regular
> NETCONF semantics, do we still need a separate "easy to use" action/RPC as
> well?
>
>
>

IMO it is fair to ask how many servers support actions that change
configuration today?
If several vendors say "this is great! we use it all the time! no problems
at all!" then
it is probably appropriate for standardization. Otherwise, not so much.
(I don't think any vendors use this design pattern now)



> >
> > > and so perhaps (2) is all
> > > we can agree on, and yes, there would need to be a third (not
> > > mentioned) action to delete the key from <operational> (presumably
> > > after having deleted the same from <running>).  Yes, it is less
> > > friendly, if you want more friendly, then let's do (1).  I'll update
> > > the draft shortly based on the less-friendly approach (2).
> >
> > I don't think (2) is the right solution either.  I think the previous
> > version of the draft was very close to a workable solution.
> >
> > > That said, I'm also okay with giving up (for now) trying to enable a
> > > client request the server to generate a key (hidden or not) or request
> > > the server to install a hidden key [note: these are #2 and #3 in my
> > > first link above].
> >
> > I don't it is necessary to give up this.
> >
> > IMO the only problematic use case is "let the device generate a key that
> > then becomes part of the config".  If we avoid that I think we can handle
> > the other cases.
>
> I think that Juergen's idea of "store the name of the key in the <running>
> configuration, but not necessarily the value" is along the right lines.
>  - If the client is willing to write the key into the configuration,
> perhaps obfuscated, or encrypted, then that is fine.
>  - If the client wants the server to allocate the keys that also works.
>
> Taking Kent's tree diagram from the 3rd of May, perhaps this could be
> modified from:
>
>      +--rw keystore
>         +--rw asymmetric-keys
>            +--rw asymmetric-key* [name]
>               +--rw name
>               +--rw algorithm?                             <--- optional?
>               +--rw public-key?                            <--- optional?
>               +--rw private-key?           union           <--- optional?
>  (note union)
>               +---x generate-hidden-key
>               +---x install-hidden-key
>               +---x generate-certificate-signing-request
>               +--rw certificates
>                  +--rw certificate* [name]
>
> to something like this:
>
>      +--rw keystore
>         +--rw asymmetric-keys
>            +--rw asymmetric-key* [name]
>               +--rw name
>               +--rw type!                                  <-- New
> mandatory field
>               +--rw algorithm?                             <--- optional
>               +--rw public-key?                            <--- optional
>               +--rw private-key?           union           <--- optional
>               +---x regenerate-hidden-key
>               +---x install-hidden-key
>               +---x generate-certificate-signing-request
>               +--rw certificates
>                  +--rw certificate* [name]
>
> Where the new "type" enum field could have 4 options such as:
>  - plain-text <= configured algo, public/private keys in raw format (not
> secure, transferable)
>  - obscured   <= as above, but obscured with a known reversible mechanism
> (not secure, transferable)
>  - encrypted  <= as above, but encrypted using server's public key
> (secure, not transferable)
>  - server-allocated <= only name and optionally algorithm in running
> config, the server allocates the key when applying the configuration,
> public key is available in operational, private key is never reported.  Key
> pair is persisted outside of YANG configuration.
>
> YANG "must" statements could be added to "algorithm", "public-key" and
> "private-key", to enforce that these are always provided if type is
> (plain-text, obscured, encrypted).
>
> The "regenerate-hidden-key" action would allow a server-allocated hidden
> key to be regenerated if required.  If user configuration caused the key to
> be created in the first place, then the key would also be deleted if the
> key list entry is deleted from configuration.
>
> A server could also automatically create its own key, without any user
> intervention.  The server chooses the key name, and the key would be of
> type "server-allocated" but it would only exist in operational
> (origin=system).  If the key needs to be referenced in configuration then
> the client would need to configure (asymmetric-key,
> name=<server-assigned-key-name>, type=server-allocated) into the
> configuration.  Subsequently removing the configuration wouldn't delete the
> key (because it is system created, and always exists), but
> regenerate-hidden-key should work to force the key to be regenerated if
> required.  The server persists the key outside of YANG configuration.
>
> The "install-hidden-key" action would allow a client to replace any
> server-allocated hidden key.
>
> Finally, if we are concerned about ease of use, then I would OK with a RPC
> being defined that performs an edit-config request to just add a named
> asymmetric-key of type server-allocated.  The RPC could also return the
> public key that has been generated by the server.  Note that this RPC isn't
> required, everything that can be done with the RPC can still be achieved
> through editing the configuration using edit-config, and reading the public
> key back with get-data, its only purpose to simplify a use case for
> clients, and perhaps to allow it to have different NACM permissions.
>
> Would a scheme like this work?  Or am I [still] missing something?
>


I also like Juergen's approach.



Thanks,
> Rob
>
>

Andy


>
>
> >
> >
> > > I would support this less complete solution because it still supports
> > > basic configuration (#0) and manufacturer-generated keys for, e.g.,
> > > IDevID certificates (#1), and thus a passable go-to-market solution.
> > > If folks don't like the update per the previous paragraph, then this
> > > looks like a good fallback.
> >
> >
> > /martin
> >
> > _______________________________________________
> > netconf mailing list
> > netconf@ietf.org
> > https://www.ietf.org/mailman/listinfo/netconf
>
> _______________________________________________
> netconf mailing list
> netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf
>