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. >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. 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 _______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
