Subject: [Anima] draft-pritikin-anima-bootstrapping-keyinfra-00

From: Brian E Carpenter <[email-masked]>
Date: Wed, 14 Jan 2015 13:59:14 +1300

Hi,

I finally found time to go through this draft...

Is there an accessible white paper or tutorial on IEEE 802.1AR?
http://standards.ieee.org/findstds/standard/802.1AR-2009.html
is behind a paywall and not particularly helpful as an
introductory document.

802.1AR-2009 is very specific that it applies to "IEEE 802
devices." What are the alternatives for other devices?

(nit) Is the list of definitions just after Figure 1
intended to be there, or in section 1.1 "Terminology"?
In any case there is a dangling sentence at the end of 1.1.

(nit) Please delete the noise word "cloud" wherever it occurs.

> Domain:  The set of entities that trust a common key infrastructure
>    trust anchor.

So, bootstrapping from power-off, how is the domain boundary
discovered? Can domains overlap, merge or split?

> Domain CA:  The domain Certification Authority (CA) optionally
>    provides certification...

I don't understand the "optionally". In what scenario do devices
in the domain *not* need to rely on the CA?

> Orchestrator:... In simple deployments this might be a
>    single administrator...

Surely in the *simplest* deployment there is no administrator?
Just plug-and-play. I think that means an extra case in
section 3.3  "Accepting New Entities". Something like
auto-detection of new devices followed by auto-registration
with some sort of validation step by Joe User:

-------------------------------------------------
| A new device has been detected on the network.|
| It says "Your new refrigerator is on-line".   |
| Please click [ACCEPT] within ten seconds to   |
| allow the device to connect.                  |
-------------------------------------------------

> 3.4.  Operating the Network
>
>   Once devices are enrolled to the domain, the network operator can
>   specify a policy, or otherwise configure the devices if required.
>   This is outside scope for this document.

It's worse than out of scope: it implies old-fashioned management,
not autonomic management. Personally I'd delete the section, but
if you keep it I'd say something like this:

   Once devices are enrolled to the domain, they may be managed
   by traditional centralized mechanisms or by autonomic methods.
   This is outside scope for this document.

> 4.1.  Behavior of a new entity
...
>     A.  Search for a Proxy on the local link using Neighbor
>         Discovery.

ND doesn't work for this, any more than ARP would. In the anima
context, I would suggest GDNP (but running in an insecure mode,
unfortunately).

>     B.  Obtain an IP address using DHCP,...

Oops. Firstly, for IPv6, the default way to get a non-link-local
address is SLAAC; you can't assume DHCPv6 is available.
Secondly, you need an address for step A anyway. You could use
a link-local address for step A, but if you get a proper address,
life gets easier, because you could rely on the GDNP diversion
mechanism.

And at that point: you don't need a proxy, because GDNP will
divert you directly to a registrar, so you don't need DNS(SD)
at all. So it all reduces to

     Use GDNP to discover a Registrar.

>  3.  Verify the MASA cloud service generated authorization token as
       provided by the contacted Registrar.

As far as I can see, you don't state anywhere what it means
to "verify" or "validate" the MASA authorization token.

More important, how will this work for disconnected networks?
(I've had to do a factory reset of my seismology truck in the middle
of the desert, and the satellite link is down, so the MASA is down.)

To be clear, I deeply dislike the dependency on an external service.
This is a weak point both in terms of reliability (for obvious
reasons) and vulnerability, because it creates a new and very
tempting target for attackers. A suborned MASA would be a very
wonderful thing: you would completely own all clients of that MASA
service.

It also creates a customer-capture opportunity, which is not
an IETF goal.

Why can't registrars do their own logging? (Trivial if there's
only one registrar per domain, of course.)

Regards
   Brian Carpenter

---

From: Sheng Jiang <[email-masked]>
Date: Mon, 19 Jan 2015 04:55:30 +0000

>with some sort of validation step by Joe User:

I fully agree that the basic scenario should be no administrator. The mechanisms/solutions with in ANIMA WG should ALL be autonomic or at least clearly towards autonomic. Depending on a human administrator does conflict with the concept of autonomic.

>   This is outside scope for this document.

+1

>     Use GDNP to discover a Registrar.

Adopting GDNP would be a good choice from the perspective of the WG recharter: we are working on reusable components and we are develop a generic protocol to support other autonomic requirements.

>of the desert, and the satellite link is down, so the MASA is down.)

Agree with Brian. If the MASA is the central of this solution, I am afraid this may be a broken deployment model. At least, there should be an alternative mechanism. One option could be the vendors could provide the relevant validation data to networks operators, then register can decide by itself.

One more issue is MASA requires protocol supports on how to exchange information and the format of information, which does not exist.

Best regards,

Sheng

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

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Mon, 19 Jan 2015 08:46:13 +0000

> -----Original Message-----
> From: Anima [mailto:[email-masked]] On Behalf Of Brian E
> Carpenter
> Sent: 14 January 2015 01:59
> To: [email-masked]
> Subject: [Anima] draft-pritikin-anima-bootstrapping-keyinfra-00
> 
> Hi,
> 

Thanks for that Brian! 
 
> is behind a paywall and not particularly helpful as an introductory
> document.
> 
> 802.1AR-2009 is very specific that it applies to "IEEE 802 devices." What are
> the alternatives for other devices?

I leave Max to comment here. 

> (nit) Is the list of definitions just after Figure 1 intended to be there, or in
> section 1.1 "Terminology"?

This is to some extent a question of taste ;-)   Which term would you propose we use? Let's agree on one here before we go back and forth ;-) 

> So, bootstrapping from power-off, how is the domain boundary discovered?

You need to define a trust anchor (implicitly or explicitly). Devices enrol at this trust anchor, one by one. Will be clearer in the text. 

> Can domains overlap, merge or split?

Yes. 
 
> I don't understand the "optionally". In what scenario do devices in the
> domain *not* need to rely on the CA?

devices can enrol directly at a CA or through an RA. Needs to be made clearer, I suppose.

> Just plug-and-play. I think that means an extra case in section 3.3
> "Accepting New Entities". Something like auto-detection of new devices
> followed by auto-registration with some sort of validation step by Joe User:
> 

Personally I believe that even in the simplest deployments there IS going to be an administrator. The text box you propose DOES require an administrator to click accept. Do we need to clarify what "administrator" means? To me, a homenet user for example who pushes a button is an administrator. To you? 

> It's worse than out of scope: it implies old-fashioned management, not
> autonomic management. Personally I'd delete the section, but if you keep it
> I'd say something like this:
> 

I don't see a strong difference between your text and ours?!? 

I thought we agreed that autonomics will come function by function into a network. In that case  (which I really thought we agreed on?) there is going to be traditional management in parallel for a long time. 

In any case, I'm happy with your proposed text, and will use that one. 

> ND doesn't work for this, any more than ARP would. In the anima context, I
> would suggest GDNP (but running in an insecure mode, unfortunately).

In this version of the document we didn't want to address which precise protocol is to be used. As we progress with the work in ANIMA, we'll put in whatever we agree upon. 

> Oops. Firstly, for IPv6, the default way to get a non-link-local address is
> SLAAC; you can't assume DHCPv6 is available.

An address can be obtained in several ways, you're right we need to be more generic. But DHCP (v6) is ONE of the options. 

> Secondly, you need an address for step A anyway. You could use a link-local
> address for step A, but if you get a proper address, life gets easier, because
> you could rely on the GDNP diversion mechanism.

The intention of this section is to explain how a new device bootstraps in various scenarios. A is implying link local only (we'll make it clearer), if that fails, use B, etc. 
 
> And at that point: you don't need a proxy, because GDNP will divert you
> directly to a registrar, so you don't need DNS(SD) at all. So it all reduces to
> 

We believe we need to support methods where the directly attached devices does not support the link local protocol. Cases B and C are meant for that. In an existing network this will be a requirement. Will make clearer in the text. 

> As far as I can see, you don't state anywhere what it means to "verify" or
> "validate" the MASA authorization token.

Will add. Basically, the MASA signs the message, and that is validated. 

> (I've had to do a factory reset of my seismology truck in the middle of the
> desert, and the satellite link is down, so the MASA is down.)

In that case, you pre-load authentication tokens at order time. Work. Will explain in more detail. 
 
> reasons) and vulnerability, because it creates a new and very tempting
> target for attackers. A suborned MASA would be a very wonderful thing: you
> would completely own all clients of that MASA service.

The MASA is optional. It adds an important benefit: With it, we can assure in a zero-touch environment that a new device will only join the intended network. This has tremendous value in some deployments. But as stated, it is optional. 
 
> It also creates a customer-capture opportunity, which is not an IETF goal.
> 
> Why can't registrars do their own logging? (Trivial if there's only one
> registrar per domain, of course.)

They can. What makes you ask that question?!? 

Brian, THANKs for this extensive review! It shows clearly that we need to explain better in quite a few places, thanks for that. Very valuable! 

Michael

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 20 Jan 2015 09:21:48 +1300

Hi Michael,

I am on a short holiday this week, so just respond below on
a couple of points:

> This is to some extent a question of taste ;-)   Which term would you propose we use? Let's agree on one here before we go back and forth ;-) 

I believe that "cloud" is really a marketing buzzword that will vanish
a few years from now. In most places it really doesn't add any information,
except that something is not in the local network. So I'm serious: delete
it. If the context requires it, state that the service is in the Internet.

> Personally I believe that even in the simplest deployments there IS going to be an administrator. The text box you propose DOES require an administrator to click accept. Do we need to clarify what…

Sure, but they are completely untrained. So they can only do very
simple things. So I think it's a third category, and the draft
only really describes two categories.

> I don't see a strong difference between your text and ours?!? 

Mine adds "autonomic".

Rgds
   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 27 Jan 2015 17:03:03 +1300

Back from holiday...

Actually apart from the points I mentioned in my previous message,
I'm happy with your explanations, Michael, except:

> The MASA is optional

That's good but I absolutely didn't pick it up while reading
the text. I think it needs to be stated more clearly and maybe
indicated in the diagram.

    Brian

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Tue, 27 Jan 2015 07:30:00 +0000

> > The MASA is optional
> 
> That's good but I absolutely didn't pick it up while reading the text. I think it
> needs to be stated more clearly and maybe indicated in the diagram.

Yes, this is difficult. In the overall approach there are many design options, and the number of options actually make the whole document confusing to read. We had many backs and forths on how to deal with all the options. So what we decided in the end was to do was to document the "optimal" case (in terms of security) first, and THEN document a list of "if you can't do x or don't have y, the impact is z". 

I still think this is probably the right approach, but (obviously) we need to explain that better. 

Would you agree with this approach? 

Michael

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 28 Jan 2015 07:55:17 +1300

> Would you agree with this approach? 

As long as it's clearly explained, sure. My sensitivity about the MASA is that
IMHO it has definite risks as well as advantages.

     Brian