Subject: Re: [netmod] Key Strings in ietf-key-chain operational state

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 1 Dec 2016 09:20:49 +0100

On Wed, Nov 30, 2016 at 09:37:21PM +0000, Acee Lindem (acee) wrote:

> In the days of MIBs, we used to omit key strings from the data that would be returned. This was ostensibly done for security purposes.

This is not correct. In SMIv2, INDEX objects are not accessible
because the values of these objects are embedded in the instance
identifier. In other words, making INDEX objects not-accessible was a
performance optimization, forcing SNMP managers to extract the INDEX
object values out of the instance identifiers. Making INDEX objects
not accessible does _not_ hide any information.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 1 Dec 2016 13:35:15 +0000

On 12/1/16, 3:20 AM, "Juergen Schoenwaelder"
<[email-masked]> wrote:

>> In the days of MIBs, we used to omit key strings from the data that
>>would be returned. This was ostensibly done for security purposes.
>

This is a different issue. What I am referring to is never returning the
keys in a read request (get, get-next, get-many, etc). For example,
(excerpted from RFC 4750):

 ospfIfAuthKey OBJECT-TYPE
       SYNTAX       OCTET STRING (SIZE (0..256))
       MAX-ACCESS   read-create
       STATUS       current
      DESCRIPTION
          "The cleartext password used as an OSPF
          authentication key when simplePassword security
          is enabled.  This object does not access any OSPF
          cryptogaphic (e.g., MD5) authentication key under
          any circumstance.

          If the key length is shorter than 8 octets, the
          agent will left adjust and zero fill to 8 octets.

          Unauthenticated interfaces need no authentication
          key, and simple password authentication cannot use
          a key of more than 8 octets.

          Note that the use of simplePassword authentication
          is NOT recommended when there is concern regarding
          attack upon the OSPF system.  SimplePassword
          authentication is only sufficient to protect against
          accidental misconfigurations because it re-uses
          cleartext passwords [RFC1704].

          When read, ospfIfAuthKey always returns an octet
          string of length zero."
       REFERENCE
          "OSPF Version 2, Section 9 The Interface Data
          Structure"
       DEFVAL { '0000000000000000'H } -- 0.0.0.0.0.0.0.0
       ::= { ospfIfEntry 16 }

Thanks,
Acee

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 1 Dec 2016 17:28:54 +0100

OK. I misread your statement. Sorry for the noise.

/js

---

From: Kent Watsen <[email-masked]>
Date: Fri, 2 Dec 2016 20:15:26 +0000

Hi Acee,

Sorry for being late to this thread.  As Mehesh mentioned, this aspect of the keystore mode is currently open, and being tracked by github issue #2.  

It is my understanding that the working group would like to pursue a strategy that supports backup/restore operations to the greatest extent possible.  

In order to prevent unauthorized access, NACM rules can be used to mark the private key data leaf (not its parent list entry) with “nacm:default-deny-all”.

In order to support hardware protected keys, the private key data leaf can be marked as mandatory false, with the explanation that, if not returned, it might be because the key is protected by hardware.

Not stated yet, but the thinking is that the private key data leaf would be config true, to support the backup/restore case of the NC/RC client passing the private to the device  (open issue: how to direct specialized hardware to generate a new protected key).  Pertinently, for the applied/operational-state datastores, the NACM and mandatory attributes carry over, so still the key is protected from unauthorized access and still the solution supports hardware protected keys.

What do you think?

Kent

On 12/1/16, 11:28 AM, "netmod on behalf of Juergen Schoenwaelder" <[email-masked] on behalf of [email-masked]> wrote:

/js

_______________________________________________
netmod mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netmod

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Sat, 3 Dec 2016 00:45:23 +0000

Hi Kent, 
So are you suggesting the nacm:default-deny-all for key strings rather
than omitting it from the operational state?
Thanks,
Acee 

On 12/2/16, 3:15 PM, "Kent Watsen" <[email-masked]> wrote:

>Hi Acee,
>
>Sorry for being late to this thread.  As Mehesh mentioned, this aspect of
>the keystore mode is currently open, and being tracked by github issue
>#2.  
>
>It is my understanding that the working group would like to pursue a
>strategy that supports backup/restore operations to the greatest extent
>possible.  
>
>In order to prevent unauthorized access, NACM rules can be used to mark
>the private key data leaf (not its parent list entry) with
>³nacm:default-deny-all².
>
>In order to support hardware protected keys, the private key data leaf
>can be marked as mandatory false, with the explanation that, if not
>returned, it might be because the key is protected by hardware.
>
>Not stated yet, but the thinking is that the private key data leaf would
>be config true, to support the backup/restore case of the NC/RC client
>passing the private to the device  (open issue: how to direct specialized
>hardware to generate a new protected key).  Pertinently, for the
>applied/operational-state datastores, the NACM and mandatory attributes
>carry over, so still the key is protected from unauthorized access and
>still the solution supports hardware protected keys.
>
>What do you think?
>
>Kent
>  
>
>
>On 12/1/16, 11:28 AM, "netmod on behalf of Juergen Schoenwaelder"
><[email-masked] on behalf of
>[email-masked]> wrote:
>

---

From: Kent Watsen <[email-masked]>
Date: Mon, 5 Dec 2016 23:24:17 +0000

Exactly, with access-control, less privileged clients would never obtain the private key data, even when reading operational state.

I don’t think this has been discussed on list yet so, to be clear, I’m saying that NACM annotations MUST be enforced for all the new datastores in the revised datastore proposal.

K.

On 12/2/16, 7:45 PM, "Acee Lindem (acee)" <[email-masked]> wrote:

Hi Kent,

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Mon, 5 Dec 2016 23:36:29 +0000

For key-chains, we do want to allow creation of entries complete with the
key-string. Otherwise, the model would not be of much use…. How would one
code this in the YANG model? RFC 6536 is lacking of any examples.
Thanks,
Acee 

On 12/5/16, 6:24 PM, "Kent Watsen" <[email-masked]> wrote:

>
>Exactly, with access-control, less privileged clients would never obtain
>the private key data, even when reading operational state.
>
>I don’t think this has been discussed on list yet so, to be clear, I’m
>saying that NACM annotations MUST be enforced for all the new datastores
>in the revised datastore proposal.
>
>K.
>
>

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 7 Dec 2016 19:33:47 +0000

Ok - I've looked at this from a different angle and I now think we should use NACM to limit access to the strings by default. It doesn't make sense to address read access without addressing read and create access.

Thanks,
Acee

BTW, I always though the OSPF MIB decision to simply omit the string was somewhat lame. However, write wasn't a factor since most implementations didn't support MIB variable update.

From: rtgwg <[email-masked]<mailto:[email-masked]>> on behalf of Acee Lindem <[email-masked]<mailto:[email-masked]>>
Date: Friday, December 2, 2016 at 12:07 PM
To: Routing WG <[email-masked]<mailto:[email-masked]>>
Subject: FW: [netmod] Key Strings in ietf-key-chain operational state

Note that omitting the keystring data node from the operational state in ietf-key-chain is consistent with what the approach in the NETMOD ietf-keystore model.

Thanks,
Acee

From: Mahesh Jethanandani <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, November 30, 2016 at 9:36 PM
To: Acee Lindem <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [netmod] Key Strings in ietf-key-chain operational state

On Nov 30, 2016, at 2:33 PM, Acee Lindem (acee) <[email-masked]<mailto:[email-masked]>> wrote:

This is something we ran into with ietf-keystore model also. The thoughts are that key strings should never leave the device. If anything most devices have tamper proof capability (FIPS 140-2) to wipe the keys out if tampered with or exported. So exporting the string, encrypted, even with NACM would defy that.

So, what we have today would with the key strings omitted from the operational state would be consistent with the direction for the ietf-keystore model. Correct?

That is correct. Kent can correct me, but we are still trying to figure how to model it in YANG and in the datastores (<applied> and <operational-state>).

How will this be enforced when we have an applied-config datastore?

Thanks,
Acee

On Nov 30, 2016, at 1:37 PM, Acee Lindem (acee) <[email-masked]<mailto:[email-masked]>> wrote:

In the days of MIBs, we used to omit key strings from the data that would be returned. This was ostensibly done for security purposes. We did the same for the operational state returned for keystring in key-chain-entries. I'm now thinking this was a mistake. Rather, it would seem that one could use RFC 6536 rules to accomplish this at a more granular level.

Note that the model also support keystring encryption as described in RFC 5649.

Thanks,
Acee

_______________________________________________
netmod mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/netmod

Mahesh Jethanandani
[email-masked]<mailto:[email-masked]>

Mahesh Jethanandani
[email-masked]<mailto:[email-masked]>