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
