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. Finally, do you know of any implementations of KEK? 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] > _______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
