Re: Kathleen Moriarty's Discuss on draft-ietf-rtgwg-yang-key-chain-20: (with DISCUSS and COMMENT)

[Alia Atlas <[e-mail]>]

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 <[e-mail]> 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
>
>