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

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

Return-Path: <pritikin@cisco.com>
X-Original-To: anima-bootstrap@ietfa.amsl.com
Delivered-To: anima-bootstrap@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17AC0129706 for <anima-bootstrap@ietfa.amsl.com>; Tue, 18 Oct 2016 10:45:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.952
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7a43F2Hxf6JD for <anima-bootstrap@ietfa.amsl.com>; Tue, 18 Oct 2016 10:45:11 -0700 (PDT)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CF6412949A for <anima-bootstrap@ietf.org>; Tue, 18 Oct 2016 10:45:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; 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-Anti-Spam-Result: =?us-ascii?q?A0CBAQBPXgZY/4sNJK1cGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgzwBAQEBAR1XfAeNLZcFlDiCCIJrgzYCGoFpOBQBAgEBAQEBAQFiJ4R?= =?us-ascii?q?hAQEBAwEjEUUFCwIBCBgCAiYCAgIwFRACBA4FiEoItjmMdQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAR2BB4czgliEMRaDBCyCLwWaCAGQBY93jHuDfwEeNlSEdXKHGYE?= =?us-ascii?q?AAQEB?=
X-IronPort-AV: E=Sophos;i="5.31,362,1473120000"; d="scan'208";a="158968035"
Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 18 Oct 2016 17:45:10 +0000
Received: from XCH-RCD-014.cisco.com (xch-rcd-014.cisco.com [173.37.102.24]) by alln-core-6.cisco.com (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 xch-aln-013.cisco.com (173.36.7.23) by XCH-RCD-014.cisco.com (173.37.102.24) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 18 Oct 2016 12:45:08 -0500
Received: from xch-aln-013.cisco.com ([173.36.7.23]) by XCH-ALN-013.cisco.com ([173.36.7.23]) with mapi id 15.00.1210.000; Tue, 18 Oct 2016 12:45:08 -0500
From: "Max Pritikin (pritikin)" <pritikin@cisco.com>
To: Michael Richardson <mcr+ietf@sandelman.ca>
Thread-Topic: [Anima-bootstrap] section 5.1 -- redirection
Thread-Index: AQHSKHz22l7b3DIF90W6zIPNiD6lZ6CthoqAgAFD/ACAAAcNAA==
Date: Tue, 18 Oct 2016 17:45:08 +0000
Message-ID: <15AFB6C8-A09B-4FFB-BE8A-165B701551CF@cisco.com>
References: <7868.1476712024@obiwan.sandelman.ca> <3F4BBD96-9E80-46DF-9E65-2A2DD9404138@cisco.com> <26843.1476811194@obiwan.sandelman.ca>
In-Reply-To: <26843.1476811194@obiwan.sandelman.ca>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.99.106.9]
Content-Type: text/plain; charset="utf-8"
Content-ID: <D9CEF27F071BC1479BEB2AEC6A96165E@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima-bootstrap/3keYyGt1ad0vAqK_JUt83J50ux0>
Cc: anima-bootstrap <anima-bootstrap@ietf.org>
Subject: Re: [Anima-bootstrap] section 5.1 -- redirection
X-BeenThere: anima-bootstrap@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list for the bootstrap design team of the ANIMA WG <anima-bootstrap.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/anima-bootstrap>, <mailto:anima-bootstrap-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/anima-bootstrap/>
List-Post: <mailto:anima-bootstrap@ietf.org>
List-Help: <mailto:anima-bootstrap-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/anima-bootstrap>, <mailto:anima-bootstrap-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 18 Oct 2016 17:45:13 -0000

> On Oct 18, 2016, at 11:19 AM, Michael Richardson <mcr+ietf@sandelman.ca> wrote:
> 
> 
> Max Pritikin (pritikin) <pritikin@cisco.com> 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 <mcr+IETF@sandelman.ca>ca>, Sandelman Software Works
> -= IPv6 IoT consulting =-
> 
> 
>