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

From: Michael Richardson <[email-masked]>
Date: Mon, 17 Oct 2016 09:47:04 -0400

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?

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

---

From: "Max Pritikin (pritikin)" <[email-masked]>
Date: Mon, 17 Oct 2016 22:00:19 +0000

> On Oct 17, 2016, at 7:47 AM, Michael Richardson <[email-masked]> wrote:
> 
> 

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. 

The redirect is an implied case by using HTTP and, for EST, we were asked to indicate what the appropriate behavior would be. Here the same idea applies *plus* note that this allows an inversion of the proxy model for the above use case. The device reaches out to a cloud service first and gets redirected to a local service. 

- max

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

---

From: Michael Richardson <[email-masked]>
Date: Tue, 18 Oct 2016 13:19:54 -0400

Max Pritikin (pritikin) <[email-masked]> 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.
    >>
    >> 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.

          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.

---

From: "Max Pritikin (pritikin)" <[email-masked]>
Date: Tue, 18 Oct 2016 17:45:08 +0000

> On Oct 18, 2016, at 11:19 AM, Michael Richardson <[email-masked]> wrote:
> 
> 

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. 

> 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