Thanks, Brian for chiming in, I am just finishing my read of this draft and looking at the NACM & referenced RFC5649.
On Wed, Apr 26, 2017 at 11: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. I'd like to see this option stay as having better options to protect keys is important. Having said that, I agree that there isn't enough guidance for the implementer and it would be good to add add that into this draft. I can put a discuss placeholder while we wait for that text. > > Finally, do you know of any implementations of KEK? This would be very helpful to know as well and if adding the guidance to implement will increase the likelihood. Thank you, Kathleen > > 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] >> > -- Best regards, Kathleen _______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
