One last piece (sorry to top-post, but scanning the relevant security considerations piece in version -20):
With this model, any user/group can read the operational state via YANG model and that would, by default, include unencrypted keys being transmitted. If NACM is supported, then only certain users/groups would be able to access the keys. Without NACM, using the KEK ensures that even if a user/group receives the operational state of the YANG model, the keys aren't unencrypted. Thus the user/group would need to have access to the key used in KEK. Does this match up with your understanding? I think that Kathleen's Discuss is just asking for a paragraph - perhaps in 3.2 or a new 3.2.1 that describes the above and that the key-handling for KEK is out-of-bounds. Regards, Alia On Thu, Apr 27, 2017 at 12:02 AM, Alia Atlas <[email protected]> wrote: > I am just catching up on this conversation. > > First, the YANG model is primarily for information in motion - either for > configuration to the device > or to read from the device. It is much less likely to represent the data > structure and storage in the device. > I believe that this draft's context is strictly for information in motion. > > This YANG model, as with all, is intended for transport over NetConf or > RestConf, which are confidential > transports. Thus, any keys sent in the YANG model are already protected > in flight. > > However, to allow for the limited cases (as I understand it) where that > isn't viewed as sufficient protection, > the key might be sent encrypted (via KEK) so it is encrypted before being > handed to the model, the configuration > action would be with the encrypted key, and then the device would have to > know how to decrypt it, which is all > out-of-band behavior as far as the YANG model and associated protocols go. > > The gotcha - and why, as I understand it, that encrypted keys are even > mentioned is that it alters the data type > used for transmitting the key as in the snippet below. Normally the > keystring would be a string, but if encrypted, > it is a hex-string - so arbitrary bytes. > > "+--rw key-string > > | +--rw (key-string-style)? > | +--:(keystring) > | | +--rw keystring? string > | +--:(hexadecimal) {hex-key-string}? > | +--rw hexadecimal-string? yang:hex-string > " > > This draft isn't trying to describe how or whether to use KEK. It's just > making sure the YANG model is sufficient > general to transmit the key if it is previously encrypted. > > Does that make sense and help clarify? > > Regards, > Alia > > > On Wed, Apr 26, 2017 at 11:00 PM, Adam Roach <[email protected]> wrote: > >> On 4/26/17 9:34 PM, Kathleen Moriarty wrote: >> >>> The final paragraph, I believe is referring to how the key is stored - >>> either a KEK is used and it's encrypted or it's not and it's advising >>> obfuscation at a minimum. >>> >> >> That's how I read it too: it's talking about how the key is stored. If >> it's encrypted with a real crypto operation, it's going to have a KEK >> (which isn't necessarily the same KEK as is used to decrypt the information >> received from a remote node, right?); and, if it's obfuscated, it doesn't >> even necessarily have a key at all, just some kind of reversible >> transformation. >> >> Let's focus on the "obfuscation" case, because I think it's easier to >> reason about (and less likely to get conflated with other operations), and >> then we can extend that reasoning to the crypto case if we come to >> agreement. I'm making certain assumptions here which you may have a >> different read on (and, as before, this is your area, so I'd take your >> assumptions over my own) -- please correct me where I'm overstating or >> misstating things. >> >> In the obfuscation case -- and barring any advanced anti-debugger and >> anti-ICE defenses -- reverse-engineering the obfuscation technique would be >> a fairly straightforward exercise. So I think we can safely assume that any >> such obfuscation performed by popular routers will be reversible by your >> average black-hat hacker. >> >> That seems to negate most of the benefit obtained by obfuscation. >> >> At the same time, an administrator observing that the stored value is not >> the same as the actual key may make the erroneous assumption that the >> on-disk value itself is not particularly high value, and may take steps >> that make it more likely to fall into the hands of an attacker than if the >> administrator saw the literal key present in the configuration. >> >> That seems to make the obfuscation potentially harmful. >> >> Little benefit with possible harm would, to me, indicate that obfuscation >> should not be employed. >> >> >> >> Does that help? I'll defer to the authors and AD and get back to the >>> part of the thread where I'm hoping we can add the KEK back into the >>> draft. >>> >> >> I hope so too. As a process point: removing this from the document seems >> like a material change. If this went through WGLC and IETF LC with the KEK >> as part of the data model, I would think its removal would require WG >> buy-in, and running through IETF LC again. >> >> /a >> >> >
_______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
