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" <kwat...@juniper.net> 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.
>
>
>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
