Following up on the discussion at the WG meeting.
All three:
https://github.com/anima-wg/brski-cloud/blob/master/presentations/three-flows.pngIn 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 <[email protected]>, Sandelman Software Works -= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
