Re: [OAUTH-WG] draft-campbell-oauth-tls-client-auth-00 feedback

[Sean Leonard <[e-mail]>]

> On Nov 17, 2016, at 8:17 AM, Brian Campbell <[e-mail]> wrote:
> 
> inline...
> 
> On Wed, Nov 16, 2016 at 1:47 AM, Sean Leonard <[e-mail] <mailto:[e-mail]>> 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
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
>