Re: [Anima] chain of redirections for Cloud Registrar
Michael Richardson <mcr+ietf@sandelman.ca> Sun, 13 June 2021 02:32 UTC
Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: anima@ietfa.amsl.com
Delivered-To: anima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 661603A2B97 for <anima@ietfa.amsl.com>; Sat, 12 Jun 2021 19:32:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 wlThk56KqSry for <anima@ietfa.amsl.com>; Sat, 12 Jun 2021 19:32:26 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1139B3A2B94 for <anima@ietf.org>; Sat, 12 Jun 2021 19:32:25 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 7B69138B19; Sat, 12 Jun 2021 22:33:25 -0400 (EDT)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id IyY8S8Cncw2C; Sat, 12 Jun 2021 22:33:21 -0400 (EDT)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 686F138B17; Sat, 12 Jun 2021 22:33:21 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 9693878B; Sat, 12 Jun 2021 22:32:20 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: anima@ietf.org, max pritikin <pritikin@cisco.com>
In-Reply-To: <6572.1623550948@localhost>
References: <6572.1623550948@localhost>
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.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-sha512"; protocol="application/pgp-signature"
Date: Sat, 12 Jun 2021 22:32:20 -0400
Message-ID: <9152.1623551540@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/BCqSZcgm1YxQebHXToELKYegesc>
Subject: Re: [Anima] chain of redirections for Cloud Registrar
X-BeenThere: anima@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Autonomic Networking Integrated Model and Approach <anima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/anima>, <mailto:anima-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/anima/>
List-Post: <mailto:anima@ietf.org>
List-Help: <mailto:anima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/anima>, <mailto:anima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 13 Jun 2021 02:32:29 -0000
Michael Richardson <mcr+ietf@sandelman.ca> wrote: > We support two methods of redirect: 307 redirect and voucher based redirect. > The first method allows a Pledge to find a BRSKI capable Registrar at which > it starts the normal voucher-request/voucher process. > The second method allows the Cloud Registrar to process a voucher request > and then redirect the Pledge to an EST-only capable Registration Authority. > The questions are two: > 1) do we allow multiple layers of 307 redirect? This can be pretty powerful > as it allows a manufacturer to just know which regional distributor they > resold to, and the distributor knows which VAR, etc. > If so, I guess we need to establish some limit to how many redirects we allow. > BRSKI says some things at section 5.6 about limiting redirects to one. > My opinion is that this restriction should not apply. There is a second problem which I just thought about. Let me past in the sequence diagram: | | | 1. Mutual-authenticated TLS | |<----------------------------------------------->| | | | 2. Voucher Request | |------------------------------------------------>| | | | 3. 307 Location: owner-ra.example.com | |<------------------------------------------------| | 4. Provisional TLS | | |<-------------------->| | The first TLS connection (1) is to a burnt-in destination. RFC6125 DNS-ID validatio may be done against an Implicit TA database must be used to validate the server certificate. After step 3, the Pledge does not know if it should start a Provisional TLS connection to the intended Registrar (which would not be verified by Implicit TA), or if it should attempt to validate owner-ra.example.com against it's Implicit TA. One possibility is that in the Cloud Registrar case, if the Pledge *can* validate the given name against the Implicit TA database that it has, then it should. If it does manage to do that, then it can accept another 307 Redirect. If it can't validate, then it can't accept another 307. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | IoT architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ -- Michael Richardson <mcr+IETF@sandelman.ca> . o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide
- [Anima] chain of redirections for Cloud Registrar Michael Richardson
- Re: [Anima] chain of redirections for Cloud Regis… Michael Richardson
- Re: [Anima] chain of redirections for Cloud Regis… Carsten Bormann
- [Anima] BRSKI redirect Q (was: Re: chain of redir… Toerless Eckert
- Re: [Anima] chain of redirections for Cloud Regis… Toerless Eckert
- Re: [Anima] BRSKI redirect Q (was: Re: chain of r… Michael Richardson
- Re: [Anima] chain of redirections for Cloud Regis… Michael Richardson