Hello OAuth folks: I have some feedback about draft-campbell-oauth-tls-client-auth-00. Overall I think it is a good, concise effort, and should be adopted as a WG item. Sorry that it didn’t get addressed in the WG meeting.
Section 1 mentions “shared secret” as the default in OAuth 2.0, but this draft provides an alternative that (implicitly) does not require a shared secret between the client and server components. However, this draft does not elaborate on the advantages of avoiding shared secrets: the advantages should be addressed in Section 1 or in the Security Considerations. In particular, a lot of enterprise scenarios seem to do intentional man-in-the-middle attacks (aka endpoint termination) for “logging” and “auditing” purposes: see the IETF 97 TLS WG meeting materials <slides-97-tls-tls-visibility-inside-the-data-center>. These same enterprise use cases are significant motivators for eliminating shared secrets on the wire. Section 5.2 discusses some ideas about associating/binding a certificate to a client identifier (client_id). I understand that in many use cases, the certificate and public key will be long-lived and issued by an authority prior to the client’s contact with the AS; in a minority of use cases (such as IoT devices), the AS will also issue certificates to clients. The best and most flexible way to do this is to define an attribute, let’s say “oauthClientID”, of type VisibleString, which can be multi-valued. By defining it as an attribute, it can be put in at least four useful protocol slots: 1. Subject Directory Attributes (RFC 5280 Section 4.2.1.8): this is where metadata about the subject goes that is not part of the distinguished name. 2. Subject attributes: this is when you want the client_id to be bound more authoritatively to the certificate, i.e., the utility and lifetime of the certificate == the lifetime of the client/AS association. 3. LDAP attributes: this is where metadata about the subject is associated together with the certificate, but not part of the certificate (which is usually in the userCertificate attribute for the LDAP entry). 4. “other places” where metadata gets associated with certificates, such as crypto tokens and databases (LDAP, of course, is just a type of database). By making the attribute multi-valued, one can associate multiple client_ids with one certificate, which means that the same certificate/keypair can be used with multiple services. Creating a new attribute is strongly preferable to reusing a field such as “commonName”, since commonName is overused and can lead to conflicts (compare with SSL’s legacy use of commonName). subjectAltName is also not preferable because the client_id itself is not really a globally unique name; it’s closer to a serial number or random (but not secret) string. To make it globally unique it needs to be combined with an identifier for the AS, and that makes such a structure more complicated. Furthermore, subjectAltName is specific to being inside a certificate; it does not have semantics outside of a certificate, whereas a generic directory attribute has equal semantics inside and outside of certificates. Editorial: there is a typo: Section 5.2: “specifc” should be “specific”. Regards, Sean _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
