Subject: Re: [Netconf] Unsigned configlets and physical security

From: Randy Presuhn <[email-masked]>
Date: Tue, 4 Mar 2014 12:07:06 -0800 (GMT-08:00)

Hi -

>From: Kent Watsen <[email-masked]>
>Sent: Mar 4, 2014 10:35 AM
>To: Randy Presuhn <[email-masked]>, "[email-masked]" <[email-masked]>
>Subject: Re: [Netconf] Unsigned configlets and physical security
...
>FWIW, The Security thinking is that someone that can get physical access
>to a device already owns it.

Stuxnet.

>So, requiring the Configlet to be signed
>doesn't protect anything and, given the logistical overhead involved in
>getting/using *signed* Configlets, would only frustrate trusted
>administrators.

If it's the administrator typing things in at a console, yes.
If it's the administrator bringing in the configuration data
on other media or via the network, clearly no.

>In this case, the administrator is using the Configlet
>because it's easier/more-scalable than manual configuration.

Thus increasing the likelihood that it's brought in on
external media, along with all the vulnerabilities that
come with that.

>Joe brings up the special case where an adversary doesn't get physical
>access, but passes an unsigned Configlet to a trusted administrator, who
>initializes a device using it without inspecting it first.  To be fair, it
>could be that trusted administrator could've been duped and actually
>thinks the Configlet is trusted and hence doesn't consider the need to
>[re]inspect it.   

That's where signatures can help, assuming they're actually
*checked* and the CAs involved haven't been subverted.

>Maybe this last issue be addressed via a Security Consideration - e.g.
>"unsigned Configlets SHOULD be inspected before each use."  What do you
>think?

You're much more optimistic than I about the likelihood
of discovering configuration errors by inspection.  Consider
possibilities like pointing to bogus DNS roots, installing
trojan-horse user IDs, pre-compromised keys for little-used
accounts, or weakening the encryption on selected links.
After all, an attacker's objective might simply be to make
sure that outgoing traffic is easily monitored.  An attack
could be as simple as changing a few bits in VACM's
configuration to allow the attacker to use SNMP
to complete the attack.

Randy

---

From: Dean Bogdanovic <[email-masked]>
Date: Thu, 6 Mar 2014 16:09:12 +0000

Randy,

Your points are valid, but we are seeing requests from data center operators to reduce some security levels for inside data centers, to make easier management. For them the big issue is how to make the build up of data centers as efficient as possible. Based on some requests seen so far, I would say with pretty high confidence that they would not mind carrying single USB with configs to setup basic functionality on network devices.

Dean

On Mar 4, 2014, at 8:07 PM, Randy Presuhn <[email-masked]> wrote:

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 6 Mar 2014 17:22:21 +0100

Hi,

I somehow doubt that 

   Further, this draft does not require Configlets to be
   signed, if loaded via a mechanism that asserts physical presence. or
   require those Configlets to have the device's unique identifier value
   set.  All of these relaxations in Security are deemed acceptable
   because physical presence should only be accessible to trusted
   parties.

will fly very high during security area review. Physical presence
obviously not always imply trusted parties. There might be deployments
where it does but in the general case it does not (and I personally
believe that even deployments where people think it does it might
actually not).

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Joe Marcus Clarke <[email-masked]>
Date: Thu, 06 Mar 2014 11:23:42 -0500

> Your points are valid, but we are seeing requests from data center operators to reduce some security levels for inside data centers, to make easier management. For them the big issue is how to make…

I agree with this, but would they mind a USB stick with signed 
configlets where the device loads _its_ configlet based on the fingerprint?

Joe

---

From: Dean Bogdanovic <[email-masked]>
Date: Thu, 6 Mar 2014 16:39:41 +0000

Don't know. I was very surprised by the request from the operators (as it opens up a big security whole), but they were very adamant about it.

At the moment, anything that inconvenience their process is a hinderance.

OTH, once they get burned, things might (I actually believe will) change. This is the reason why I'm saying put it optional. If you put it mandatory, it will hinder adoption.

Dean

On Mar 6, 2014, at 4:23 PM, Joe Marcus Clarke <[email-masked]> wrote:

> I agree with this, but would they mind a USB stick with signed configlets where the device loads _its_ configlet based on the fingerprint?
> 
> Joe
> 
>> 
>> Dean
>>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 6 Mar 2014 18:00:00 +0100

> OTH, once they get burned, things might (I actually believe will) change. This is the reason why I'm saying put it optional. If you put it mandatory, it will hinder adoption.

It needs to be mandatory to implement. If people then want to shoot
themself, let them do it. But it does not work to make this optional
to implement because this makes it hard for those who want to be
responsible.

/js

---

From: Kent Watsen <[email-masked]>
Date: Thu, 6 Mar 2014 17:06:58 +0000

>believe that even deployments where people think it does it might

I think there is a good chance it will fly because there is precedent in
the TPM specification [1], which uses physical presence to perform certain
administrative functions.  See section 10 (Physical Presence) in the
"Part 1: Design Principles" document.

However, to your point, we'd still need their sign off.  Since I'm on
friendly terms with sec folks (my other foot is in their area), I'll ask
the ADs when I see them next...

[1] http://www.trustedcomputinggroup.org/resources/tpm_main_specification

Thanks,
Kent

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 6 Mar 2014 18:19:47 +0100

> [1] http://www.trustedcomputinggroup.org/resources/tpm_main_specification

I am talking about the IETF. And it is not just physical presence, why
would you trust the content on the USB stick to be valid? The argument
someone can verify the content ad-hoc while plugging in the stick
sounds not very convincing to me.

/js

---

From: Joe Marcus Clarke <[email-masked]>
Date: Thu, 06 Mar 2014 13:02:23 -0500

> [1] http://www.trustedcomputinggroup.org/resources/tpm_main_specification

Thanks for the pointer, Kent.  In this section, though, I don't see the 
exact parallel to the USB stick idea.  That is, in this TPM diagram the 
administrator isn't bringing anything other than herself into the secure 
area (i.e., having physical proximity to the device).  With the USB 
example, the "malware" could be brought into the secure area without the 
administrator's knowledge (I agree, they should have checked first, 
but...).

Getting strong security advice would be good.

Joe

---

From: "ietfdbh" <[email-masked]>
Date: Thu, 6 Mar 2014 13:16:58 -0500

+1
See RFC3365, BCP61

David Harrington
[email-masked]
+1-603-828-1401

> -----Original Message-----
> From: Netconf [mailto:[email-masked]] On Behalf Of Juergen
> Schoenwaelder
> Sent: Thursday, March 06, 2014 12:00 PM
> To: Dean Bogdanovic
> Cc: Randy Presuhn; [email-masked]
> > Don't know. I was very surprised by the request from the operators (as
it
> opens up a big security whole), but they were very adamant about it.
> >
> > OTH, once they get burned, things might (I actually believe will)
change.
> This is the reason why I'm saying put it optional. If you put it
mandatory, it will
> hinder adoption.

---

From: Kent Watsen <[email-masked]>
Date: Fri, 7 Mar 2014 16:56:43 +0000

So after consulting a number of folks, both in and out of the security
area, we have the following:

Regarding scope

  Opinions: 

  1. Take loading Configlets from anything other than a Configuration
     Server out of draft, since it's not a protocol and can be a
     vendor-specific option.  Note, if we take it out, this entire
     discussion is mute.

  2. Leave loading Configlets via physical presence in the draft, as
     it squarely addresses a common interest and specifies the draft's
     position on the matter.  To some, since we're discussing on-boot
     behavior, if it's not specified, then it's implicitly not allowed.
     In fact, a statement to that effect is desired.

  My thoughts:

    Option #1 is a lot easier for us, but option #2 better serves the
    purpose, especially if willing to add a statement that anything
    not explicitly specified is disallowed.

Regarding signing:

  Opinions:

  1. Require signature in all cases

  2. Require signature for network-accessed Configlets and let vendors
     decide what is possible when via physical presence (e.g. SP-
     owned home equipment would require a signature, if said equipment
     supports physical-presence mechanism at all).  Additionally, the
     Ability to use an unsigned Configlet for many devices (because
     they don't require a unique-identifier) resolves logistical
     deployment issues.

  My thoughts:

     My primary concern here is how easy it is on trusted administrators,
     as there is significant overhead involved in getting a Configlet
     signed.  Please note that while the draft enables the signing role
     to be delegated to a 3rd-party, the delegation is unlikely to ever
     be to a specific customer (enterprise or SP), because that would
     enable the enterprise/SP to sign Configlets for devices that don't
     belong to them.  Further, if we insist on a signature, then we
     would also need to insist on the device's unique-identifier being
     in the Configlet to thwart substitution attacks.  This means that,
     for each device, trusted admins would have to go to the 3rd-party
     to get a Configlet signed, and they would have to insure that they
     loaded the right Configlet onto the right device.  One thing we
     could do to improve the situation would be to allow a Configlet to
     contain a list of unique-identifiers (not just one), thus allowing
     one Configlet to be loaded by more than one device.  Is it enough?

     FWIW, the only way I can imagine it being possible for a customer
     (enterprise/SP) to sign their own Configlets is if the customer
     receives customer-specific hardware that has been coded to trust
     a customer-specific trust-anchor, thus denying the ability for a
     Configlet signed by them to work on any other customer's equipment.

Regarding encryption:   (tangentially related)

  Opinions:

  1. Encryption is undesirable, as inspection of the Configlet's
     contents is needed

  2. Encryption is required, because content-inspection is undesirable.
     For instance, for home equipment, the SP doesn't want the end
     user to have any visibility into their network.

  My thoughts: 

     It is easy for the Configlet Signer to optionally encrypt a
     Confilglet using a device-specific public-key.  Obviously this
     only works for Configlets destined for a single device, not
     containing more than one unique-identifier.  I'm ok with this,
     is optional-encryption sufficient?  To be clear: device MUST
     Support encryption, user can choose if they want to use it...

Thanks,
Kent

---

From: Dean Bogdanovic <[email-masked]>
Date: Mon, 10 Mar 2014 21:32:26 +0000

Kent

Please see inline

>    not explicitly specified is disallowed.

idb>> I prefer the option #1, as it enables deployment according to local security policies (some enterprises might have less stringent security policies). Even worse is the statement that anything not explicitly specified is disallowed. That prevents deployment, unless security policies would be updated.
>     Configlet signed by them to work on any other customer's equipment.

idb>> In case my vote is decider, vote for option 2

---

From: Joe Marcus Clarke <[email-masked]>
Date: Mon, 10 Mar 2014 17:58:14 -0400

>      not explicitly specified is disallowed.

I think option 1 is safer, and vendors can be left up to their own 
decisions.

>       they don't require a unique-identifier) resolves logistical

I think we should mandate signing in all cases in the draft (which would 
be over the network).

But if you had a number of configlets each named with the fingerprint, 
you could always load the right one.  In this manner, you could have a 
number on the same disk and the device could pick the right one.

>       Support encryption, user can choose if they want to use it...

I agree.  I think encryption can be optional.  However, in light of 
pervasive monitoring, will the security directorate accept this?  Will 
encryption have to be made mandatory?

Joe