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 protected]> 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 protected] on behalf of >[email protected]> 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" >> <[email protected]> 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 >[email protected] >https://www.ietf.org/mailman/listinfo/netmod > > _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
