On Wed, Apr 26, 2017 at 12:04 PM, Brian Weis (bew) <[email protected]> wrote: > Hi Acee, > > On Apr 26, 2017, at 8:55 AM, Acee Lindem (acee) <[email protected]> wrote: > > Hi Brian, > > On 4/26/17, 11:45 AM, "Brian Weis (bew)" <[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.
Great, is this already documented in a draft or RFC for usage with YANG data models? If so, a reference to that would help or additional text in this draft. Having the guidance in one document to reference would be helpful in any case (might be this one, I suspect). Thanks, Kathleen > > Brian > > > Thanks, > Acee > > > 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 > > > > -- > Brian Weis > Security, CSG, Cisco Systems > Telephone: +1 408 526 4796 > Email: [email protected] > > > -- > Brian Weis > Security, CSG, Cisco Systems > Telephone: +1 408 526 4796 > Email: [email protected] > -- Best regards, Kathleen _______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
