Hi, I'm putting this on the mailing list ahead of IETF 123 hoping to prompt some discussion based on some work done recently in 3GPP SA3. This follow-up comes out of discussions between Google, Cisco, Johns Hopkins, NSA, and NCSC.
At this point we would really appreciate the ACME group's input on two options for proceeding: - Would there be sufficient interest to incorporate any of the ideas below into a future RFC for general-purpose ACME? Perhaps the group is aware of up-coming drafts that might be willing to adopt/include things? - Or would the working group prefer to see a limited purpose RFC instead? If the group felt some agenda time was available in Madrid then a couple of people involved in the 3GPP work will be in attendance: Charles Eckel and me. Background: SA3 recently concluded work on a new informative text for use of ACME in the 5G Core. The updated version of the base spec with these change incorporated is available at: https://www.3gpp.org/ftp/Specs/archive/33_series/33.310/33310-j40.zip See Appendix J, p. 72 (note docx format stored in zip file - 3GPP norm). The consensus was to follow parts of the base RFC 8555, complemented with TKAuth validation per RFC 9447 with a new identifier and challenge type for 5G (currently being registered with IANA). There were some ideas generated which weren't quite vanilla RFC-8555, and thus not pursued, but which would have been beneficial if available to us. The extensions would be to parts of the RFC that were not marked as extensible. I will include some inline feedback kindly passed on by Andy Warner (Google) who was involved in the discussions. ---------- Brief overview of problem space and solution adopted: The 5G Core fits the following model: 1. Orchestrator/OAM: - can issue short term credentials and inject them into network functions when spinning them up - in the solution chosen, can act as TK Auth server. 2. Network functions/NF - virtualized - should have limited privileges - will have an ACME client 3. CA - distinct entity from the orchestrator/OAM External Account Binding (EAB) is used to secure account creation. TK Auth is used for identifier/identity validation. TK Auth token signed by OAM includes not just SAN fields but bespoke 5G X.509 extension (as defined in RFC 9509) for NFType. ----------- Acme Extensions In Orchestrate Use-cases (AEIOU) 1. External Account binding ideas EAB is adopted in our work to authorize account creation. This requires an every-time communication: every time an NF is created the OAM and CA must communicate to share the new MAC key, and other account specific information. If, say, certificate based options for digital signature were permitted the need for every-time OAM-CA communication could be alleviated (depending on what is encoded in the certificate - the NFType parameter in our case can be). We avoid the bootstrap problem since case the OAM can be assumed to be a secondary CA. Initial feedback suggests this is most inline with existing implementation. A finer-grained option would be to introduce OAuth (or similar) to account creation. This gives more flexibility in providing account information than just certificate extensions. In the orchestrated case the OAM can be the OAuth auth server. Initial feedback suggests this has interesting potential but is a significant change to the existing procedures. 2. Client certificates In our situation of having the OAM able to issue temporary certificates, we could use them in a couple of ways: a. the newAccount message to authenticate via mTLS at account creation instead of using EAB b. require them on TLS-ALPN challenges to limit on-path-attackers c. require them on HTTP challenges where the ACME client redirects to HTTPS Initial feedback from Andy highlighted the fact clientAuth is being pushed out of public trust stores, and that that TLS-ALPN is not as widely supported on the client side as I may have assumed. I also have reservations about b. and c. within the 5G use case as they require NFs which may not need open inbound ports for any other reason to start punching holes in their firewalls solely for the purpose of certificate issuance. However, for completeness I am mentioning them here. Your thoughts on these or other paths forward would be greatly appreciated. Matt G, NCSC, with input from Andy Warner (Google) and Charles Eckel (Cisco).
_______________________________________________ Acme mailing list -- [email protected] To unsubscribe send an email to [email protected]
