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

Michael Richardson <> Tue, 18 October 2016 17:19 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 215531296B8 for <>; Tue, 18 Oct 2016 10:19:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.332
X-Spam-Status: No, score=-2.332 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id tLPttNRISPjA for <>; Tue, 18 Oct 2016 10:19:56 -0700 (PDT)
Received: from ( [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id F139D129417 for <>; Tue, 18 Oct 2016 10:19:55 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 104722009E; Tue, 18 Oct 2016 13:34:30 -0400 (EDT)
Received: from (localhost [IPv6:::1]) by (Postfix) with ESMTP id 4C95063AFE; Tue, 18 Oct 2016 13:19:54 -0400 (EDT)
From: Michael Richardson <>
To: "Max Pritikin (pritikin)" <>
In-Reply-To: <>
References: <> <>
X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha1"; protocol="application/pgp-signature"
Date: Tue, 18 Oct 2016 13:19:54 -0400
Message-ID: <>
Archived-At: <>
Cc: anima-bootstrap <>
Subject: Re: [Anima-bootstrap] section 5.1 -- redirection
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list for the bootstrap design team of the ANIMA WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 18 Oct 2016 17:19:58 -0000

Max Pritikin (pritikin) <> 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.

          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.

Michael Richardson <>, Sandelman Software Works
 -= IPv6 IoT consulting =-