Re: Kathleen Moriarty's Discuss on draft-ietf-rtgwg-yang-key-chain-20: (with DISCUSS and COMMENT)

[Kathleen Moriarty <[e-mail]>]

Hi Adam,



On Wed, Apr 26, 2017 at 4:52 PM, Adam Roach <[e-mail]> 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.

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.

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 <[e-mail]> wrote:
>>>
>>> On 4/26/17 2:36 PM, Kathleen Moriarty wrote:
>>>>
>>>> On Wed, Apr 26, 2017 at 2:42 PM, Adam Roach <[e-mail]> 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