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

[Kathleen Moriarty <[e-mail]>]

Hi Brian & Acee,

On Wed, Apr 26, 2017 at 8:49 PM, Brian Weis (bew) <[e-mail]> 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) <[e-mail]> wrote:
>>
>> Kathleen,
>>
>> On 4/26/17, 4:47 PM, "Kathleen Moriarty"
>> <[e-mail]> wrote:
>>
>>> Acee,
>>>
>>>
>>>
>>> On Wed, Apr 26, 2017 at 4:39 PM, Acee Lindem (acee) <[e-mail]>
>>> 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

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"
>>>> <[e-mail]> 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
>>>>
>>>
>>>
>>>
>>> --
>>>
>>> Best regards,
>>> Kathleen
>>
>
> --
> Brian Weis
> Security, CSG, Cisco Systems
> Telephone: [phone]
> Email: [e-mail]
>



-- 

Best regards,
Kathleen