Subject: [Anima-bootstrap] message flow notes from design team meeting Feb 4th

From: "Max Pritikin (pritikin)" <[email-masked]>
Date: Thu, 4 Feb 2016 16:30:34 +0000

Bootstrapping flow for anima-bootstrapping-keyinfra-02-pre01

                                             .+------------------------+
      +--------------Drop Ship-------------->.| Vendor Service         |
      |                                      .+------------------------+
      |                                      .| M anufacturer|         |
      |                                      .| A uthorized  |Ownership|
      |                                      .| S igning     |Tracker  |
      |                                      .| A uthority   |         |
      |                                      .+--------------+---------+
      |                                      ..............  ^
      V                                                      |
   +-------+     ............................................|...
   |       |     .                                           |  .
   |       |     .  +------------+       +-----------+       |  .
   |       |     .  |            |       |           |       |  .
   |       <---L2--->            |       |           <-------+  .
   |       |   or   |   Proxy    |       | Registrar |          .
   |       <---L3--->            <---L3-->           |          .
   | New   |     .  |            |       |           |          .
   | Entity|     .  +------------+       +-----+-----+          .
   |       |     .                             |                .
   |       |     .           +-----------------+----------+     .
   |       |     .           | Domain Certification       |     .
   |       |     .           | Authority                  |     .
   +-------+     .           | Management and etc         |     .
                 .           +----------------------------+     .
                 .                                              .
                 ................................................
                               "Domain" components

 +---------+        +----------+        +----------+        +-----------+
 |  New    |        |  Proxy   |        |          |        |  Vendor   |
 | Entity  |        |          |        |Registrar |        |  Service  |
 |         |        |          |        |          |        | (Internet)|
 +---------+        +----------+        +----------+        +-----------+

New entity boots in CLEAN STATE
RFC3927 IPv4 Link-Local Address
RFC4862 IPv6 Stateless Address Autoconfiguraion <— design for this

            -------->

RFC6763/RFC6762 mDNS query 
*or* 
ietf-anima-grasp-02 GRASP query
Include a paragraph explaining the choice to be made

“MAY” do this but is it not required. Include a paragraph outlining the tradeoff between speed vs exposing the new device.
This indicates to the network that this new entity is looking to bootstrap
It leaks some information to watchers that the new device is in CLEAN STATE

            <--------
“MUST” be broadcast periodically w/o query
RFC6763/RFC6762 mDNS broadcast
*or*
ietf-anima-grasp-02 GRASP broadcast 
non-query devices can wait to listen for these
this response/broadcast indicates the local proxy contact information 

(In this flow it is assumed a response/broadcast is seen by New Entity. If one is not the NE MAY continue to communicate with a well known cloud based AN proxy. This flow is not detailed here.) 

 +---------+         +----------+         +----------+ 
 | New     |-------->|  Proxy   |-------->|Registrar | 

(d)TLS established. 
This is to-be RFC7030 EST with a bootstrapping extension.
The New Entity authenticates with IEEE 802.1AR credentials
The Domain authenticates with current Domain credentials which the new entity *PROVISIONALLY* accepts.
Proxy behavior: discussed in draft-richardson-anima-state-for-joinrouter-00
	“The New Entity MUST use method 3
	The Registrar MUST support method 3”
	HTTP-Proxy method is used and domain MUST support ‘CONNECT’ which allows maximum flexibility in proxy implementations
	including: circuit proxy, napt66, http proxy, CoAP/DTLS with relay, HTTP with IPIP tunnel, CoAP/DTLS with IPIP tunnel
MCR to bring over the conclusion and justification but leave the analysis via reference to his draft.

                                           +----------+ 
                                           |          |  
                                           |Registrar |  
                                           |          |  
                                           +----------+  
				<Verify 802.1AR credential against white list?>

				Extract MASA server information from 802.1AR credential extensions 
				see: MUD extension.
				If they don’t exist the registrar needs to be configured appropriately

							OPTIONAL: MASA *or* NETCONF ownership voucher flow
                                           +----------+         +--------+ 
                                           |          |         |
                                           |Registrar |-------->| Vendor MASA
							HTTPS REST API *also defined EST extensions*
							The 802.1AR ID is forwarded (not proved)
							The Domain ID is forwarded 
							Short story: Signed proof of Registrar of unknown domain. Domain auth only for DoS protection.
								OPTIONAL: Verify Domain/NE pairing
								Log ownership claim
							Longer story:
								nonce based
								this exchange MAY occur out-of-band/prior to deployment (nonce-less)
								
                                           +----------+         +--------+ 
                                           |Registrar |<--------| Vendor MASA
								Return proof of logging
								Return audit log information
								OPTION: “ownership voucher” instead of log based

                                           +----------+ 
                                           |          |  
                                           |Registrar |  
                                           |          |  
                                           +----------+  
				<Verify logged information, still accept?>

 +---------+         +----------+         +----------+ 
 | New     |<--------|  Proxy   |<--------|Registrar | 

Log/ownership voucher information returned via EST extension
New Entity now checks the previously accepted *PROVISIONAL* domain certs 

<all ok?>

 +---------+         +----------+         +----------+ 
 | New     |-------->|  Proxy   |-------->|Registrar | 

Continue with off the shelf EST:
	request CA certs
		Move from provisional to authenticated EST, as defined is RFC7030
	request client cert
						<Registrar  acts as off the shelf RA> 
 +---------+         +----------+         +----------+ 
 | New     |<--------|  Proxy   |-------->|Registrar | 

LDevID installed on device

Now fire up (secured) GRASP and ACP

=========

CoAP support: 
	Describe how to use block transfer *draft* for EST. That would enable this use of EST to work over dTLS/CoAP.
	Do this as a new document. Potentially for anima or core working group? This would only work if the core document proceeds.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 5 Feb 2016 07:57:29 +1300

On 05/02/2016 05:30, Max Pritikin (pritikin) wrote:

...
> RFC4862 IPv6 Stateless Address Autoconfiguraion <— design for this

Note that you get an IPv6 link-local address even if there is no IPv6
router handing out a prefix for SLAAC, so you can always start operations.

> Include a paragraph explaining the choice to be made

Note that GRASP discovery intrinsically works on or off link, unlike mDNS.
(Supposedly, DNS-SD will fix this, one day.)

> this response/broadcast indicates the local proxy contact information 

GRASP Flood is your friend. Again, it intrinsically works on or off link. Running code,
if you want to progam in Python.

    Brian