Okay, on further digging through RFC5649, it does have handling for this
in the form of a 64-bit key data integrity check. So it looks like the
"try it and see if it works" approach will be fine.
/a
On 4/26/17 11:24, Adam Roach wrote:
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
