Hi Kathleen, Brian, On 4/26/17, 10:42 PM, "Kathleen Moriarty" <[email protected]> wrote:
>Hi Brian & Acee, > >On Wed, Apr 26, 2017 at 8:49 PM, Brian Weis (bew) <[email protected]> wrote: >> Hi Kathleen and Acee, >> >> Just a clarification on what I had said earlier. >> >>> On Apr 26, 2017, at 1:55 PM, Acee Lindem (acee) <[email protected]> wrote: >>> >>> Kathleen, >>> >>> On 4/26/17, 4:47 PM, "Kathleen Moriarty" >>> <[email protected]> wrote: >>> >>>> Acee, >>>> >>>> >>>> >>>> On Wed, Apr 26, 2017 at 4:39 PM, Acee Lindem (acee) <[email protected]> >>>> wrote: >>>>> Kathleen, Brian, >>>>> >>>>> Since KEK as described in RFC 5649 is not ready for prime time, why >>>>> don’t >>>> >>>> This is widely deployed in other use cases, >>> >>> None of these use cases are documented in IETF RFCs or drafts. >> >> The AES key wrap method itself is well understood, and if you look at >>the citations for RFC 3394 at >><http://www.arkko.com/tools/allstats/citations-rfc3394.html> it is >>actually used in a number of IETF protocols. This is the basis for why I >>originally suggested that it made sense to include it in a YANG model >>that distributes keys. >> > >Thanks for saving me a step, I was going to use Jari's tool once I got >back online for the same purpose. > >>> >>>> so I am not following this >>>> statement that it isn't ready for prime time. RFC5649 is >>>> straightforward. What is the gap for your usage that requires >>>> additional guidance? Brian says this in in use for other YANG modules >>>> already as well. >> >> Apologies, I was unclear in what I said. I am not actually aware of it >>being used in other YANG modules … I meant to communicate what Kathleen >>said more succinctly, which is that the RFC 3394 and RFC 5649 are >>implemented for the same purpose in other (non-YANG module) protocols. >>None of the citations in the list above appear to be YANG modules, but >>then I’m not sure whether or not any other YANG modules distribute keys >>either. > >Thanks, Brian, that is helpful. > >Acee, after a little more reading, is the gap for implementation >guidance on how to use/access the key encrypting key because of the >following sentence in -20? > > The AES key-encryption key (KEK) is > not included in the YANG model and must be set or derived independent > of key-chain configuration. > >This is an important step, I'm guessing Brian helped with this text >and that may be where you need some guidance for implementing the key >distribution functions with a stored KEK instead of the key obfuscated >in some way. Personally, I'd leave this as implementation specific >and the guidance here is enough for the draft, but vendors >implementing would have to figure out how they want to do this. >Before going further, can I confirm with you that this is the place >where you'd like guidance? > >The guidance I provided earlier that is not in the draft is as follows >(but might not answer your question): > > If you want to wrap an AES key and nothing else, use RFC 3394 > If you want to wrap an AES key and some other attributes too, use RFC >5649 In this case, it is only the keys, so I should change the reference to RFC 3394? Thanks, Acee > >Thank you, >Kathleen > >> >> Hope that helps, >> Brian >> >>>> Could you please be more explicit in terms of what >>>> you need for guidance. I offered a suggestion, if that isn't enough, >>>> could you please explain the gap as you see it so we can assist? >>> >>> Sorry, I must have missed the text you recommended. Please provide it >>> again and I will restore the option with the guidance that is missing >>>from >>> RFC 5649. >>> >>> Thanks, >>> Acee >>> >>> >>> >>> >>>> >>>> Thank you, >>>> Kathleen >>>> >>>>> you take this up as a separate draft rather than trying to hold this >>>>> important document hostage? We have the NETCONF Access Control Model >>>>> (NACM) to protect the keys during transport (which has been >>>>> implemented). >>>>> Obviously, key-strings are stored on devices today since they are >>>>>being >>>>> used for protocol authentication and encryption so this is totally >>>>> orthogonal to the YANG model being used to provision them. >>>>> >>>>> Thanks, >>>>> Acee >>>>> >>>>> On 4/26/17, 4:30 PM, "Kathleen Moriarty" >>>>> <[email protected]> wrote: >>>>> >>>>>> Hi Adam, >>>>>> >>>>>> I think I see where we are coming to different conclusions.... >>>>>> >>>>>> On Wed, Apr 26, 2017 at 4:18 PM, Adam Roach <[email protected]> >>>>>>wrote: >>>>>>> On 4/26/17 2:36 PM, Kathleen Moriarty wrote: >>>>>>>> >>>>>>>> On Wed, Apr 26, 2017 at 2:42 PM, Adam Roach <[email protected]> >>>>>>>>wrote: >>>>>>>>> >>>>>>>>> On 4/26/17 11:34 AM, Kathleen Moriarty wrote: >>>>>>>>>> >>>>>>>>>> Since the following text int he Security Considerations section >>>>>>>>>>is >>>>>>>>>> a >>>>>>>>>> recommendation, IMO it would be better to drop "or otherwise >>>>>>>>>> obfuscated" >>>>>>>>>> from the sentence as encrypting the keys really should be the >>>>>>>>>> recommendation. Can we make this update? >>>>>>>>>> >>>>>>>>>> It is RECOMMENDED that keys be encrypted or otherwise >>>>>>>>>> obfuscated >>>>>>>>>> when >>>>>>>>>> stored internally on a network device supporting this >>>>>>>>>> specification. >>>>>>>>>> >>>>>>>>>> If obfuscation is what happens more often in practice, maybe >>>>>>>>>> mention >>>>>>>>>> this >>>>>>>>>> as a fallback from the recommendation, but not make them sound >>>>>>>>>> equivalent? >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> To be clear -- the current guidance from the security area is to >>>>>>>>> perform >>>>>>>>> this kind of encryption, where you have encrypted material living >>>>>>>>> side-by-side with the key necessary to decrypt it? >>>>>>>> >>>>>>>> We are talking about using a key encrypting key (KEK) and storing >>>>>>>> that, not storing the raw key next to the encrypted data as far >>>>>>>>as I >>>>>>>> can tell. >>>>>>> >>>>>>> >>>>>>> Right. >>>>>>> >>>>>>>> Additionally, I haven't seen a discussion on the hardware >>>>>>>> this is expected to run on. >>>>>>> >>>>>>> >>>>>>> That might be appropriate matter for the draft, if it is going to >>>>>>>make >>>>>>> this >>>>>>> recommendation. >>>>>>> >>>>>>>> Some implementations of KEK solutions use dedicated hardware for >>>>>>>>the >>>>>>>> KEK and require authentication for access to the key, hence >>>>>>>> preventing >>>>>>>> generic access and side-by-side storage of the KEK's protected >>>>>>>>key, >>>>>>>> and encrypted data. I'd rather see a KEK used than just a key >>>>>>>>stored >>>>>>>> in any case. Are you arguing for not using any encryption at all? >>>>>>> >>>>>>> >>>>>>> I'll defer to you, of course, since you have presumably given the >>>>>>> topic >>>>>>> more >>>>>>> thought than I have, but: yes. >>>>>>> >>>>>>> Absent something like an HSM or forcing human intervention >>>>>>>whenever a >>>>>>> process starts (or restarts), it seems that the scheme described in >>>>>>> section >>>>>>> 5 doesn't actually deter a competent attacker from obtaining the >>>>>>>keys. >>>>>>> My >>>>>>> impression is that storing information in an encrypted form that >>>>>>>can >>>>>>> be >>>>>>> trivially decrypted by an attacker provides a false sense of >>>>>>>security >>>>>>> to >>>>>>> equipment operators. >>>>>>> >>>>>>> If the scheme in section 5 *does* require the kind of prerequisites >>>>>>> you >>>>>>> posit, such as dedicated security hardware, it seems that such >>>>>>> prerequisites >>>>>>> should be mentioned alongside the recommendation. >>>>>>> >>>>>>>> For YANG modules, couldn't the application via NETCONF/RESTCONF >>>>>>>> accessing the module provide the credentials to access the key >>>>>>>> protected by the KEK? >>>>>>> >>>>>>> >>>>>>> That solves the issues with provisioning, but doesn't seem to help >>>>>>>the >>>>>>> processes actually involved in routing. >>>>>>> >>>>>>>> Some implementations could store the KEK in >>>>>>>> dedicated hardware as well. In this way, storing the KEK and data >>>>>>>> together is not the same as storing a key right next to the data >>>>>>>>it >>>>>>>> is >>>>>>>> protecting. >>>>>>> >>>>>>> >>>>>>> This makes perfect sense; and it should probably be in the >>>>>>>document. >>>>>>> >>>>>>>> Use of a KEK is better then not encrypting and can be done >>>>>>>> well. >>>>>>> >>>>>>> >>>>>>> It can also be done poorly, and the mention of obfuscation (along >>>>>>>with >>>>>>> the >>>>>>> exchange I cite below) leads me to believe that -- absent concrete >>>>>>> guidance >>>>>>> to the contrary -- implementors will choose to do it poorly. It's >>>>>>>not >>>>>>> clear >>>>>>> that doing this poorly provides any benefit, and it seems to me >>>>>>>that >>>>>>> it >>>>>>> may >>>>>>> cause harm: if something _looks_ secure but isn't, doesn't that >>>>>>>have >>>>>>> the >>>>>>> potential for operators to incorrectly treat it as secure? Again, >>>>>>>this >>>>>>> is >>>>>>> more your area than mine and so I will defer to your opinion on the >>>>>>> topic; >>>>>>> but from a lay perspective, this seems likely to result in the >>>>>>>lack of >>>>>>> guarding against compromise of the encrypted information under the >>>>>>> mistaken >>>>>>> impression that it can't be decrypted trivially. >>>>>>> >>>>>> >>>>>> The way I read the thread from Acee is that there aren't any KEK >>>>>> implementations with with particular YANG module, however Brian says >>>>>> there is with other YANG modules. I *think* when Acee is referring >>>>>>to >>>>>> obfuscation and less than ideal scenarios, it is with the currently >>>>>> deployed implementations that don't use KEKs. But the text and >>>>>> responses did seem to be commingled a bit too much. >>>>>> >>>>>>> >>>>>>>> Am I missing something? Was there something implementation >>>>>>>>specific >>>>>>>> that has the raw key stored with the encrypted data? >>>>>>> >>>>>>> >>>>>>> Perhaps the following exchange with the author: >>>>>>> >>>>>>> Adam: "By my reading, this is just talking about encrypting 'on the >>>>>>> disk' >>>>>>> storage on the device. Any processes involved in provisioning the >>>>>>> values or >>>>>>> using them to process traffic would have access to the plaintext, >>>>>>> presumably >>>>>>> by reading the encrypted form off disk, reading some keying >>>>>>>material >>>>>>> off >>>>>>> disk, and combining them to retrieve the plaintext key." >>>>>> >>>>>> It looks like version 20 had different assumptions about using the >>>>>> KEK. I *think* this is describing usage without a KEK and may be >>>>>>part >>>>>> of why Acee is asking for more implementation guidance... so I'll >>>>>>keep >>>>>> my discuss to see if we can shape that up more. This is helpful as >>>>>>I >>>>>> think I see the gap more now as to what he might be looking for in >>>>>> terms of guidance. >>>>>> >>>>>> Here's the text from -20: >>>>>> >>>>>> When configured, the key-strings can be encrypted using the AES Key >>>>>> Wrap algorithm [AES-KEY-WRAP]. The AES key-encryption key (KEK) is >>>>>> not included in the YANG model and must be set or derived >>>>>>independent >>>>>> >>>>>> Lindem, et al. Expires October 20, 2017 >>>>>>[Page 15] >>>>>> Internet-Draft YANG Key Chain April >>>>>>2017 >>>>>> >>>>>> of key-chain configuration. When AES key-encryption is used, the >>>>>> hex-key-string feature is also required since the encrypted keys >>>>>>will >>>>>> contain characters that are not representable in the YANG string >>>>>> built-in type [YANG]. AES key-encryption MAY be used for added key >>>>>> security in situations where the NETCONF Access Control Mode is not >>>>>> available. >>>>>> >>>>>>> >>>>>>> Acee: "This is the correct interpretation." >>>>>>> >>>>>>> /a >>>>>> >>>>>> Thanks. >>>>>> >>>>>> -- >>>>>> >>>>>> Best regards, >>>>>> Kathleen >>>>> >>>> >>>> >>>> >>>> -- >>>> >>>> Best regards, >>>> Kathleen >>> >> >> -- >> 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
