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

["Acee Lindem (acee)" <[e-mail]>]

Hi Kathleen, Brian,

On 4/26/17, 10:42 PM, "Kathleen Moriarty"
<[e-mail]> wrote:

>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

In this case, it is only the keys, so I should change the reference to RFC
3394?

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"
>>>>> <[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