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

Reply via email to