Re: [Anima-bootstrap] section 5.1 -- redirection

["Max Pritikin (pritikin)" <[e-mail]>]

> On Oct 18, 2016, at 11:19 AM, Michael Richardson <[e-mail]> wrote:
> 
> 
> Max Pritikin (pritikin) <[e-mail]> wrote:
>>> Max, I'm doing the minutes, and I'm trying to explain the confusion we
>>> had over the various objects by connecting to the real text, and I
>>> came across this.
>>> 
>>> Section 5.1 includes the text:
>>> 
>>> As indicated in EST [RFC7030] the bootstrapping server can redirect
>>> the client to an alternate server.  If the New Entity authenticated
>>> the Registrar using the well known URI method then the New Entity MUST
>>> follow the redirect automatically and authenticate the new Registrar
>>> against the redirect URI provided.  If the New Entity had not yet
>>> authenticated the Registrar because it was discovered and was not a
>>> known-to-be-valid URI then the new Registrar must be authenticated
>>> using one of the two autonomic methods described in this document.
>>> Similarly the Registar MAY respond with an HTTP 202 ("the request has
>>> been accepted for processing, but the processing has not been
>>> completed") as described in EST [RFC7030] section 4.2.3.
> 
>>> I'm trying to understand how/when the New Entity would authenticate
>>> the registrar using the well known URI.  Is this for some form of
>>> mitigation, where the new entity does not (can not) do all of the
>>> proxy steps and a human helps via craft console?  Or is this part of
>>> the rekey state machine?
> 
>> Including a well known URI as the final discovery attempt allows the
>> client state machine and code base to support a model where it is
>> booted on an unsecured (unknown) network where nothing local responds
>> to discovery attempts. This use case support any home or small-business
>> style device that might use a cloud management model.
> 
> Right, I recall this part now.
> Can I suggest the 5.1 text say:
> 
>          <t>When the New Entity has used a URI of last resort (described in
>          section 3.1.1, method (d)), then the New Entity MUST be ready to
>          accept a redirected from the bootstrap server to an alternate
>          server.  This is as per EST [RFC7030].
> 
>          Redirects are otherwise illegal, and MUST cause the New Entity to
>          start over, and select a different proxy.

I’d either move this to the end or move this to the beginning. Where it is it beaks the flow between the prior paragraph and the next paragraph. 

> 
>          This is most likely to occur when the vendor's registrar knows
>          the a more relevant local registrar for the client.  The client
>          will have authenticated the vendor's registrar using built-in trust
>          anchors, and therefore the redirect URI SHOULD be trusted.
> 
>          Since client authentication occurs
>          during the TLS handshake the bootstrapping server has sufficient
>          information to apply appropriate policy concerning which server to
>          redirect to.
> 
>          After the redirect, the client MUST proceed through the same
>          provisional state as before.</t>
> 
> 
> I also would like to give the four steps in section 3.1.1 Discovery
> names.  Perhaps it's enough to say "Discovery method (a)"?
> Except that these are not methods, but steps, two of which are MAY,
> so maybe the various connection methods need names.

I think “step (a)” would be clear enough. I’m not sure they need to be named (mostly because coming up with the names seems like a rathole w/o sufficient value). 

I’m happy with adding this type of clarifying text. 

- max

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