[Anima] Cloud BRSKI discussion -- Option 3 use cases - Enroll to the Cloud

Michael Richardson <mcr+ietf@sandelman.ca> Sun, 24 November 2019 07:40 UTC

Return-Path: <mcr@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 2B69E120044 for <anima@ietfa.amsl.com>; Sat, 23 Nov 2019 23:40:33 -0800 (PST)
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 XjPmZzt3yab9 for <anima@ietfa.amsl.com>; Sat, 23 Nov 2019 23:40:31 -0800 (PST)
Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 185A5120025 for <anima@ietf.org>; Sat, 23 Nov 2019 23:40:31 -0800 (PST)
Received: from dooku.sandelman.ca (eth-west-pareq2-46-193-2-123.wb.wifirst.net [46.193.2.123]) by relay.sandelman.ca (Postfix) with ESMTPS id C56261F47D for <anima@ietf.org>; Sun, 24 Nov 2019 07:40:29 +0000 (UTC)
Received: by dooku.sandelman.ca (Postfix, from userid 179) id E803D9D1; Sun, 24 Nov 2019 15:40:32 +0800 (+08)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: "anima@ietf.org" <anima@ietf.org>
X-Attribution: mcr
X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha256"; protocol="application/pgp-signature"
Date: Sun, 24 Nov 2019 08:40:32 +0100
Message-ID: <28811.1574581232@dooku.sandelman.ca>
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/1PRO8dS-A2ymFVq9X6cXU3nG0Qw>
Subject: [Anima] Cloud BRSKI discussion -- Option 3 use cases - Enroll to the Cloud
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, 24 Nov 2019 07:40:33 -0000

Following up on the discussion at the WG meeting.
All three:

    https://github.com/anima-wg/brski-cloud/blob/master/presentations/three-flows.png

In all cases the Pledge gets some kind of network connectivity.
This could be an open WiFi, but is more often a cable plugged in with DHCPv4/IPv6.

3) Cloud issues voucher, Cloud issue registrar

This is section 7.2.1 in the ocument.

This is involves all the BRSKI mechanism occuring in the cloud, including
the use of EST onboarding.

The diagram is at:
  https://github.com/anima-wg/brski-cloud/blob/master/presentations/option-3-cloud-only.png

7.2.1:


   +--------+            +-----------+              +----------+
   | Pledge |            | Local     |              | Cloud RA |
   |        |            | Service   |              | / MASA   |
   +--------+            +-----------+              +----------+
       |                                                 |
       | 1. Full TLS                                     |
       |<----------------------------------------------->|
       |                                                 |
       | 2. Voucher Request                              |
       |------------------------------------------------>|
       |                                                 |
       | 3. Voucher Response {service:fqdn}              |
       |<------------------------------------------------|
       |                                                 |
       | 4. EST enroll                                   |
       |------------------------------------------------>|
       |                                                 |
       | 5. Certificate                                  |
       |<------------------------------------------------|
       |                                                 |
       | 6. Full TLS          |                          |
       |<-------------------->|                          |
       |                      |                          |
       | 7. Service Access    |                          |
       |--------------------->|                          |


Note that this all activity occurs with the Cloud RA.
In the case where the customer has a Registrar in a multi-tenant cloud
service, that this is really option 1, because there is a redirect.

This is closest to what current single-vendor verticals (e.g. Azure, Amazon,
etc.) do today for onboarding, in that the customer is never actually
represented.

The certificate might be ACME.

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-