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

[Kathleen Moriarty <[e-mail]>]

On Thu, Apr 27, 2017 at 10:03 AM, Acee Lindem (acee) <[e-mail]> wrote:
> 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?

Yes, thanks.

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



-- 

Best regards,
Kathleen