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

"Max Pritikin (pritikin)" <> Tue, 18 October 2016 17:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 17AC0129706 for <>; Tue, 18 Oct 2016 10:45:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.952
X-Spam-Status: No, score=-14.952 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7a43F2Hxf6JD for <>; Tue, 18 Oct 2016 10:45:11 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1CF6412949A for <>; Tue, 18 Oct 2016 10:45:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=5166; q=dns/txt; s=iport; t=1476812710; x=1478022310; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=pfGUWrea0Zfc6eqdmI9QNFCUMpd02enolIWve8POEUQ=; b=d9B6IW6ynRpAeb8lmUJlnaKcNkIuHoiPlwG3BHHwBlLiEx1/uU8+9cob CmioehmO+5gi5ZaecmJQUpYSQ90Vsy28Kfm3d6OvuXGDfmps9QniihjLZ hK9kXsBVmeORLzHCmnTwiWBXd1+U7GwMF6XBfZHdhPkljN4YgC8aM4w/F 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.31,362,1473120000"; d="scan'208";a="158968035"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-SHA; 18 Oct 2016 17:45:10 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id u9IHjAAn018322 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 18 Oct 2016 17:45:10 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 18 Oct 2016 12:45:08 -0500
Received: from ([]) by ([]) with mapi id 15.00.1210.000; Tue, 18 Oct 2016 12:45:08 -0500
From: "Max Pritikin (pritikin)" <>
To: Michael Richardson <>
Thread-Topic: [Anima-bootstrap] section 5.1 -- redirection
Thread-Index: AQHSKHz22l7b3DIF90W6zIPNiD6lZ6CthoqAgAFD/ACAAAcNAA==
Date: Tue, 18 Oct 2016 17:45:08 +0000
Message-ID: <>
References: <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-ID: <>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
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:45:13 -0000

> On Oct 18, 2016, at 11:19 AM, Michael Richardson <> wrote:
> 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.

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 <>, Sandelman Software Works
> -= IPv6 IoT consulting =-