Kathleen, Adam, Brian, On 4/26/17, 10:34 PM, "Kathleen Moriarty" <[email protected]> wrote:
>Hi Adam, > > > >On Wed, Apr 26, 2017 at 4:52 PM, Adam Roach <[email protected]> wrote: >> Sorry for top-posting, but I want to see if we can untangle something. >> >> I'm glad this is getting clearer for you, but it's just getting more >> confusing for me. In the -20 version of the document, there was text >>about >> using a KEK for data in motion (section 5 paragraph 3), and a separate >> mention of using a KEK for data at rest (section 5, final >>paragraph)[1]. For >> clarity: for the remainder of this thread, I will refer to these as >> KEK-motion and KEK-rest respectively. >> > >The draft is about stored key chain in a YANG module accessed (key >distribution) for different purposes. Using a KEK is just a way to >protect the key that is stored. NETCONF (with SSH) or RESTCONF (with >TLS) are required for secure access to the keys or if a KEK is used, >the protected keys. In-motion (if I understand you correctly) is just >the transport of this data model element for use. > >As stated in the introduction, the key might not be used directly and >there's no mention of using this key to protect data that is stored >with the key: > > In some applications, the protocols do not use the key chain element > key directly, but rather a key derivation function is used to derive > a short-lived key from the key chain element key (e.g., the Master > Keys used in [TCP-AO]). > >If a KEK is used, this is talking about the protected key. > >What I am trying to help Acee with is on the following from -20 so he >has some implementation guidance around using a KEK: > > The AES key-encryption key (KEK) is > not included in the YANG model and must be set or derived independent > of key-chain configuration. I don’t see what is unclear about the above. Other than an indication that the KEK is in use for a particular key-chain, the YANG model is completely independent of KEK. If a treatise on how to deploy KEK is required, it should be in a separate document worked on in the Security Area and I shouldn’t be subject to capricious DISCUSSes. I will add the statement, “The procedures and details of ASE Key-Wrap deployment are beyond the scope of this document.” > >The final paragraph, I believe is referring to how the key is stored - >either a KEK is used and it's encrypted or it's not and it's advising >obfuscation at a minimum. While you might use KEK (RFC 5649) to encrypt keys in memory, this is a more general statement with respect to keys not being stored in plain text. It was requested during one of the reviews. However, I am happy to remove it if it is problematic. Thanks, Acee > >Does that help? I'll defer to the authors and AD and get back to the >part of the thread where I'm hoping we can add the KEK back into the >draft. > >Regards, >Kathleen > >> For additional clarity, the exchange with Acee I cite below predates the >> release of the -21 version of the document, so it can only be in >>reference >> to the -20 version. >> >> While I see that there are probably some operational issues that need >>to be >> resolved regarding KEK-motion, I would like to treat them separately >>from my >> concerns with KEK-rest. >> >> My concern here is exclusively with regards to KEK-rest, which seems to >>be >> suffering some degree of conflation with KEK-motion, and which will have >> distinctly different considerations regarding whether and how it can be >> compromised. >> >> I have more to say on this, but would like to pause and make sure we're >>in >> concordance that there are two unrelated KEKs in play here. >> >> /a >> >> ____ >> [1] I cite as evidence that these are two different KEKs under >>discussion >> the following two points: (a) the third paragraph talks about KEKs in >>terms >> of RFC 5649, which requires AES; while the final paragraph talks about >> encryption "or obfuscation," which clearly can't be RFC 5649; and (b) >>in the >> -21 version of the document, all mention of RFC 5649 has been stricken, >> while the final paragraph of section 5 remains. >> >> >> >> On 4/26/17 3:30 PM, Kathleen Moriarty 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 _______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
