Subject: [Anima] What elements of IETF ANIMA can be used for I2NSF?

From: Linda Dunbar <[email-masked]>
Date: Thu, 23 Oct 2014 17:26:20 +0000

I2NSF is to develop application /user oriented policies (the attributes,  the profiles, or the descriptors ) of the network security functions that clients can request/query from 3rd party  providers.

ANIMA (Autonomic Networking Integrated Model and Approach) introduces a control paradigm where network processes, driven by objectives (or intent), coordinate their local decisions, autonomically translate them into local actions, and adapt them automatically according to various sources of information including external information and protocol information bases.

ANIMA will develop protocols to achieve auto discovery among management system and devices. The listed drafts proposed the "The Configuration Discovery and Negotiation protocol designed to be a generic platform, which is independent from the negotiation contents." There is also the Security aspects being discussed in the ANIMA drafts (like secure messages, or keys, among the parties (to be discovered).

Are there some elements developed by ANIMA that can be used by I2NSF?

Linda

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 24 Oct 2014 08:33:39 +1300

Linda,

> Are there some elements developed by ANIMA that can be used by I2NSF?

I think the short answer is that it's too soon to answer that question.
The long answer is that I suppose I2NSF would need to identify how
it could be described as a use case for autonomic networking (rather
than as a top-down management use case). For example could the
autonomic discovery mechanism be used to find the I2NSF provider,
even if a specific mechanism was used to download the security
policy itself?

One issue is the trust boundary. We assume that participants in an
autonomic network have a common trust anchor. How can we trust a
"3rd party" provider?

   Brian

On 24/10/2014 06:26, Linda Dunbar wrote:
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Anima mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima

---

From: Rene Struik <[email-masked]>
Date: Thu, 23 Oct 2014 15:41:52 -0400

[pruning the email cc to being just Anima]

Hi Brian:

I am somewhat puzzled by the homogeneous trust domain remark below. Shouldn't one aim for supporting heterogeneous trust domains as well (e.g., so as to support devices from multiple vendors). Note: I do realize only considering homogeneous domains make life easier, but also makes this less applicable to real-life systems (including constrained networks, IoT, etc.).

Best regards, Rene

==
We assume that participants in an autonomic network have a common trust anchor.

-- 
email: [email-masked] | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 24 Oct 2014 13:29:50 +1300

On 24/10/2014 08:41, Rene Struik wrote:
> I am somewhat puzzled by the homogeneous trust domain remark below.
> Shouldn't one aim for supporting heterogeneous trust domains as well
> (e.g., so as to support devices from multiple vendors). 

I don't see why equipment from multiple vendors needs multiple trust
domains. Can you explain? My assumption is that we don't want anything
like "call home", because that would expose autonomic nodes to direct
attacks from outside. So personally I see heterogeneous trust domains
as a bug, not a feature. However, we certainly need to develop a
complete threat analysis before deciding this question.

   Brian

> Note: I do
> realize only considering homogeneous domains make life easier, but also
> makes this less applicable to real-life systems (including constrained
> networks, IoT, etc.).
> 
> Best regards, Rene
> 
> 
> ==
>>> I2NSF is to develop application /user oriented policies (the
>>> attributes,  the profiles, or the descriptors ) of the network
>>> security functions that clients can request/query from 3rd party 
>>> providers.
>>>
>>> ANIMA (Autonomic Networking Integrated Model and Approach) introduces
>>> a control paradigm where network processes, driven by objectives (or
>>> intent), coordinate their local decisions, autonomically translate
>>> them into local actions, and adapt them automatically according to
>>> various sources of information including external information and
>>> protocol information bases.
>>>
>>> ANIMA will develop protocols to achieve auto discovery among
>>> management system and devices. The listed drafts proposed the "The
>>> Configuration Discovery and Negotiation protocol designed to be a
>>> generic platform, which is independent from the negotiation
>>> contents." There is also the Security aspects being discussed in the
>>> ANIMA drafts (like secure messages, or keys, among the parties (to be
>>> discovered).
>>>
>>>

---

From: Toerless Eckert <[email-masked]>
Date: Sun, 26 Oct 2014 17:48:33 -0700

I hope you are both right but talk about different stages.

We want common trust anchors for the running autonomic network and those
ultimately should be defined by the owner of the network. But during
enrollment of devices into that owners network, the manufacturer installed
certificate and trust-points in the to-be-enrolled devices will differ
by vendor.

Yes?No?;-)

Toerless

-- 
---
Toerless Eckert, [email-masked]

---

From: Michael Richardson <[email-masked]>
Date: Sun, 26 Oct 2014 21:33:23 -0400

> We want common trust anchors for the running autonomic network and
    > those ultimately should be defined by the owner of the network. But
    > during enrollment of devices into that owners network, the manufacturer
    > installed certificate and trust-points in the to-be-enrolled devices
    > will differ by vendor.

Yes from me.
This is the critical part that we (an SDO) has to get right.

Once the device is enrolled, it can be tweaked in a dozen different ways to
behave properly if necessary.

I don't think that a device with security functions will be asked to perform
them prior to being enrolled, so by the time a device becomes relevant from
an I2NSF point of view, the device will have a single (local) trust anchor.

(If multiple trust anchors are necessary, that's what certificate chains are
for, and it's way better to use that rather than multiple trust points if you can)

Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 27 Oct 2014 15:50:12 +1300

> This is the critical part that we (an SDO) has to get right.

That might be the way to do it. But another way is that when an
operator receives a new box, the box goes to a central place to have a
locally generated key pair and certificate installed, before going
to the warehouse for a later truck roll. I don't think we can exclude
that solution for a highly paranoid operator, who wants absolutely
no traffic about the enrollment to go outside. I think we need to
keep both options open.

Apart from that, I agree with what Toerless said.

   Brian

---

From: Michael Richardson <[email-masked]>
Date: Mon, 27 Oct 2014 08:17:30 -0400

Brian E Carpenter <[email-masked]> wrote:
    >> Toerless Eckert <[email-masked]> wrote: > I hope you are both right
    >> but talk about different stages.
    >>
    >> > We want common trust anchors for the running autonomic network and >
    >> those ultimately should be defined by the owner of the network. But >
    >> during enrollment of devices into that owners network, the
    >> manufacturer > installed certificate and trust-points in the
    >> to-be-enrolled devices > will differ by vendor.
    >>
    >> Yes from me.  This is the critical part that we (an SDO) has to get
    >> right.

    > locally generated key pair and certificate installed, before going to
    > the warehouse for a later truck roll. I don't think we can exclude that
    > solution for a highly paranoid operator, who wants absolutely no
    > traffic about the enrollment to go outside. I think we need to keep
    > both options open.

I don't see this as two options. It's one.

All that you've said is that the operator did the initial imprinting in
the warehouse rather than in the field.   If all boxes in the field have been
imprinted in this way, then there are no additional trust issues.
If some have been installed this way, and some have not, perhaps there are
bridge CAs needed to enable to the imprinted boxes to trust the "stock"
machines.

Why do you think that this is two ways?  Maybe I'm missing something.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 28 Oct 2014 08:33:13 +1300

> Why do you think that this is two ways?  Maybe I'm missing something.

I had understood that people were thinking of a mechanism whereby the
enrolment process would rely on a transaction with the manufacturer's
CA, i.e. communication outside the operator's own network, to validate
the device identity.

   Brian

---

From: Michael Richardson <[email-masked]>
Date: Mon, 27 Oct 2014 17:59:14 -0400

Brian E Carpenter <[email-masked]> wrote:
    brian> We want common trust anchors for the running autonomic network
    brian> and those ultimately should be defined by the owner of the
    brian> network. But during enrollment of devices into that owners
    brian> network, the >> manufacturer installed certificate and trust-points
    brian> in the to-be-enrolled devices will differ by vendor.

    mcr> Yes from me.  This is the critical part that we (an SDO) has to get
    mcr> right.

    brian> That might be the way to do it. But another way is that when an >
    brian> operator receives a new box, the box goes to a central place to have a
    brian> locally generated key pair and certificate installed, before going
    brian> to the warehouse for a later truck roll. I don't think we can
    brian> exclude that solution for a highly paranoid operator, who wants
    brian> absolutely no traffic about the enrollment to go outside. I think we
    brian> need to keep both options open.

    mcr> I don't see this as two options. It's one.

    mcr> All that you've said is that the operator did the initial imprinting
    mcr> in the warehouse rather than in the field.  If all boxes in the field
    mcr> have been imprinted in this way, then there are no additional trust
    mcr> issues.  If some have been installed this way, and some have not,
    mcr> perhaps there are bridge CAs needed to enable to the imprinted boxes
    mcr> to trust the "stock" machines.

    mcr> Why do you think that this is two ways?  Maybe I'm missing something.

    brian> I had understood that people were thinking of a mechanism whereby the
    brian> enrolment process would rely on a transaction with the manufacturer's
    brian> CA, i.e. communication outside the operator's own network, to validate
    brian> the device identity.

Yes, we are thinking of such thing.
I don't like the word "transaction" -- while I think it's correct, I think
that you are thinking about an "online transaction" (which is certainly
possible).

I'm thinking that it does not need to be online; there definitely was a
"transaction" though --- operator paid money to vendor, and vendor shipped
equipment, and along with that equipment would be some machine readable
(or machine retrievable) credential and/or certificate.  Could be a USB key
with a shared secret or a certificate chain, or a QR code containing same,
or a QR code containing a URL at which to retrieve the cert chain, or a
use-once token that will let the operators' CA get a certificate proving
ownership.

I think that we need to define what's in that proof-of-ownership certificate;
I don't think we need to invent anything for the transport of said
certificate, but we may want to say which of the 37 different ways to get a
certificate we think are MAY/SHOULD/MUST.

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Tue, 28 Oct 2014 10:57:39 +0000

Toerless summed it up nicely. 

Inside a domain (for example, an enterprise network), you want a single trust domain. The owner of that enterprise network wants all those devices under one trust anchor. (Of course he can create sub-domains, or several domains). 

Before they form part of a single domain, devices come from various vendors, or are imprinted in various ways. In that part there are many trust domains. As Brian points out, some domains will accept a call home functions, others will not. 

Bottom line: We need a process which gets devices from various origins and trust domains, and various ways to initialise them to a single trust domain, for example an enterprise network. draft-pritikin-bootstrapping-keyinfrastructures tries to explain what this process could look like. 

Michael

[typing this offline on a plane - apologies I don't respond to the latest message]

> -----Original Message-----
> From: Anima [mailto:[email-masked]] On Behalf Of Michael
> Richardson
> Sent: 27 October 2014 13:18
> To: Brian E Carpenter
> Cc: [email-masked]
> Subject: Re: [Anima] Homogeneous vs. heterogeneous trust domains (Re:
> What elements of IETF ANIMA can be used for I2NSF?)
> 
>

---

From: Michael Richardson <[email-masked]>
Date: Tue, 28 Oct 2014 10:53:11 -0400

> Inside a domain (for example, an enterprise network), you want a single
    > trust domain. The owner of that enterprise network wants all those
    > devices under one trust anchor. (Of course he can create sub-domains,
    > or several domains).

I think that we are all agreed on this.

    > Before they form part of a single domain, devices come from various
    > vendors, or are imprinted in various ways. In that part there are many
    > trust domains. As Brian points out, some domains will accept a call
    > home functions, others will not.

So, irrespective of whether there is a call-home part of the imprinting,
Brian's point was that some domains expect to the imprinting in the field,
and some prefer to do this in a virtual faraday cage.

I claim that there is doesn't matter where the initial imprinting occurs;
I think it's the same process.  All nodes should expect the potential for
their role to change after a power cycle/deep sleep.

    > Bottom line: We need a process which gets devices from various origins
    > and trust domains, and various ways to initialise them to a single
    > trust domain, for example an enterprise
    > network. draft-pritikin-bootstrapping-keyinfrastructures tries to
    > explain what this process could look like.

In other emails over the I've tried to fill in some details on such a
process, is it the time to recap that here?