Hi Arndt, As stated in IETF123/Madrid you can find my personal review of draft-schwenkschuster-oauth-spiffe-client-auth-01:
* 1. Introduction: While this Draft is point at Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants [RFC7521<https://www.ietf.org/archive/id/draft-schwenkschuster-oauth-spiffe-client-auth-00.html#RFC7521>], the section should directly point to: § X.509-SVID authentication should point more to Mutual TLS Client Authentication and Certificate-Bound Access Tokens (MTLS) [RFC8705<Mutual%20TLS%20Client%20Authentication%20and%20Certificate-Bound%20Access%20Tokens%20(MTLS)>] § JWT-SVID authentication should also point more to OAuth 2.0 Attestation-Based Client Authentication [Ref<https://datatracker.ietf.org/doc/html/draft-ietf-oauth-attestation-based-client-auth>] which is more advanced in the IETF Draft pipeline on top of JWT Profile for OAuth 2.0 Client Authentication and Authorization Grants [RFC7523<https://www.rfc-editor.org/rfc/rfc7523.html>] Especially as this Draft focus more on "using SPIFFE credentials for OAuth client authentication" than grants. * 3.1. Client Authentication with JWT-SVIDs: * The proposed urn registration is urn:ietf:params:oauth:client-assertion-type:jwt-spiffe but as it builds on top of RFC7523 it might be better to declare it as urn:ietf:params:oauth:client-assertion-type:svid-jwt-bearer * At least can we switch spiffe for svid? svid includes spiffe notion but is more precise * The elements of Section 5 related to JWT-SVID should be included here and not in section 5 * 3.2 Client Authentication using X509-SVID * Maybe pointing to section 2.5 Client Authentication of RFC 9700 - Best Current Practice for OAuth 2.0 Security * The server certificate MUST be validated by the client using its system trust store, and NOT the SPIFFE trust bundle. * Might worth rephrasing: The server certificate MUST be validated by the client using its system trust store, and MUST NOT be validated by the SPIFFE trust bundle. * The request MUST include the client_id parameter containing the SPIFFE-ID of the client. It MUST match the URI SAN of the presented X509-SVID client credential. * The presence of the client_id parameter is expected by RFC8705 , that is an additional argument that we should enforce this as a profile of RFC 8705 and point to this draft is superseding it * The only "new" element is that the client_id MUST hold the SPIFFE ID value. * There is no mention of potential control on the extended key usage? Should TLS Web client authentication be checked ? * Perform standard X.509 path validation against the trust anchors according to Section 5. * On one side it talks of trust anchor and on the other side of the reference it talks about trust bundle, this should be clarified or aligned on trust bundle or changed to "the trust anchor represented by the trust bundle" * A change was made on the same in 3.1 for JWT-SVID, it should be applied here * 4. SPIFFE Trust Establishment and Client Registration This section needs to deal with Client registration impacts (it must not be out of scope): * for JWT Profile for OAuth 2.0 Client Authentication and Authorization Grants [RFC7523<https://www.rfc-editor.org/rfc/rfc7523.html>] it was pointed as out of scope * But now that we can pass more information see Section 6.2 Client Authentication of OAuth Client ID Metadata Document [ref<https://drafts.aaronpk.com/draft-parecki-oauth-client-id-metadata-document/draft-parecki-oauth-client-id-metadata-document.html>] * Should the client advertise it is capable of doing jwt-spiffe? what about the X.509-SVID authentication method? * for Mutual TLS Client Authentication and Certificate-Bound Access Tokens (MTLS) [RFC8705<Mutual%20TLS%20Client%20Authentication%20and%20Certificate-Bound%20Access%20Tokens%20(MTLS)>] it was specified that some new parameter could be specified in Section 3.4 Client Registration Metadata * Should this be adapted in this Draft to reflect the specifies of SPIFFE client authentication? * 5. SPIFFE Key Distribution and Validation * Section 5.1 seems to have specific guidance for JWT-SVID validation and X.509-SVID validation, would it not be better to distribute the sub-section in 3.1 and 3.2 accordingly to make the "authentication processing" for each type consistent? * Section 5.1: * The SPIFFE bundle endpoint cannot be derived from the JWT-SVID and X509-SVID and MUST be configured manually out of band. Bundle endpoints MUST be keyed by the trust domain identifier. * How to establish that? Can you give examples on where is the trust domain identifier in each case. * I am torn on 5.2 as a whole... if section 5.1 methods are a must, then maybe 5.2 should move into the Security consideration * 8. IANA Considerations * Maybe should evaluate looking at the OAuth Token Endpoint Authentication Methods IANA registry<https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#token-endpoint-auth-method> too as there are 2 new * Potential missing sections: * Proof of possession for the JWT-SVID passed as client authentication * Might be as simple as mentioning DPoP, will be aligned with where OAuth 2.0 Attestation-Based Client Authentication [Ref<https://datatracker.ietf.org/doc/html/draft-ietf-oauth-attestation-based-client-auth>] is going and the current * This is not needed for the X.509-SVID authentication as this will be handled by the mTLS authentication. * Proposition of simplification: § Should this Draft be split in two? one for JWT-SVID client authentication and one for X.509-SVID client authentication as profiles of JWT Profile for OAuth 2.0 Client Authentication and Authorization Grants [RFC7523<https://www.rfc-editor.org/rfc/rfc7523.html>] § and Mutual TLS Client Authentication and Certificate-Bound Access Tokens (MTLS) [RFC8705<Mutual%20TLS%20Client%20Authentication%20and%20Certificate-Bound%20Access%20Tokens%20(MTLS)>] * ? Jeff Jean-François "Jeff" Lombardo | Amazon Web Services Architecte Principal de Solutions, Spécialiste de Sécurité Principal Solution Architect, Security Specialist Montréal, Canada Commentaires à propos de notre échange? Exprimez-vous ici<https://urldefense.com/v3/__https:/feedback.aws.amazon.com/?ea=jeffsec&fn=Jean*20Francois&ln=Lombardo__;JQ!!Pe07N362zA!0k9CkAV8Djpw_8EfIAKrbhP3TQrJr0oMnznlUgBJ3V3NoEk6hihx7dNHnQuejn6SSH2CP8Iow3G-tTzppHeg$>. Thoughts on our interaction? Provide feedback here<https://urldefense.com/v3/__https:/feedback.aws.amazon.com/?ea=jeffsec&fn=Jean*20Francois&ln=Lombardo__;JQ!!Pe07N362zA!0k9CkAV8Djpw_8EfIAKrbhP3TQrJr0oMnznlUgBJ3V3NoEk6hihx7dNHnQuejn6SSH2CP8Iow3G-tTzppHeg$>.
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
