Re: [Anima] Homogeneous vs. heterogeneous trust domains (Re: What elements of IETF ANIMA can be used for I2NSF?)

["Michael Behringer (mbehring)" <[e-mail]>]

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:[e-mail]] On Behalf Of Michael
> Richardson
> Sent: 27 October 2014 13:18
> To: Brian E Carpenter
> Cc: [e-mail]
> Subject: Re: [Anima] Homogeneous vs. heterogeneous trust domains (Re:
> What elements of IETF ANIMA can be used for I2NSF?)
> 
> 
> Brian E Carpenter <[e-mail]> wrote:
>     >> Toerless Eckert <[e-mail]> 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.
> 
>     > 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.
> 
> 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.
> 
> 
> 
> 
> 
> --
> Michael Richardson <[e-mail]>, Sandelman Software Works
> -= IPv6 IoT consulting =-
> 
>