Subject: [6tisch-security] a different explanation of autonomic bootstrap

From: Michael Richardson <[email-masked]>
Date: Sat, 03 May 2014 15:32:00 -0400

(LookOut, AppleMail and web mail people will need a fixed font to understand this email.
Sorry, if you got pretty proportional wrapped emails, your program violated rfc5822...
Try viewing through the mailarchive link that is now in every email that goes through
ietf.org...)

I think that draft-pritikin-bootstrapping-keyinfrastructures needs to explain things a
bit differently.  I'm not sure if this represents significant "on-the-wire" changes
yet, or just details.

Michael: I'd like to go through this on Monday's call, and I will attempt to prepare
some slides to go with it. Maybe Max would be able to join us?
I also CC'ed Bob Moskovitz of Verizon Business, as he had indicated to me privately
that they were doing extensive use of 802.1AR certificates for deployment of
VoIP phones/systems.

Bob: if you should be available 10am EDT Monday (yeah, that would be first
thing for you, and you might not even read this), you might join our call,
details in next email, but I'll understand if you can not make it.

I think that I am making up something on the operator claiming side of
things; because the IEEE 802.1AR specification does not (unless I missed it)
say anything about how the device is claimed by the network (how it trusts
the network), only how the network trusts the device.  Perhaps there are some
specifications which I've missed, or perhaps some things which are simply unspecified.

I had copied the various steps out of pritikin-bootstrapping document with
the intention of making them more precise in the 6tisch security (creating a
profile), and then found that everything wound up in the first two steps, and
then noticed that there was "Claiming" way at the bottom!!

So clearly, I got something wrong!!!!

Let's start with the diagram mentioned above.
See another email about if we reverse who initiates the TLS.

I'm adding some letters to each arc so that they be mapped back to the steps,
which I show below.

I'm also going to have to add a whole bunch of details, because they matter here,
and I've made this very much (EAP-)TLS specific.  TLS does not send the ClientCertificate
until after the Server has sent it's certificate, which presentes a problem that
I'll explain below.

   +---------+                +----------+                +-----------+
   |  New    |                |          |                |  Factory  |
   | Entity  |                |  Domain  |                |   Cloud   |
   |         |                |          |                |  Service  |
   +---------+                +----------+                +-----------+
       |                           |                            |
       |<-------discovery-(A)----->|                            |
       |-----TLS ClientHello (B)-->|                            |
       |     (802.1AR cred)        |                            |
       |                           |---802.1AR identity(C)----->|
       |                           |---Domain ID--------------->|
       |                           |                    [device belongs]
       |                           |                    [to domain?    ]
       |                           |                            |
       |                           |<---device history log(D)---|
       |                    [ accept device? ]                  |
       |<------ServerHello-(E)-----|                            |
       |                           |------- claim device -(F)-->|
       |                           |                  [update audit log]
       |                           |<----- authz token --(G)----|
       |                           |      (802.1AR cert)        |
       |                           |                            |
       |                  [ still accept device?]               |
       |<----ServerCertificate-(H)-|                            |
       |                           |                            |
  [validate cert chain? (I)]       |                            |
       |                           |                            |
       |---ClientCertificate-(J)-->|                            |
       |                           |                            |
       |                           |                            |
       |----domain enrolment------>|                            |
       |<----domain certificate----|                            |

A  Proxy Discovery (A)
B  TLS ClientHello
   This part has to include two things which are not exactly common TLS.
   1) it must have a TrustedAuthorities (6066) indicating what it's Factor CA
   2) it must include its IDevID somewhere, TBD.

C  (optional) Query to Factory Cloud Service/MASA
D  (optional) reply with device history leading to accept device decision.
E  Domain Auth* server sends ServerHello
   (otherwise, if one does not accept the device, then one sends back
   an error message, which naturally could be forged, so the device
   really takes this a clue to back off a bit, listen some more,
   and try again later)
F  claim device.  The Domain Auth* may need to talk to a cloud
         service in order to get an appropriate certificate issued
         to it.  That also would update the audit log.
G  an appropriate certificate is issues to the Domain Auth*, that
   both identifies the domain owner, and binds the device to that
   domain owner.   This certificate could also be delivered by
   USB key, QR code, etc.
H  the certificate (chain) is sent as the ServerCertificate
   to the device.
I  the device validates the certificate chain.  The device
   has a trusted certificate store which contains the Factory
   CA certificate.  In addition, it has its per-device IDevID
   certificate signed by said Factory CA.

   The device can therefore validate a chain of certificates
   that start at the Vendor Factor CA, and may chain through
   multiple resellers, and finally end with a certificate
   permitting the Domain Owner to claim the device.  It is
   unclear what the subject of each of the certificates in
   the chain is, as each part must in fact list the IDevID
   being claimed.

J  the device, accepting the claim would respond with the
   next step in the TLS protocol, the ClientCertificate
   message, proving the device is in fact the IDevID it claimed
   to be.

Now, the bootstrap process then suggests that using the resulting
secure channel, that a certificate enrollment process (CET) be done.

I feel neither here nor there about that.

PRO:
  - It certainly would shorten then process of authenticating, and 802.1AR
    devices certainly are expected to be able to deal with that.
  - It permits all devices to have a common (short) root, such that
    adjacent devices could in fact authenticate each other easily.
    This very much matters to PCE-less 6top!

CON:
  - it seems like it is a whole chunk of additional infrastructure (operating
    a CA), and I'm afraid that it may scare many off.
  - I'm not sure that running CET over EAP-TLS is such a good idea, fragmentation
    wise.
  - it kinda implies that there may be a  lot more async operations
    during operation, and I think that a very long lived TLS Session Resumption Token,
    (rfc5077), stored into flash on the device is closer to what people
    expect to use.   Given that, one can resume the created TLS session,
    perhaps outside of the EAP-TLS.

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

---

From: Michael Richardson <[email-masked]>
Date: Sun, 04 May 2014 12:45:53 -0400

So I ask Google for:
   example of 802.1AR certificate

and the first three hits are my draft where I have an empty box.

---

From: Robert Moskowitz <[email-masked]>
Date: Sat, 03 May 2014 23:59:15 -0400

Quick response.

If I get a few reports written, I am available.  I have 3 calls monday 
afternoon.  I can't even read this until I get 3 more reports written (3 
down, 3 to go).  And one of them I am recommending 802.1AR as the 
deployment model.  It is NOT VoIP; it is big. Another is HIP's HITs and 
it is also big.  Each have their place in the scheme of things.  Another 
is totally 'off the wall', due to some interesting constraints and 
require some original thinking. ARGH!!!! :)

---

From: "Max Pritikin (pritikin)" <[email-masked]>
Date: Mon, 5 May 2014 18:10:47 +0000

> some slides to go with it. Maybe Max would be able to join us?

I’m sorry, I’m reading this now and its presumably after the call time. 

> specifications which I've missed, or perhaps some things which are simply unspecified.

That is not specified in 802.1AR which focusses on the device identity. 

> until after the Server has sent it's certificate, which presentes a problem that

Interesting that you are communicating to the Factory Cloud Service inline with the TLS handshake. In our discussions we would have imagined completing the TLS handshake and then communicating with the factory service. I see how this causes the difficulty you’re referencing below.

Discussion included inline but at a high level consider this flow as more closely matching my mental model: 

  +---------+                +----------+                +-----------+
  |  New    |                |          |                |  Factory  |
  | Entity  |                |  Domain  |                |   Cloud   |
  |         |                |          |                |  Service  |
  +---------+                +----------+                +-----------+
      |                           |                            |
      |<-------discovery-(A)----->|                            |
      |-----TLS ClientHello (B)-->|                            |
      |                           |                            |
      |<------ServerHello-(E)-----|                            |
      |<----ServerCertificate-(H)-|                            |
      |                           |                            |
 [validate cert chain? (I)]       |                            |
 [PROVISIONAL ACCEPT: Enter bootstrapping mode!]               |
      |                           |                            |
      |---ClientCertificate-(J)-->|                            |
      |   (802.1AR cred)          |                            |
      |                           |                            |
   [TLS handshake is run to completion]                        |
      |                           |                            |
      |---/BootstrapRequest------>|                            | 
      |                           |                            |
      |                           |---802.1AR identity(C)----->|
      |                           |---Domain ID--------------->|
      |                           |                    [device belongs]
      |                           |                    [to domain?    ]
      |                           |                    [PREFERRED: JUST LOG, NO DECISIONS]
      |                           |                            |
      |                           |<---device history log(D)---|
      |                    [ accept device? ]                  |
      |                           |------- claim device -(F)-->|
      |                           |                  [update audit log]
      |                           |<----- authz token --(G)----|
      |                           |      [SIGNED LOG ENTRY]    |
      |                           |                            |
      |                  [ still accept device?]               |
      |                           |                            |
      |<—[authz token]------------|                            |
  [validate token using factory root cert]
  [Join this domain?]             |                            |
      |                           |                            |
  [Initiate EST/RFC7030 on this TLS connection]                |
      |----domain enrolment------>|                            |
      |<----domain certificate----|                            |

In this fashion it is a “/BootstrapRequest” extension to RFC7030 Enrollment over Secure Transport. The basic message elements are all as you described but I’ve simply re-ordered them to better match the TLS and EST flows which minimizes the integration efforts. 

RFC6066 TrustedAuthority won’t help here because Domain is unlikely to have a useful certificate issued by the Factory Cloud Service.

Instead the New Entity would provisionally accept the TLS communications w/o being able to verify the Domain credential. It submits its IDevID in response (during ‘J’) but the entire session is still provisional. 

- max

---

From: Rene Struik <[email-masked]>
Date: Mon, 05 May 2014 15:07:59 -0400

Hi Max:

Some comments below.

Rene

On 5/5/2014 2:10 PM, Max Pritikin (pritikin) wrote:
[snip]
> |<----domain certificate----| | In this fashion it is a 
> “/BootstrapRequest” extension to RFC7030 Enrollment over Secure 
> Transport. The basic message elements are all as you described but 
> I’ve simply re-ordered them to better match the TLS and EST flows 
> which minimizes the integration efforts.
>>
RS>>
It may be undesirable to have provisional sessions, if only because of 
the amount of dangling state one has to keep and because of time-outs 
and nesting issues. Once some of the missing info that prevented proper 
authentication has been provided to the new entity and/or network 
representative, proper authenticated key agreement can be realized.
<<RS

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

---

From: "Max Pritikin (pritikin)" <[email-masked]>
Date: Mon, 5 May 2014 19:57:01 +0000

I understand the concern regarding "dangling state” but counter that this:
	* is on the client that initiated the connection (no scaling issues)
	* consistent with the current TLS handshake (no extensions)
	* consistent with common TLS APIs (easy to develop using off the shelf components)
	* does not persist across connections (there is no need to maintain state that spans TLS sessions)
	* minimal integration/modification of the TLS handshake minimizes potential difficulties with TLSv3 

Since bootstrapping is a limited occurrence, and all state is on the client anyway, I’d lean in that direction over a more optimized handshake. 

- max

On May 5, 2014, at 1:07 PM, Rene Struik <[email-masked]> wrote:

>> |<----domain certificate----| | In this fashion it is a “/BootstrapRequest” extension to RFC7030 Enrollment over Secure Transport. The basic message elements are all as you described but I’ve simply re-ordered them to better match the TLS and EST flows which minimizes the integration efforts.
>>> 
> It may be undesirable to have provisional sessions, if only because of the amount of dangling state one has to keep and because of time-outs and nesting issues. Once some of the missing info that prevented proper authentication has been provided to the new entity and/or network representative, proper authenticated key agreement can be realized.
> <<RS
> 
> --

---

From: Rene Struik <[email-masked]>
Date: Mon, 05 May 2014 16:18:31 -0400

Hi Max:

Perhaps, I am missing something here: in the picture, the network 
representative ("Domain") has a message exchange with the third party 
("Factory Cloud Service"), which can be viewed as a subroutine inside 
the TLS protocol. During this subroutine, the server has to maintain 
state and triggers lots of bandwidth consumption in the network, without 
having any cryptographic assurances on the new entity (it simply acts on 
a received string that seems to be an ar-certificate).

It would help to have a more complete picture of the TLS handshake in 
the ascii diagrams, including key confirmation messages ("finished" 
messages). I could then try and describe cryptographic and other 
relevant properties and compare with other options.

Best regards, Rene

---

From: "Max Pritikin (pritikin)" <[email-masked]>
Date: Mon, 5 May 2014 20:39:13 +0000

On May 5, 2014, at 2:18 PM, Rene Struik <[email-masked]> wrote:

> Hi Max:
> 
> Perhaps, I am missing something here: in the picture, the network representative ("Domain") has a message exchange with the third party ("Factory Cloud Service"), which can be viewed as a subroutine inside the TLS protocol. During this subroutine, the server has to maintain state and triggers lots of bandwidth consumption in the network, without having any cryptographic assurances on the new entity (it simply acts on a received string that seems to be an ar-certificate).
> 
> It would help to have a more complete picture of the TLS handshake in the ascii diagrams, including key confirmation messages ("finished" messages). I could then try and describe cryptographic and other relevant properties and compare with other options.

As shown below (in my simplified mental model diagram) the TLS handshake runs to completion (the Finished message etc) before any communication with the Cloud Service. Details aren’t included but they’re also just standard off-the-shelf TLS: 

  [TLS handshake is run to completion]   <------------------------------ TLS is established

At this point there is a TLS session between the New Entity and the Domain that is only *provisionally* authenticated. The Domain absolutely knows the identity of the new device (leveraging 802.1AR) but the New Entity is still waiting to see if this is the correct domain.

     |                           |                            |

This is an artifact of “domain enrollment” from below. Because I was an author of EST/RFC7030 I’m structuring this conversation around that protocol which is HTTPS based. Thus this expectation that the first data message is initiated by the client.

     |                           |                            |
     |                           |---Domain ID [nonce]------->|

This entire sequence occurs while the TLS connection is held open. You are correct that the server has to maintain the TLS session and HTTPS session during this. Notice though that the New Entity isn’t involved in this exchange and only the Domain ID (and optionally a nonce) are sent to the server. Therefore in an environment where scalability is a greater concern these operations can occur in advance (assuming the device IDs are known out-of-band, such as via bill-of-sale integration). There is a cost to this scalability which is losing the nonce information but that choice is made by the Domain and captured in the Cloud logs. 

     |                           |                            |

This portion then is the authz response (which may be nonce-less) and basic enrollment mechanism. Again shown here as being EST/RFC7030 HTTPS messages. 

- max

---

From: Michael Richardson <[email-masked]>
Date: Fri, 16 May 2014 14:30:25 -0400

Michael Richardson wrote:
    mcr> I think that I am making up something on the operator claiming side of
    mcr> things; because the IEEE 802.1AR specification does not (unless I
    mcr> missed it)
    mcr> say anything about how the device is claimed by the network (how it
    mcr> trusts
    mcr> the network), only how the network trusts the device.  Perhaps there
    mcr> are some
    mcr> specifications which I've missed, or perhaps some things which are
    mcr> simply unspecified.

    > That is not specified in 802.1AR which focusses on the device identity.

So, the good news is that we don't need to read and profile another
specification.  The bad news is that we need to make something up....
I'm hoping that Bob Moskowitz might have something.... Bob, would it be worth
involving someone from a vendor of the phones that are involved?  Part of
this model was first described by Cullen Jennings... if that vendor is
involved...

    mcr> I'll explain below.

    > Interesting that you are communicating to the Factory Cloud Service
    > inline with the TLS handshake. In our discussions we would have
    > imagined completing the TLS handshake and then communicating with the
    > factory service. I see how this causes the difficulty you’re
    > referencing below.

Good that you see that in particular, in order for the device to complete
it's TLS certificate validation, the domain may need to use a different
certificate.  You are proposing that the one could complete the handshake
first, and then there is an interaction with the factory.   How does
this work in offline mode, or when the factory has gone out of business?
(Pulled a Nortel)

    > In this fashion it is a “/BootstrapRequest” extension to RFC7030
    > Enrollment over Secure Transport. The basic message elements are all as
    > you described but I’ve simply re-ordered them to better match the TLS
    > and EST flows which minimizes the integration efforts.

Is there some precedent on how the signed authz token looks?
I assume that it must bind the domain identity and the DeviceID.

    > RFC6066 TrustedAuthority won’t help here because Domain is unlikely to
    > have a useful certificate issued by the Factory Cloud Service.

okay.  I though that this was the point of the authz token.

    > Instead the New Entity would provisionally accept the TLS
    > communications w/o being able to verify the Domain credential. It
    > submits its IDevID in response (during ‘J’) but the entire session is
    > still provisional.

In another email people complained about having open dangling TLS sessions.
I agree with your analysis that the constrained device is in charge of the
situation, and it needs to maintain at most one such session, but it does
need to remember (and blacklist for a period of time) peers which offer it
networks but which can not validate themselves after a period of time.

That period of time might need to be long: enough days to survive reasonable
business processes.  Enough the service might be up, the authorizations might
not catch up until someone in accounts payable returns to work.  On the other
hand, should another offer come along the mote might be wiser to try that
network out.

---

From: "Max Pritikin (pritikin)" <[email-masked]>
Date: Mon, 19 May 2014 15:15:12 +0000

Conversation continued inline for context.  

> this work in offline mode, or when the factory has gone out of business?

The communication channel between the Domain and the Factory does not require the New Entity to cryptographically identify itself, therefore offline New Entities are supported. 
The messages from the Factory are store-and-forward (e.g. signed) so they can be obtained in advanced and presented once the New Entity/Domain communication is established. 
Nonceless signed replies from the Factory never expire, so they can persist beyond factories going out of business. 
If there are a large number of New Entities in the world then the Factory keys have value and perhaps that service could be spun off? A consortium approach could insulate one particular factory from an individual business. (As long as the consortium stays alive. See discussion below about Certificate Transparency).
Ultimately though if the Factory option totally goes away then physical possession of a device is sufficient to take ownership of it. What you can’t do is remotely claim ownership of it (zero touch provisioning).

> I assume that it must bind the domain identity and the DeviceID.

In my prototype I build the Factory response like so:

# build response
# It contains:
#	Device Identity
#	Hash of the Domain root key
# 	The client nonce (if provided)
TMP_RESP="$(mktemp)"
echo $UDI > $TMP_RESP
echo $DOMAINHASH >> $TMP_RESP
echo $CLIENTNONCE >> $TMP_RESP

# use smime to sign response using the Factory Key
# Here called a “Manufacturing Authorized Signing Authority (MASA)” key
$OPENSSLCMD smime -sign -in $TMP_RESP -aes128 -signer $MASA_DBDIR/masacrtandkey.pem -out $TMP_RESP.smime -nodetach

My current thinking would be to move this more toward leveraging a Merkle Hash Tree similar to the methods proposed by Google for their Certificate Transparency work as described in RFC6962. Effectively what we’re looking for here is very similar — we’re building a transparent log of the event (here "binding a device identity to a domain hash" rather than the issuance of a certificate which is the "binding of a principle name to key”). 

> networks but which can not validate themselves after a period of time.

agreed.

> hand, should another offer come along the mote might be wiser to try that

An interesting point. I haven’t thought enough about how the device behaves if its left hanging for a long period of time.

- max 

> _______________________________________________
> 6tisch-security mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tisch-security

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Tue, 20 May 2014 14:51:03 +0000

> -----Original Message-----
> From: Max Pritikin (pritikin)
> Sent: 05 May 2014 22:39
> To: Rene Struik
> Cc: Michael Richardson; Robert Moskowitz; Michael Behringer (mbehring);
> tisch-security
> Subject: Re: [6tisch-security] a different explanation of autonomic bootstrap
> 
> 
> 
> 
> 
> ("Factory Cloud Service"), which can be viewed as a subroutine inside the
> TLS protocol. During this subroutine, the server has to maintain state and
> triggers lots of bandwidth consumption in the network, without having any
> cryptographic assurances on the new entity (it simply acts on a received
> string that seems to be an ar-certificate).
> >
> > It would help to have a more complete picture of the TLS handshake in the
> ascii diagrams, including key confirmation messages ("finished" messages).
> I could then try and describe cryptographic and other relevant properties
> and compare with other options.
> 
> As shown below (in my simplified mental model diagram) the TLS
> handshake runs to completion (the Finished message etc) before any
> communication with the Cloud Service. Details aren't included but they're
> also just standard off-the-shelf TLS:
> 
> 
> At this point there is a TLS session between the New Entity and the Domain
> that is only *provisionally* authenticated. The Domain absolutely knows
> the identity of the new device (leveraging 802.1AR) but the New Entity is
> still waiting to see if this is the correct domain.
> 
>      |                           |                            |
> This is an artifact of "domain enrollment" from below. Because I was an
> author of EST/RFC7030 I'm structuring this conversation around that protocol
> which is HTTPS based. Thus this expectation that the first data message is
> initiated by the client.
> 
>      |                           |                            |
> This entire sequence occurs while the TLS connection is held open. You are
> correct that the server has to maintain the TLS session and HTTPS session
> during this. Notice though that the New Entity isn't involved in this
> exchange and only the Domain ID (and optionally a nonce) are sent to the
> server. Therefore in an environment where scalability is a greater concern
> these operations can occur in advance (assuming the device IDs are known
> out-of-band, such as via bill-of-sale integration). There is a cost to this
> scalability which is losing the nonce information but that choice is made by
> the Domain and captured in the Cloud logs.
> 
> 
>      |                           |                            |
>      |<-[authz token]------------|                            |
> This portion then is the authz response (which may be nonce-less) and basic
> enrollment mechanism. Again shown here as being EST/RFC7030 HTTPS
> messages.
> 
> - max
> 
> 
> >
> > Best regards, Rene
> >
> >
> >
> >> I understand the concern regarding "dangling state" but counter that this:
> >> Since bootstrapping is a limited occurrence, and all state is on the client
> anyway, I'd lean in that direction over a more optimized handshake.
> >>
> >> - max
> >>
> >>
> "/BootstrapRequest" extension to RFC7030 Enrollment over Secure
> Transport. The basic message elements are all as you described but I've
> simply re-ordered them to better match the TLS and EST flows which
> minimizes the integration efforts.
> >>>> RFC6066 TrustedAuthority won't help here because Domain is unlikely
> to have a useful certificate issued by the Factory Cloud Service.
> >>>>
> communications w/o being able to verify the Domain credential. It submits
> its IDevID in response (during 'J') but the entire session is still provisional.
> >>>>
> >>> RS>>
> the amount of dangling state one has to keep and because of time-outs and
> nesting issues. Once some of the missing info that prevented proper

---

From: Michael Richardson <[email-masked]>
Date: Mon, 26 May 2014 22:46:44 -0400

This is a change to the time sequence diagram that I posted a few weeks ago,
this time looking at the details if the secure connection is initiated from
the Authorization Server/Domain Owner (PCE).  This is the more about the
"WirelessHART" way, because it uses the same application layer protocol to
do the security as the application uses.  There is also some consistency with
the ideas in the OSCAR paper.

The interesting thing about doing it this way is that it changes which
end is the client and which is the server, and this may have significant
advantages from a TLS point of view.

The process would be initiated by the NewEntity sending an ND ARO.
There is a new document posted since I started writing this email:
  https://datatracker.ietf.org/doc/draft-sarikaya-ace-cga-nd/

which is rather useful, because if Behcet hadn't written that, I'd have to.
(Noting that Hosnieh Rafiee has some concerns about CGA, and also there have
been IPR issues with CGA, which I've never looked into myself).

If the LSEND ARO additionally contains the IDevID, ideally under LSEND
signature, then the Domain can consider if that IDevID belongs on the
network.  A DTLS session could be started using certificates
like have been described in previous messages, and a 6top control would
be used to update the L2 key, and/or set a MSK per the piro document.

The biggest challenge is figuring out whether end-to-end addressing and
routing is used to reach the new 6LN, or if a proxy/relay method is used
to some adjacent 6LN.    The EAP-TLS diagram implicitely had such a proxy
as PANA/1x goes from supplicant to neighbouring authenticator.

I also posted a really rough document:
    draft-richardson-6tisch-idevid-cert-00
which is cribbed directly from RFC3779.

   +---------+                +----------+                +-----------+
   |  New    |                |          |                |  Factory  |
   | Entity  |                |  Domain  |                |   Cloud   |
   |         |                |          |                |  Service  |
   +---------+                +----------+                +-----------+
       |                           |                            |
       |<-------RA-----------------|                            |
       |-------- LSEND ARO ------->|                            |
       |                           |---802.1AR identity( )----->|
       |                           |---Domain ID--------------->|
       |                           |                    [device belongs]
       |                           |                    [to domain?    ]
       |                           |                            |
       |                           |<---device history log( )---|
       |<-------- LSEND ARO -------|                            |
       |                           |------- claim device -( )-->|
       |                           |                  [update audit log]
       |                           |<----- authz token --( )----|
       |                           |      (802.1AR cert chain)  |
       |                           |                            |
       |                    [ accept device? ]                  |
       |<----DTLS ClientHello ( )--|                            |
       |-------ServerHello-( )---->|                            |
       |<----DTLS ClientCert  ( )--|                            |
       |  (IDevId Credential chain |                            |
       |-----DTLS ServerCert  ( )->|                            |
       |  (802.1AR certificate)    |                            |
       |                           |                            |
       |<----6top commands       --|                            |
       |                           |                            |

One advantage is that the Domain is control of which devices are enrolled,
and what rate.  New Entities that are waiting for their turn simply wind
up sending AROs to renew.
A second possible advantage is that the "clear" RAs could contain a different
ABRO than the secure RAs, so join traffic could go through the network in a
different way.

A downside is that the 6LR which advertises to the joining node need to deal
with what's going on; potentially the new node could be in a different
prefix, etc..

This process could also lead into EST, but it doesn't have to.
Or we could map the 802.1AR APIs into 6top API.