Subject: Re: [Anima] I-D Action: draft-pritikin-anima-bootstrapping-keyinfra-02.txt

From: Brian E Carpenter <[email-masked]>
Date: Wed, 15 Jul 2015 14:37:01 +1200

Hi,

This draft is much more complete and easier to understand than the previous
version, thanks.

I do have one important comment. Like it or not, there will be enterprise
users who insist on a security air gap. Also, to me it seems an essential
requirement that an AN can bootstrap itself with no Internet connection,
for a variety of possible reasons and scenarios. You might need to boot
your emergency services network after a disaster, for example. "Cannot
connect to masa.example.com" is not acceptable in that case.

But you took out a vital sentence since the -01 draft:

> The MASA	 		
> is not a mandatory component, but it enables the new device to	 		
> validate which domain it is joining.

We need to restore that, and explain (with security considerations, of
course) how to bootstrap with no MASA.

(I could imagine that such a network would have to manually register
an Intent server and then distribute Intent saying "There is no MASA".
Yes, there are security exposures there. But I don't think we can duck
it.)

> 3.1.  Behavior of a new entity
...
>        B.  Obtain an IP address using existing methods, such as SLAAC or
>            DHCPv6, and search for a local registrar using DNS service
>            discovery.

It's inappropriate to specify DNS-SD. There may be multiple legitimate
ways to discover the registrar.

> 3.1.1.  Discovery and Identity
...
>    [[EDNOTE: it is unclear yet if discovery happens on a per interface
>    basis or once per device.

Isn't that settled by the scope of an 802.1AR cert? Surely that's defined
somewhere?

>    ...What is the requirement around joining
>    multiple domains; is this a bootstrapping requirement or is this a
>    broader autonomic requirement]]

I seem to think we settled on joining one domain (which might be
a sub-domain) and then doing some sort of cross-certification to
get authenticated and authorized in another domain. If so, it isn't
a bootstrap requirement.

> 5.  Protocol Details
> 
>    For simplicity the bootstrapping protocol is described as extensions
>    to EST [RFC7030].

We need to discuss that. You're assuming that all AN nodes will contain
HTTP machinery and JSON machinery. Is that a safe assumption for constrained
AN nodes?

What is the advantage of HTTP compared with naked TLS, again in the context
of constrained nodes?

(These questions are also interesting in the Anima signaling context, too;
it would be good to end up with a shared set of assumptions.)

Regards
   Brian

---

From: "Max Pritikin (pritikin)" <[email-masked]>
Date: Sun, 19 Jul 2015 22:41:33 +0000

> Yes, there are security exposures there. But I don't think we can duck

I can’t think of any way to allow the devices to blow off security w/o invalidating the security in all use cases. The text of s6.1 details touch based methods to enable this. Also keep in mind that permanent claims (or long ‘ownership vouchers’) allow the local network to cache all the needed information. 

I’m open to suggestions of other way to handle this. 

> ways to discover the registrar.

I’d added an ednote to the git repository to address this. 

> Isn't that settled by the scope of an 802.1AR cert? Surely that's defined

No, this is about how we do discovery. For example perhaps only one interface has access to the local infrastructure. I suspect we need to do discovery on all interfaces. 

> get authenticated and authorized in another domain. If so, it isn't

I’ll buy that. Added a note to the git repository. 

> it would be good to end up with a shared set of assumptions.)

I agree this will probably switch to anima signaling context. 

- max

> 
> Regards
>   Brian
> 
> _______________________________________________
> Anima mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 20 Jul 2015 18:46:30 +1200

Max,
On 20/07/2015 10:41, Max Pritikin (pritikin) wrote:
> I can’t think of any way to allow the devices to blow off security w/o invalidating the security in all use cases. 

Indeed. I am not suggesting that. I am requesting that the draft does not
make it seem as though you can only boot securely with use of a MASA.

> The text of s6.1 details touch based methods to enable this. 

Yes. So don't make that look like an obscure path that nobody will
follow. I believe it will be quite common. (And yes, it increases
OPEX; networks that want an air gap had better understand that this is
expensive.)

> Also keep in mind that permanent claims (or long ‘ownership vouchers’) allow the local network to cache all the needed information. 

Right, although I'm not sure how that will work in, for example,
a tactical military network where the cache has been physically destroyed.

> I’m open to suggestions of other way to handle this.

I think it's more a matter of document structure than anything else.

   Brian

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Fri, 24 Jul 2015 13:19:28 +0000

> -----Original Message-----
> From: Brian E Carpenter [mailto:[email-masked]]
> Sent: 20 July 2015 08:47
> To: Max Pritikin (pritikin)
> Cc: [email-masked]; Anima WG
> Subject: Re: [Anima] I-D Action: draft-pritikin-anima-bootstrapping-
> keyinfra-02.txt
> 
> Max,
> >> This draft is much more complete and easier to understand than the
> >> previous version, thanks.
> >>
> >> I do have one important comment. Like it or not, there will be
> >> enterprise users who insist on a security air gap. Also, to me it
> >> seems an essential requirement that an AN can bootstrap itself with
> >> no Internet connection, for a variety of possible reasons and
> >> scenarios. You might need to boot your emergency services network
> >> after a disaster, for example. "Cannot connect to masa.example.com" is
> not acceptable in that case.
> >>
> > I can’t think of any way to allow the devices to blow off security w/o
> invalidating the security in all use cases.
> 
> Yes. So don't make that look like an obscure path that nobody will follow. I
> believe it will be quite common. (And yes, it increases OPEX; networks that
> want an air gap had better understand that this is
> expensive.)
> 
> > Also keep in mind that permanent claims (or long ‘ownership vouchers’)
> allow the local network to cache all the needed information.
> 
> Right, although I'm not sure how that will work in, for example, a tactical
> military network where the cache has been physically destroyed.
> 

Brian, there is a reason why we have structured the document in this way: There are actually many moving bits and pieces, and options which have an impact on security. We did not find a way to handle all of those in a coherent way without losing the overall message and overview. Thus the decision was made to describe the most secure model as a starting point then all alternatives. 

I still think this is the right approach. But maybe we can have some text in the main section that is a bit more explicit about this single case. 

Michael

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 25 Jul 2015 02:38:01 +1200

Front posting because I think you have hit the answer:

> But maybe we can have some text in the main section that is a bit more explicit about this single case. 

Yes, I think a few sentences at the front could fix it. Actually, there are two
related cases that need to be described: an operator who absolutely refuses
to have an Internet connection, and a network that is knocked off the
Internet by a catastrophic event but needs to boot some nodes.

Regards
   Brian

---

From: "Jason Coleman (colemaj)" <[email-masked]>
Date: Fri, 24 Jul 2015 15:00:15 +0000

I am in agreement with Brian that we need to have some discussion point, at least a reference about the security.
We talked a bit this week about the ability to use a proxy for the MASA service.

Does that proxy need to be connected to the Internet at all times, or could it perhaps cache information that is required on a recurring basis?
This may or may not solve all of the use cases that Brian is talking about, but would provide an alternative that may be in the middle between full MASA access and no access that results in permanent ownership which has longer term implications for some companies.

-- 
Jason Coleman

---

From: "Max Pritikin (pritikin)" <[email-masked]>
Date: Fri, 24 Jul 2015 22:02:31 +0000

Brian’s requests were re-enforced by some concerns Russ Housely had when I met with him this week as well. I agree we’ll need to face this head-on even while we’re very clear about the costs. 

- max