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

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 26 Apr 2017 09:34:32 -0700

Kathleen Moriarty has entered the following ballot position for
draft-ietf-rtgwg-yang-key-chain-20: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-rtgwg-yang-key-chain/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Thanks for your work on this draft.  There is one outstanding issue from
the SecDir review that may require some updated text to resolve.  It
seems use of the key wrap method in RFC5649 requires more guidance for
implementations to use it with this YANG module.  It's good to know that
this is in use for other modules, so having a clear reference either to
another draft or the text being in this draft for later reference would
be helpful.

In looking at this text within the draft, I think it would be better to
pull the text out of the Security Considerations section and into an
earlier section of the draft.  It's better to introduce this prior to
enumerating security considerations for the draft since this something
that would be implemented.  Then security considerations should mention
the considerations of using this option versus just what's in NACM.

You have the text:

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

I think it's pretty straightforward after looking at RFC5649, but maybe
more text would be helpful to clarify for implementers.  This might mean
more text from 5649 on what gets placed in the YANG data model where you
have already allocated for this or including an example.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you for working through the SecDir review and making the suggested
updates.

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?

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 26 Apr 2017 16:52:24 +0000

Kathleen, 

The lack of KEK specification is not a problem with the YANG key-chain
model, it with RFC 5649 and KEK. I’d request that yourself or someone in
the security area provide a reference or text. A primary reason KEK has
not been widely deployed is that RFC 5649 is woefully lacking in
operational guidance. If you can’t do this, I’ll remove the reference and
rely on NCACM similar to the shared-secret data node in RFC 7317.

Thanks
Acee

On 4/26/17, 12:34 PM, "rtgwg on behalf of Kathleen Moriarty"
<[email-masked] on behalf of [email-masked]>
wrote:

>_______________________________________________
>rtgwg mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/rtgwg

---

From: Adam Roach <[email-masked]>
Date: Wed, 26 Apr 2017 13:42:14 -0500

> as a fallback from the recommendation, but not make them sound

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?

/a

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 26 Apr 2017 15:05:04 -0400

Hi Acee,

Adding Brian since he may be able to assist since he is familiar with
other implementations with YANG modules.

> rely on NCACM similar to the shared-secret data node in RFC 7317.

I'm not following you as to what is lacking, if you could please
expand on that it would be appreciated and then we can assist more.
RFC 3394 and RFC5649 are widely deployed according to the author.  Do
you mean deployed specific to YANG modules or something else?

Does the following guidance help:

    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

I think it would be better to have the text from the -20 version in
the body of the document (rather than security considerations
section), I see it was removed in -21.  Then have the considerations
for using/not using in the security considerations section.  I think
Brian's responses help cover some of what would go into the text for
the security considerations section.

Is this the text provided what you need help with or is it something
additional for developers?  By implementors, are you referring to the
developers or operators configuring the devices?  I just want to be
sure we are clear on the problem so we can assist.

Thank you,
Kathleen

-- 

Best regards,
Kathleen

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 26 Apr 2017 15:36:10 -0400

> 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.  Additionally, I haven't seen a discussion on the hardware
this is expected to run on.

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?

For YANG modules, couldn't the application via NETCONF/RESTCONF
accessing the module provide the credentials to access the key
protected by the KEK?  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. Use of a KEK is better then not encrypting and can be done
well.

Am I missing something?  Was there something implementation specific
that has the raw key stored with the encrypted data?

Thanks,
Kathleen

-- 

Best regards,
Kathleen

---

From: Adam Roach <[email-masked]>
Date: Wed, 26 Apr 2017 15:18:00 -0500

On 4/26/17 2:36 PM, Kathleen Moriarty wrote:
> can tell.

Right.

> Additionally, I haven't seen a discussion on the hardware

That might be appropriate matter for the draft, if it is going to make 
this recommendation.

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

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

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

Acee: "This is the correct interpretation."

/a

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 26 Apr 2017 16:30:09 -0400

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-masked]> wrote:
> That might be appropriate matter for the draft, if it is going to make this
> recommendation.
>
> I'll defer to you, of course, since you have presumably given the topic more
> thought than I have, but: yes.
>
> 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.
>
> posit, such as dedicated security hardware, it seems that such prerequisites
> should be mentioned alongside the recommendation.
>
> 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.

> 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

   hex-key-string feature is also required since the encrypted keys will

> Acee: "This is the correct interpretation."

Thanks.

-- 

Best regards,
Kathleen

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 26 Apr 2017 20:39:48 +0000

Kathleen, Brian, 

Since KEK as described in RFC 5649 is not ready for prime time, why don’t
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-masked]> wrote:

>>this
>>section
>>prerequisites
>>the
>>disk'

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 26 Apr 2017 16:47:44 -0400

Acee,

> Since KEK as described in RFC 5649 is not ready for prime time, why don’t

This is widely deployed in other use cases, 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?

Thank you,
Kathleen

-- 

Best regards,
Kathleen

---

From: Adam Roach <[email-masked]>
Date: Wed, 26 Apr 2017 15:52:40 -0500

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.

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.

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 26 Apr 2017 20:55:09 +0000

Kathleen,

On 4/26/17, 4:47 PM, "Kathleen Moriarty"
<[email-masked]> wrote:

>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

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 

>>>>>>> If obfuscation is what happens more often in practice, maybe
>>>>>>>mention
>>>>>>> this
>>>> that doing this poorly provides any benefit, and it seems to me that
>>>>it
>>>>may

---

From: "Brian Weis (bew)" <[email-masked]>
Date: Thu, 27 Apr 2017 00:49:11 +0000

Hi Kathleen and Acee,

Just a clarification on what I had said earlier.

> On Apr 26, 2017, at 1:55 PM, Acee Lindem (acee) <[email-masked]> wrote:
> 
> Kathleen,
> 

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.

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

Hope that helps,
Brian

>> Could you please be more explicit in terms of what

-- 
Brian Weis
Security, CSG, Cisco Systems
Telephone: +1 408 526 4796
Email: [email-masked]

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 26 Apr 2017 22:34:33 -0400

Hi Adam,

On Wed, Apr 26, 2017 at 4:52 PM, Adam Roach <[email-masked]> wrote:
> 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

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

-- 

Best regards,
Kathleen

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 26 Apr 2017 22:42:25 -0400

Hi Brian & Acee,

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

Thanks for saving me a step, I was going to use Jari's tool once I got
back online for the same purpose.

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

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?

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

Thank you,
Kathleen

-- 

Best regards,
Kathleen

---

From: Adam Roach <[email-masked]>
Date: Wed, 26 Apr 2017 22:00:11 -0500

> obfuscation at a minimum.

That's how I read it too: it's talking about how the key is stored. If 
it's encrypted with a real crypto operation, it's going to have a KEK 
(which isn't necessarily the same KEK as is used to decrypt the 
information received from a remote node, right?); and, if it's 
obfuscated, it doesn't even necessarily have a key at all, just some 
kind of reversible transformation.

Let's focus on the "obfuscation" case, because I think it's easier to 
reason about (and less likely to get conflated with other operations), 
and then we can extend that reasoning to the crypto case if we come to 
agreement. I'm making certain assumptions here which you may have a 
different read on (and, as before, this is your area, so I'd take your 
assumptions over my own) -- please correct me where I'm overstating or 
misstating things.

In the obfuscation case -- and barring any advanced anti-debugger and 
anti-ICE defenses -- reverse-engineering the obfuscation technique would 
be a fairly straightforward exercise. So I think we can safely assume 
that any such obfuscation performed by popular routers will be 
reversible by your average black-hat hacker.

That seems to negate most of the benefit obtained by obfuscation.

At the same time, an administrator observing that the stored value is 
not the same as the actual key may make the erroneous assumption that 
the on-disk value itself is not particularly high value, and may take 
steps that make it more likely to fall into the hands of an attacker 
than if the administrator saw the literal key present in the configuration.

That seems to make the obfuscation potentially harmful.

Little benefit with possible harm would, to me, indicate that 
obfuscation should not be employed.

> part of the thread where I'm hoping we can add the KEK back into the

I hope so too. As a process point: removing this from the document seems 
like a material change. If this went through WGLC and IETF LC with the 
KEK as part of the data model, I would think its removal would require 
WG buy-in, and running through IETF LC again.

/a

---

From: Alia Atlas <[email-masked]>
Date: Thu, 27 Apr 2017 00:02:14 -0400

I am just catching up on this conversation.

First, the YANG model is primarily for information in motion - either for
configuration to the device
or to read from the device.   It is much less likely to represent the data
structure and storage in the device.
I believe that this draft's context is strictly for information in motion.

This YANG model, as with all, is intended for transport over NetConf or
RestConf, which are confidential
transports.  Thus, any keys sent in the YANG model are already protected in
flight.

However, to allow for the limited cases (as I understand it) where that
isn't viewed as sufficient protection,
the key might be sent encrypted (via KEK) so it is encrypted before being
handed to the model, the configuration
action would be with the encrypted key, and then the device would have to
know how to decrypt it, which is all
out-of-band behavior as far as the YANG model and associated protocols go.

The gotcha - and why, as I understand it, that encrypted keys are even
mentioned is that it alters the data type
used for transmitting the key as in the snippet below.  Normally the
keystring would be a string, but if encrypted,
it is a hex-string - so arbitrary bytes.

"+--rw key-string

            |  +--rw (key-string-style)?
            |     +--:(keystring)
            |     |  +--rw keystring?            string
            |     +--:(hexadecimal) {hex-key-string}?
            |        +--rw hexadecimal-string?   yang:hex-string
"

This draft isn't trying to describe how or whether to use KEK.  It's just
making sure the YANG model is sufficient
general to transmit the key if it is previously encrypted.

Does that make sense and help clarify?

Regards,
Alia

On Wed, Apr 26, 2017 at 11:00 PM, Adam Roach <[email-masked]> wrote:

> (which isn't necessarily the same KEK as is used to decrypt the information
> received from a remote node, right?); and, if it's obfuscated, it doesn't
> even necessarily have a key at all, just some kind of reversible
> transformation.
>
> reason about (and less likely to get conflated with other operations), and
> then we can extend that reasoning to the crypto case if we come to
> anti-ICE defenses -- reverse-engineering the obfuscation technique would be
> a fairly straightforward exercise. So I think we can safely assume that any
> such obfuscation performed by popular routers will be reversible by your
> average black-hat hacker.
>
> At the same time, an administrator observing that the stored value is not
> the same as the actual key may make the erroneous assumption that the
> on-disk value itself is not particularly high value, and may take steps
> that make it more likely to fall into the hands of an attacker than if the
> administrator saw the literal key present in the configuration.
>
> Little benefit with possible harm would, to me, indicate that obfuscation
> should not be employed.
>
>
>
> like a material change. If this went through WGLC and IETF LC with the KEK
> as part of the data model, I would think its removal would require WG
> buy-in, and running through IETF LC again.
>
> /a
>
>

---

From: Alia Atlas <[email-masked]>
Date: Thu, 27 Apr 2017 00:11:37 -0400

One last piece (sorry to top-post, but scanning the relevant security
considerations piece in version -20):

With this model, any user/group can read the operational state via YANG
model and that would, by default, include
unencrypted keys being transmitted.  If NACM is supported, then only
certain users/groups would be able to access
the keys.  Without NACM, using the KEK ensures that even if a user/group
receives the operational state of the YANG
model, the keys aren't unencrypted.  Thus the user/group would need to have
access to the key used in KEK.

Does this match up with your understanding?

I think that Kathleen's Discuss is just asking for a paragraph - perhaps in
3.2 or a new 3.2.1 that describes the above
and that the key-handling for KEK is out-of-bounds.

Regards,
Alia

On Thu, Apr 27, 2017 at 12:02 AM, Alia Atlas <[email-masked]> wrote:

> transports.  Thus, any keys sent in the YANG model are already protected
> in flight.
>

---

From: Alia Atlas <[email-masked]>
Date: Thu, 27 Apr 2017 09:57:24 -0400

Hi Alexey,

On Thu, Apr 27, 2017 at 5:39 AM, Alexey Melnikov <[email-masked]>
wrote:

> Hi Alia,
>
> On Thu, Apr 27, 2017, at 05:02 AM, Alia Atlas wrote:
>
> I wish the document said that.
>
>
> As a side note, the document is confusing, because it doesn't explain when
> and why hexstring version is to be used.
> It also has some text suggesting that hexstring might be used to provide
> more entropy, which doesn't necessarily mean that the keystring contains
> encrypted key.
>

 Right - those are other reasons that someone might use a hex-string for
the key.

> This helps. The change in -21 to remove aes-key-wrap means that now it is
> not possible to tell whether the keystring is the passphrase/key itself or
> whether it contains encrypted key.
>

More - it doesn't tell the sender of the YANG model for providing current
state to encrypt the keys or the receiver that they are encrypted.

I do think it is worth working through the issues so that the aes-key-wrap
goes back in the document - but I need to talk to the authors and the WG.
This part of the draft is more aspirational which is why I think it is
being negotiable.

 Regards,
Alia

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 27 Apr 2017 14:00:58 +0000

Kathleen, Adam, Brian,

On 4/26/17, 10:34 PM, "Kathleen Moriarty"
<[email-masked]> wrote:

>>about

I don’t see what is unclear about the above. Other than an indication that
the KEK is in use for a particular key-chain, the YANG model is completely
independent of KEK. If a treatise on how to deploy KEK is required, it
should be in a separate document worked on in the Security Area and I
shouldn’t be subject to capricious DISCUSSes. I will add the statement,
“The procedures and details of ASE Key-Wrap deployment are beyond the
scope of this document.”

>obfuscation at a minimum.

While you might use KEK (RFC 5649) to encrypt keys in memory, this is a
more general statement with respect to keys not being stored in plain
text. It was requested during one of the reviews. However, I am happy to
remove it if it is problematic.

Thanks,
Acee 
>>be
>>in
>>discussion
>>>> storage on the device. Any processes involved in provisioning the
>>>>values
>>>> or

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 27 Apr 2017 14:03:04 +0000

Hi Kathleen, Brian,

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

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

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

Thanks,
Acee 

>>>>>>>>>> Since the following text int he Security Considerations section
>>>>>>>>>>is
>>>>>>>>>> a
>>>>>>> 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.
>>>>>>>
>>>>>>>> together is not the same as storing a key right next to the data
>>>>>>>>it
>>>>>>>> is
>>>>>>>> protecting.
>>>>>>>
>>>>>>>
>>>>>>> to the contrary -- implementors will choose to do it poorly. It's
>>>>>>>not
>>>>>>> clear
>>>>>>> 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
>>>>>>> values or
>>>>>>> by reading the encrypted form off disk, reading some keying
>>>>>>>material
>>>>>>> off

---

From: Adam Roach <[email-masked]>
Date: Thu, 27 Apr 2017 09:05:28 -0500

On 4/26/17 23:02, Alia Atlas wrote:
> First, the YANG model is primarily for information in motion - either 
> for configuration to the device
> or to read from the device.   It is much less likely to represent the 
> data structure and storage in the device.

Thanks; I understand all that. I'm trying to focus on the final 
paragraph of section 5, though, which appears to be an exception to what 
you say above.

/a

---

From: Alia Atlas <[email-masked]>
Date: Thu, 27 Apr 2017 10:15:57 -0400

On Thu, Apr 27, 2017 at 10:05 AM, Adam Roach <[email-masked]> wrote:

> Thanks; I understand all that. I'm trying to focus on the final paragraph
> of section 5, though, which appears to be an exception to what you say
> above.

I don't understand why - IMHO, that paragraph is simply saying  - this
model passes keys around (in motion).  Of course, a system shouldn't store
such keys unencrypted.  From what Acee says, this "motherhood and apple
pie" additional advice was added due to secdir review.

Regards,
Alia

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 27 Apr 2017 07:17:02 -0700

> pie" additional advice was added due to secdir review.

I thought Adam's point was that storing keys encrypted with a key that's
adjacent to them was not useful.

-Ekr

---

From: Alia Atlas <[email-masked]>
Date: Thu, 27 Apr 2017 10:21:16 -0400

> adjacent to them was not useful.

This is not at all in scope for this document.  It isn't giving
implementation-specific advice on how to manage and store keys.
It is providing a model to configure and read keys.

Alia

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 27 Apr 2017 14:23:18 +0000

From: Eric Rescorla <[email-masked]<mailto:[email-masked]>>
Date: Thursday, April 27, 2017 at 10:17 AM
To: Alia Atlas <[email-masked]<mailto:[email-masked]>>
Cc: Adam Roach <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Kathleen Moriarty <[email-masked]<mailto:[email-masked]>>, The IESG <[email-masked]<mailto:[email-masked]>>, Jeff Tantsura <[email-masked]<mailto:[email-masked]>>, Routing WG <[email-masked]<mailto:[email-masked]>>
Subject: Re: Kathleen Moriarty's Discuss on draft-ietf-rtgwg-yang-key-chain-20: (with DISCUSS and COMMENT)
Resent-From: <[email-masked]<mailto:[email-masked]>>
Resent-To: Acee Lindem <[email-masked]<mailto:[email-masked]>>, Jeffrey Zhang <[email-masked]<mailto:[email-masked]>>, Derek Yeung <[email-masked]<mailto:[email-masked]>>, Yingzhen Qu <[email-masked]<mailto:[email-masked]>>, Ing-Wher Chen <[email-masked]<mailto:[email-masked]>>
Resent-Date: Thursday, April 27, 2017 at 10:17 AM

On Thu, Apr 27, 2017 at 7:15 AM, Alia Atlas <[email-masked]<mailto:[email-masked]>> wrote:
On Thu, Apr 27, 2017 at 10:05 AM, Adam Roach <[email-masked]<mailto:[email-masked]>> wrote:
On 4/26/17 23:02, Alia Atlas wrote:
First, the YANG model is primarily for information in motion - either for configuration to the device
or to read from the device.   It is much less likely to represent the data structure and storage in the device.
I believe that this draft's context is strictly for information in motion.

Thanks; I understand all that. I'm trying to focus on the final paragraph of section 5, though, which appears to be an exception to what you say above.

I don't understand why - IMHO, that paragraph is simply saying  - this model passes keys around (in motion).  Of course, a system shouldn't store such keys unencrypted.  From what Acee says, this "motherhood and apple pie" additional advice was added due to secdir review.

I thought Adam's point was that storing keys encrypted with a key that's adjacent to them was not useful.

Right. I’m not sure what the definition of “adjacent” is here since it is very implementation specific. I will remove the final paragraph in the next revision when I add KEK back (assuming we can agree on reasonable guidance and which RFC to reference). What I’m strongly opposed to is pushing this back in the process for such a change.

Acee

-Ekr

Regards,
Alia

/a

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 27 Apr 2017 07:28:01 -0700

On Thu, Apr 27, 2017 at 7:23 AM, Acee Lindem (acee) <[email-masked]> wrote:

>
>
> From: Eric Rescorla <[email-masked]>
> To: Alia Atlas <[email-masked]>
> Cc: Adam Roach <[email-masked]>, "[email-masked]" <
> [email-masked]>, "[email-masked]" <
> [email-masked]>, Kathleen Moriarty <
> [email-masked]>, The IESG <[email-masked]>, Jeff
> Tantsura <[email-masked]>, Routing WG <[email-masked]>
> Resent-From: <[email-masked]>
> Resent-To: Acee Lindem <[email-masked]>, Jeffrey Zhang <[email-masked]>,
> Derek Yeung <[email-masked]>, Yingzhen Qu <[email-masked]>,
> Ing-Wher Chen <[email-masked]>
> Right. I’m not sure what the definition of “adjacent” is here since it is
> very implementation specific. I will remove the final paragraph in the next
> revision when I add KEK back (assuming we can agree on reasonable guidance
> and which RFC to reference). What I’m strongly opposed to is pushing this
> back in the process for such a change.
>

I'm not arguing for any particular outcome, merely making a technical
observation about what is and is not useful from a security perspective.

-Ekr

---

From: Kathleen Moriarty <[email-masked]>
Date: Thu, 27 Apr 2017 11:11:14 -0400

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

Yes, thanks.

-- 

Best regards,
Kathleen

---

From: Kathleen Moriarty <[email-masked]>
Date: Thu, 27 Apr 2017 11:13:06 -0400

On Thu, Apr 27, 2017 at 10:28 AM, Eric Rescorla <[email-masked]> wrote:
>> Cc: Adam Roach <[email-masked]>, "[email-masked]"
>> <[email-masked]>, "[email-masked]"
>> <[email-masked]>, Kathleen Moriarty
>> <[email-masked]>, The IESG <[email-masked]>, Jeff Tantsura
>> <[email-masked]>, Routing WG <[email-masked]>
>> Subject: Re: Kathleen Moriarty's Discuss on
>> draft-ietf-rtgwg-yang-key-chain-20: (with DISCUSS and COMMENT)
>> Resent-To: Acee Lindem <[email-masked]>, Jeffrey Zhang
>> <[email-masked]>, Derek Yeung <[email-masked]>, Yingzhen Qu
>> <[email-masked]>, Ing-Wher Chen <[email-masked]>
>>>> paragraph of section 5, though, which appears to be an exception to what you
>>>> say above.
>>>
>>>
>>> such keys unencrypted.  From what Acee says, this "motherhood and apple pie"
>>> additional advice was added due to secdir review.
>>
>>

As I understand it, the KEK is not generated on device, so they are
not stored together.  The KEK would be out-of-band and how it's
accessed will be implementation specific.

-- 

Best regards,
Kathleen