Hi Alexey,
On Thu, Apr 27, 2017 at 5:39 AM, Alexey Melnikov <[email protected]>
wrote:
> Hi Alia,
>
> On Thu, Apr 27, 2017, at 05:02 AM, Alia Atlas 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.
>
> I wish the document said that.
>
>
> 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.
>
> As a side note, the document is confusing, because it doesn't explain when
> and why hexstring version is to be used.
> It also has some text suggesting that hexstring might be used to provide
> more entropy, which doesn't necessarily mean that the keystring contains
> encrypted key.
>
Right - those are other reasons that someone might use a hex-string for
the key.
>
> "+--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.
>
>
> This helps. The change in -21 to remove aes-key-wrap means that now it is
> not possible to tell whether the keystring is the passphrase/key itself or
> whether it contains encrypted key.
>
More - it doesn't tell the sender of the YANG model for providing current
state to encrypt the keys or the receiver that they are encrypted.
I do think it is worth working through the issues so that the aes-key-wrap
goes back in the document - but I need to talk to the authors and the WG.
This part of the draft is more aspirational which is why I think it is
being negotiable.
Regards,
Alia
> 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
