[Anima] BRSKI-Cloud discussion (from private thread)

[Michael Richardson <[e-mail]>]

It was written privately that:
    > “A 406 (Not Acceptable) ... The registrar SHOULD use this response if
    > it determines
    > the pledge is unacceptable due to inventory control, MASA audit-logs,
    > or any other reason.
    > ”

    > Michael: Its not clear in draft-29, but I am reading into this that if
    > ownership tracking is supported, that if the wrong Local Registrar
    > (i.e. not the owner) requests a voucher for a pledge, the MASA should
    > return a 406 response code.

yes, that's what's expected.

In explaining BRSKI via animated slideware about how things work (yestesday),
it has occured to me that MASA ought to probably restrict or delay simultaneous
voucher-requests from different domainIDs if they have no sales-channel
integration.  (There is a youtube screencast)

There is otherwise a kind of race condition that could occur.

That allows one domainID to clearly claim the device, and proceed to
enrollment (or fail) before the other one makes an attempt.

Back to the Cloud-Registrar:

    > If we are using any of the other 3 options “Voucher Request Handled by
    > Cloud Registrar”, the local domain does not see the Voucher response at
    > all. Voucher Request/Response handling is all done by the Cloud
    > Registrar.

The response voucher needs to include a pinned-domain-cert linking to the
Local Registrar so that the 3xx redirect can validate the Local Registrar
correctly.

I think that we should have a discussion about option 2 (redirect at ENROLL)
vs option 3 (redirect via Voucher).  I'm not sure why we need both cases.

    > I think it looks like we need to do either

    > (i)               “Voucher Request Redirected to Local Domain
    > Registrar” where the cloud 3xxs the Voucher request and the Pledge
    > resends the Voucher Request via the local registrar (which you were
    > trying to avoid) OR

    > (ii)              “Voucher Request Handled by Cloud Registrar” option 2
    > or 3 *and* somehow get the pledge to include the Voucher in the EST
    > enrol API. This means that, similar to your flow in your slide, the
    > device has to treat the Voucher kind of like a Bearer token and include
    > the Voucher in the HTTP Authorization header of the EST enrol
    > request. So logically following on from that, it seems like it would
    > mean defining a new HTTP “Authorization: Voucher xxx” type, similar to
    > HTTP “Authorization: Bearer xxx”… Michael – have you ever considered
    > that scenario at all? A Voucher being used kinda like an OAuth Bearer
    > token..?

I don't think that I really understood the situation that waranteed it!
The question is whether the Local Registrar is an EST-only Registrar, or if
speaks BRSKI.

As an alternative to a new form of authentication, the Registrar, upon seeing
a client connect with an IDevID containing a serial number and a MASA URL,
could do a voucher-request to the MASA, and receive in response, the same
voucher that was issued to the Pledge.

As another alternative, the Voucher-Request POST that the Pledge does, could
be answered with a 201 Created and a Location: for the voucher object.  The
Pledge would retrieve it, and then, put that URL into a Referer: header field
on the POST.

Let's talk about the "3xx" responses.  From Wikipedia:

301 Moved Permanently
    This and all future requests should be directed to the given URI.

302 Found (Previously "Moved temporarily")
    Tells the client to look at (browse to) another URL. 302 has been superseded
    by 303 and 307. This is an example of industry practice contradicting the
    standard. The HTTP/1.0 specification (RFC 1945) required the client to
    perform a temporary redirect (the original describing phrase was "Moved
    Temporarily"),[22] but popular browsers implemented 302 with the
    functionality of a 303 See Other. Therefore, HTTP/1.1 added status codes 303
    and 307 to distinguish between the two behaviours.[23] However, some Web
    applications and frameworks use the 302 status code as if it were the
    303.

303 See Other (since HTTP/1.1)
    The response to the request can be found under another URI using the GET
    method. When received in response to a POST (or PUT/DELETE), the client
    should presume that the server has received the data and should issue a new
    GET request to the given URI.

304 Not Modified (RFC 7232)
    Indicates that the resource has not been modified since the version specified
    by the request headers If-Modified-Since or If-None-Match. In such case,
    there is no need to retransmit the resource since the client still has a
    previously-downloaded copy.[26]

305 Use Proxy (since HTTP/1.1)
    The requested resource is available only through a proxy, the address for
    which is provided in the response. For security reasons, many HTTP clients
    (such as Mozilla Firefox and Internet Explorer) do not obey this status
    code.[27]

306 Switch Proxy
    No longer used. Originally meant "Subsequent requests should use the
    specified proxy."[28]

307 Temporary Redirect (since HTTP/1.1)
    In this case, the request should be repeated with another URI; however,
    future requests should still use the original URI. In contrast to how 302 was
    historically implemented, the request method is not allowed to be changed
    when reissuing the original request. For example, a POST request should be
    repeated using another POST request.[29]


It seems that we should probably be answering the voucher-request POST with
307.

--
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-