Re: [netconf] ietf crypto types - permanently hidden

Martin Bjorklund <mbj@tail-f.com> Fri, 03 May 2019 11:37 UTC

Return-Path: <mbj@tail-f.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 DD42B1200B7 for <netconf@ietfa.amsl.com>; Fri, 3 May 2019 04:37:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 FlyE-Q2oSmjX for <netconf@ietfa.amsl.com>; Fri, 3 May 2019 04:37:45 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id D590512004A for <netconf@ietf.org>; Fri, 3 May 2019 04:37:44 -0700 (PDT)
Received: from localhost (h-4-215.A165.priv.bahnhof.se [158.174.4.215]) by mail.tail-f.com (Postfix) with ESMTPSA id 57CEA1AE0389; Fri, 3 May 2019 13:37:43 +0200 (CEST)
Date: Fri, 03 May 2019 13:37:43 +0200 (CEST)
Message-Id: <20190503.133743.1149689382943153005.mbj@tail-f.com>
To: rwilton@cisco.com
Cc: j.schoenwaelder@jacobs-university.de, netconf@ietf.org
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <3208a877354745fa85188b81a3d8aa24@XCH-RCD-007.cisco.com>
References: <e30aa60f31ba40e8abc9cfaeffad7802@XCH-RCD-007.cisco.com> <20190503.084757.791827158808672980.mbj@tail-f.com> <3208a877354745fa85188b81a3d8aa24@XCH-RCD-007.cisco.com>
X-Mailer: Mew version 6.7 on Emacs 25.2 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=utf-8
Content-Transfer-Encoding: base64
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/W3zFjNc7QcuYOOuJOtuRrhTEB6Q>
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 11:37:48 -0000

"Rob Wilton (rwilton)" <rwilton@cisco.com>; wrote:
> 
> 
> > -----Original Message-----
> > From: Martin Bjorklund <mbj@tail-f.com>;
> > Sent: 03 May 2019 07:48
> > To: Rob Wilton (rwilton) <rwilton@cisco.com>;
> > Cc: j.schoenwaelder@jacobs-university.de; netconf@ietf.org
> > Subject: Re: [netconf] ietf crypto types - permanently hidden
> > 
> > "Rob Wilton (rwilton)" <rwilton@cisco.com>; wrote:
> > > Hi Martin,
> > >
> > > > -----Original Message-----
> > > > From: netconf <netconf-bounces@ietf.org>; On Behalf Of Martin
> > > > Bjorklund
> > > > Sent: 01 May 2019 22:06
> > > > To: j.schoenwaelder@jacobs-university.de
> > > > Cc: netconf@ietf.org
> > > > Subject: Re: [netconf] ietf crypto types - permanently hidden
> > > >
> > > > Hi,
> > > >
> > > > Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>; wrote:
> > > > > On Tue, Apr 30, 2019 at 02:49:30PM +0200, Martin Bjorklund wrote:
> > > > > > Kent Watsen <kent+ietf@watsen.net>; wrote:
> > > > > > >
> > > > > > > Correct, as I didn’t think there was consensus yet.  Perhaps
> > > > > > > there is rough-consensus, and it may be that the only way to
> > > > > > > gauge that is to try and see how much push back there is.
> > > > > > >
> > > > > > > Okay, so how about this, based on this thread, there appears
> > > > > > > to be support to add a flag to control if a key should be
> > > > > > > “permanently hidden” or not, in which case configuration is
> > > > > > > created.
> > > > > >
> > > > > > I (still) object to this.  Actions shouldn't create config.  We
> > > > > > already have generic protcol operations to do this.  We go from
> > > > > > a document-oriented configuration model towards a
> > > > > > command-oriented model.  Not good.  In RESTCONF, the generic
> > > > > > methods support things like ETags, which I suspect you don't want to
> > replicate in this
> > > > > > action?   Will the action support all error-options of edit-config,
> > > > > > like rollback-on-error?
> > > > > >
> > > > >
> > > > > Martin,
> > > > >
> > > > > do you have any proposal how to support the requirement to
> > > > > generate a key on the device that is workable with a
> > > > > document-oriented configuration model? Do you propose that the
> > > > > action/rpc returns the public key information as result data that
> > > > > then needs to be written back to the server and somehow matched to
> > > > > the key that is cached on the device? Perhaps you have other ideas I
> > > > > can't
> > think of?
> > > > >
> > > > > I think I would be happy to not have this special hack but then we
> > > > > need a workable alternative. Key generation on devices is
> > > > > something that is being used - and may be even more used in the
> > > > > future the more we get special hardware support for storing keys.
> > > >
> > > > So the current draft supports two use cases:
> > > >
> > > >   1.  The client configures the private and public keys explicitly
> > > >       (simple case).  Both keys are availible in the config and
> > > >       operaional state.
> > > >
> > > >   2.  The client asks the device to generate a "hidden" key which may
> > > >       be a key in special TPM hardware.
> > > >
> > > > For 2, the client configures the name of the key (in <running>).
> > > > Then the client invokes the action (in <operational>).  The device
> > > > generates a new key pair (perhaps in tpm-hw).  In <operational>, the
> > > > public key is now visible and the private key has the special enum
> > > > "permanently-hidden".
> > >
> > > Why is a separate action required to create the keys?
> > >
> > > Why is the configuration to generate a hidden key not sufficient for
> > > the device to automatically allocate a key in the TPM module?
> > 
> > This is a very good question.  Why don't we have actions for
> > "create-interface',
> > "create-user" or "create-acl"?  In all these cases we have config that
> > a device
> > internally parses and translates to some internal procedure (perhaps
> > ifconfig,
> > adduser, iptables etc).
> 
> For me, the ideal goal is that the configuration is intent based.

Absolutely.  These were rhetorical questions.

> I.e. rather than telling the device what sequence of steps it should
> perform, it is telling the device what state the device should be
> trying to get into.
> 
> So for an interface, the intent of the interface configuration is "I
> want interface XXX to exist on the device, be enabled, have this IPv4
> address configured on it".  As a client, I don't care what internal
> steps the device needs to take to reach this state, if it gets to this
> desired state.  Similarly, if something transiently goes wrong on the
> device, then it should always try to recover towards the desired state
> expressed in the intended configuration.
> 
> I think that users is a slightly orthogonal issue.  I think that the
> external primary manageability key for users should be unique
> usernames.  Certainly, whenever I log into any machine it is my
> username that I use to identify myself.  When I look folks up in the
> directory I do it via their name, not their userid.  In some cases, it
> might be desirable to use the same userid across multiple machines.
> This can be achieved by having extra optional configuration to express
> this.  Otherwise, I think that userids should primarily be treated as
> internal user identifiers that need to persisted along with any files
> associated with the user.
> 
> > 
> > In a way, this case is different b/c the client needs control of
> > *when* the key is generated.  We cannot copy & paste some config to
> > *another
> > device and expect it to work exactly the same.  OTOH that probably is
> > true for
> > other things as well; if a user has been created in the config there
> > might be files
> > owned by that user stored in the home directory.
> > 
> > Also, we might need the option to re-generate the key (even though the
> > current
> > version doesn't support this).  But *this* could be done w/ an action
> > (if we need
> > to support it).
> 
> Exactly.  Using an action to regenerate an internally managed key is
> fine.  This is equivalent to an action to reboot a linecard or clear
> some statistics.  This hasn't changed the intent of what the desired
> state the system should be in.
> 
> The alternative to the action would be to remove the config, wait
> until the device has confirmed that the key is removed (in
> operational), and then configure it again.

Not very nice, since you may have leafrefs to the keys that would have
to be removed as well, and so on.

> > What did I miss; what makes this case special so that it can't be
> > handled like
> > other config?
> 
> For me, I think that the special cases are:
>  (i) The ability to force a key to be recreated (i.e. the action
>  described above)

Ok.

>  (ii) The ability to program a client defined key pair in a private way
>  that is not visible in the configuration.  Have we considered a
>  solution that puts these into the configuration but has them encrypted
>  with a device specific public/private key pair.

I don't think so.  I'm not sure this itself solves the problem
though.  FWIW, we have tailf-specific types that work like this.  They
are similar to iana-crypt-hash in syntax and semantics, but they use
encryption rather than hashing.


/martin