> On Nov 17, 2016, at 8:17 AM, Brian Campbell <bcampb...@pingidentity.com> > wrote: > > inline... > > On Wed, Nov 16, 2016 at 1:47 AM, Sean Leonard <dev+i...@seantek.com > <mailto:dev+i...@seantek.com>> wrote: > 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. > > Thanks Sean. Some things at the WG meeting ran long and it fell off the back > of the list. The slides that would have been presented are in the meeting > materials > https://www.ietf.org/proceedings/97/slides/slides-97-oauth-sessb-tls-client-auth-00.pdf > > <https://www.ietf.org/proceedings/97/slides/slides-97-oauth-sessb-tls-client-auth-00.pdf> > if anyone wants to take a look (there's not a whole lot to them though). > > > 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. > > I agree that Section 1 could say more about the motivation/advantages over > the shared client secret. I'll look to expand on that in future revisions. > Specific proposed text is always welcome too. > > 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. > > I believe that the specifics of if and how a client id is represented in a > certificate is well beyond the scope of this document. But maybe some > considerations or guidance about using an attribute would be appropriate in > describing one possible way to do the binding between client and certificate, > if you wanted to propose some specific text.
Sure, I can propose some specific text along those lines. I will try to supply something over the next few weeks. Best regards, Sean > > > Editorial: there is a typo: Section 5.2: “specifc” should be “specific”. > > Will fix. Thanks. > > > > Regards, > > Sean > _______________________________________________ > OAuth mailing list > OAuth@ietf.org <mailto:OAuth@ietf.org> > https://www.ietf.org/mailman/listinfo/oauth > <https://www.ietf.org/mailman/listinfo/oauth> >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
