On Thu, Apr 27, 2017 at 10:03 AM, Acee Lindem (acee) <[email protected]> wrote: > 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?
Yes, thanks. > > 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 > -- Best regards, Kathleen _______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
