Hi Acee, On Apr 26, 2017, at 8:55 AM, Acee Lindem (acee) <[email protected]<mailto:[email protected]>> wrote:
Hi Brian, On 4/26/17, 11:45 AM, "Brian Weis (bew)" <[email protected]<mailto:[email protected]>> 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. Since RFC 5649 is simply the algorithm without much guidance on operations, the inclusion of this option has raised more questions than the commensurate benefit. Additionally, there is nothing precluding a user from deploying KEK for the keys in the YANG key-chain model. If you took out the key wrap method, then stating how a user might do the key wrapping themselves should be described in the draft. I guess that makes them responsible for pre- and post- processing of the keys in an implementation-specific manner.. Finally, do you know of any implementations of KEK? Not with this data model, because I’m not involved with implementations of the data model. The use of a key wrap and KEK is used in other cases. Brian Thanks, Acee Hope that helps, Brian On Apr 25, 2017, at 5:47 PM, Acee Lindem (acee) <[email protected]<mailto:[email protected]>> wrote: On 4/25/17, 6:44 PM, "Adam Roach" <[email protected]<mailto:[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]<mailto:[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 -- Brian Weis Security, CSG, Cisco Systems Telephone: +1 408 526 4796 Email: [email protected]<mailto:[email protected]> -- Brian Weis Security, CSG, Cisco Systems Telephone: +1 408 526 4796 Email: [email protected]<mailto:[email protected]>
_______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
