I'm not concerned about how the KEKs get distributed.
I'm concerned about how you know which one to use.
/a
On 4/26/17 10:45, Brian Weis (bew) wrote:
Distributing and maintaining keys has a higher security bar than most
configuration items, because their leakage can usually cause more harm. For
example, a leaked key from the routing key chain could allow an attacker to
substitute its own routing messages for authentic ones.
Distributing plain-text keys through a general purpose configuration protocol is not
always considered safe. When the configuration protocol is protected (e.g., TLS),
the security requirements of some users are satisfied because they are only worried
about protecting the keys on the wire. But other users with larger threat profile
(e.g., government users) often do not consider sending plain-text keys through a
protected configuration protocol to be sufficient, because they may not have enough
control over the ciphers chosen for the TLS session, or perhaps they want to protect
the keys in the configuration system before they are delivered to the TLS session.
In these cases it’s valuable to "key wrap” (encrypt) the keys in the software
that generates the keys, and unwrap them in the piece of software that is actually
installing the keys. That’s the motivation for including an optional key wrap method
in the key chain Yang data model.
Yes, using a key wrap method means there’s an extra complication with needing
to maintain a key wrap key. Users that require the use of a key wrap probably
don’t have a problem with distributing a key out of band for this. Distributing
it in-band would likely mean sending it through a different Yang data model,
which would have exactly the same problem of needing to be key wrapped so I’m
not sure it’s valuable to even specify an in-band method. If that’s a hard
requirement, then I suppose the key wrap method can be removed. But the removal
of the key wrap option is likely to restrict the users who can use the key
chain data mode.
Hope that helps,
Brian
On Apr 25, 2017, at 5:47 PM, Acee Lindem (acee) <[email protected]> wrote:
On 4/25/17, 6:44 PM, "Adam Roach" <[email protected]> wrote:
On 4/25/17 17:22, Acee Lindem (acee) wrote:
Hi Adam,
On 4/25/17, 5:27 PM, "Adam Roach" <[email protected]> wrote:
- Section 5 discusses the use of a KEK, distributed out-of-band, to
decrypt the keys stored in this format. There appears to be no
affordance
for indicating the identity of which KEK to use, which would come in
handy for the types of key rotation schemes I'm familiar with. Mostly,
I'm worried about the "try it and see if it works" approach when you
have
two valid KEKs (as during a transition), as it's not clear that you
will
be able to distinguish success from failure in all cases.
AES is an algorithm. I know there are 128, 192, and 256 bit varieties.
Do
you want me to specify than any variety may be used? I almost removed
this
out-of-band key encryption once.
This isn't about crypto-agility; it's about key rotation. This section
posits a system in which you have some KEK, distributed out-of-band.
Let's call the key we're using at this moment "Generation A." At some
point -- let's say next week -- we decide that it's time to change the
KEK to one we're going to call "Generation B." First, we need to get the
"Generation B" KEKs to everyone before the switch-over (to avoid a
period of time during which they can't decrypt the YANG-stored keys).
The issue becomes: once you have both "Generation A" and "Generation B",
how do you know which one to use to decrypt the YANG keys? If there were
a place to store a key ID in the YANG model, it could identify which of
the two keys to use. Lacking that, for some kinds of data, you can do a
"try both and see which works," but it's not clear that doing so is
possible in this case (since the thing you're decrypting is a key, and
will simply look like random bits regardless of which KEK you use on it,
you can't examine its structure to determine whether it is valid).
This isn't a blocking comment; I'm just wondering whether this
operational aspect occurred to the WG when this scheme was being
discussed, and whether there's some trivial way to perform KEK rotation
that could be described in the document. Without the ability to rotate
the KEK, I'm not sure this scheme is all that useful.
It seems that this should have been covered in some other Security RFC. If
not RFC 5649 (which seems to be inexplicably narrow in scope), then some
other Security document. If there is am out-of-band KEK procedure for
encryption of key string, then it should have been documented prior to my
usage. I’m copying Brian Weis (a Security Directorate member) who
originally suggested this. My inclination is to remove all traces of AEA
Key Wrap (RFC 5649) and rely on NCACM.
Thanks,
Acee
/a
_______________________________________________
rtgwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg
