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)" <a...@cisco.com> wrote:
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" <kwat...@juniper.net> 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"
><netmod-boun...@ietf.org on behalf of
>j.schoenwael...@jacobs-university.de> wrote:
>
>OK. I misread your statement. Sorry for the noise.
>
>/js
>
>On Thu, Dec 01, 2016 at 01:35:15PM +0000, Acee Lindem (acee) wrote:
>>
>>
>> On 12/1/16, 3:20 AM, "Juergen Schoenwaelder"
>> <j.schoenwael...@jacobs-university.de> wrote:
>>
>> >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.
>>
>> 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
>>
>>
>>
>>
>>
>> >
>> >/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/>
>>
>
>--
>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/>
>
>_______________________________________________
>netmod mailing list
>netmod@ietf.org
>https://www.ietf.org/mailman/listinfo/netmod
>
>
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
