Subject: [OAUTH-WG] draft-ietf-tls-oob-pubkey: My summary

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 12 Jul 2012 10:54:48 +0300

Hi Erk, Hi Robert, Hi Nikos, 

thanks for your quick response.  Here is an attempt to summarize your input. 

--------

I use three types of indications in the message exchange below for improved clarity, namely: 

(a) 'cert-receive=(value-1, value-2, ..., value-n)' with the meaning: "I accept certificate of the following types (value-1, ..., value-n) if you send them to me." The list is ordered by preference. 

(b) 'cert-send=(value-1, value-2, ..., value-n)' with the meaning: "I could send you certificate of the following types  (value-1, ..., value-n) if you ask." The list is ordered by preference. 

(c) cert-info=(value) with the meaning: "The certificate payload in this message contains a certificate of the following type". 

I) Server uses Raw Public Keys (client authentication happens at some other layer) (the DANE use case)

client_hello,
cert-receive=(Raw, X.509) // (1)
cert-send=()             -> // (2)

                         <-  server_hello,
                             cert-info=(Raw),// (3)
                             certificate, // (4)
                             server_key_exchange,
                             server_hello_done 

client_key_exchange,
change_cipher_spec,
finished                  ->

                         <- change_cipher_spec,
                            finished

Application Data        <------->     Application Data

Legend: 

(1) Client accepts to receive two types of certificates, preferring raw public keys.
(2) The client does not have a raw public key nor an X.509 certificate for client authentication. 
(3) The server decides to sends his raw public key and indicates this in the cert-info field. 
(4) The certificate payload contains the raw public key. 

II) Client and Server use Raw Public Keys (the smart object use case - CORE working group)

client_hello,
cert-receive=(Raw) // (1)
cert-send=(Raw)             -> // (2)

                         <-  server_hello,
                             cert-info=(Raw),// (3)
                             certificate, // (4)
                             certificate_request, // (5)
                             cert-receive=(Raw) // (6)
                             server_key_exchange,
                             server_hello_done 

cert-info=(Raw), // (7)
certificate, // (8)
client_key_exchange,
change_cipher_spec,
finished                  ->

                         <- change_cipher_spec,
                            finished

Application Data        <------->     Application Data

Legend: 

(1) Client accepts to receive raw public keys.
(2) The client does have a raw public key for client authentication. 
(3) The server decides to sends his raw public key and indicates this in the cert-info field. 
(4) The certificate payload contains the raw public key. 
(5) The server wants to use client authentication and and sends a cert-request. 
(6) The certificate request asks for a certificate of type 'raw' (knowing that the client supports it from (2)). 
(7) The client indicates that the certificate payload contains a raw public key
(8) Here is the payload of the certificate itself. 

III) Hybrid Scenario (the OAuth Holder-of-the-Key Use case)

client_hello,
cert-receive=(X.509, Raw) // (1)
cert-send=(Raw)             -> // (2)

                         <-  server_hello,
                             cert-info=(X.509),// (3)
                             certificate, // (4)
                             certificate_request, // (5)
                             cert-receive=(Raw) // (6)
                             server_key_exchange,
                             server_hello_done 

cert-info=(Raw), // (7)
certificate, // (8)
client_key_exchange,
change_cipher_spec,
finished                  ->

                         <- change_cipher_spec,
                            finished

Application Data        <------->     Application Data

Legend: 

(1) Client accepts to receive X.509 certs and raw public keys, in this order of preference. (Could also be X.509 only in this example)
(2) The client does have a raw public key for client authentication. 
(3) The server decides to sends his X.509 cert and indicates this in the cert-info field. 
(4) The certificate payload contains the X.509 cert. 
(5) The server wants to use client authentication and sends a cert-request. 
(6) The certificate request asks for a certificate of type 'raw' (knowing that the client supports it from (2)). 
(7) The client indicates that the certificate payload contains a raw public key.
(8) Here is the payload of the certificate itself. 
 
--------

Do these indications clarify the semantic?
I personally believe so. 

Ciao
Hannes

---

From: "Manger, James H" <[email-masked]>
Date: Fri, 13 Jul 2012 01:40:18 +1000

> (1) Client accepts to receive X.509 certs and raw public keys, in this
> order of preference. (Could also be X.509 only in this example)
> (6) The certificate request asks for a certificate of type 'raw'
> (knowing that the client supports it from (2)).

So the OAuth client completes a TLS handshake with a protected resource using a raw key, but the protected resource doesn't get any authorization for that raw key until it sees an access_token which appear where? In an HTTP header somewhere in the App Data some time after the TLS handshake finishes?

--
James Manger

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 13 Jul 2012 14:47:07 +0300

Hi James, 

> So the OAuth client completes a TLS handshake with a protected resource using a raw key, but the protected resource doesn't get any authorization for that raw key until it sees an access_token whic…
The access token is conveyed in the HTTP exchange (similar to what bearer does). As such, the authorization decision would be done when the resource server receives the access token. 

Ciao
Hannes

---

From: John Bradley <[email-masked]>
Date: Fri, 13 Jul 2012 08:13:07 -0400

It sucks for TLS hinting:)

In principal the client needs to know what keypair to use for the TLS session before it is initiated.

The protected resource establishes the session with client auth accepting any client key.

The protected resource compares the client key passed in from TLS with the one in the token as part of token validation, and accepts or rejects the token.

It is different from "normal" TLS client auth in that it is not the TLS layer making the access decision.

John B.
On 2012-07-12, at 11:40 AM, Manger, James H wrote:

> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 13 Jul 2012 15:35:44 +0300

Hi John, 

authorization decisions are not made by the TLS library - they are made by the application. 

For example, in the HTTPS case the authorization decision that is made by the client is to compare the content of the cert with the domain part of the HTTP URI. Similar authorization decisions are being made by many applications using HTTP, see http://tools.ietf.org/html/rfc6125.

So, there is nothing unusual here. 

Ciao
Hannes

---

From: John Bradley <[email-masked]>
Date: Fri, 13 Jul 2012 09:32:18 -0400

I am not saying it is unusual in a bad way.

Some people think of TLS client auth happening at the TLS layer.   That is common in  server to server connections.

Decisions based on the client cert can happen at the app layer, as they do in SAML HoK.

I think people have less experience with doing that though.

John B.

---

From: Phil Hunt <[email-masked]>
Date: Fri, 13 Jul 2012 07:40:04 -0700

At the moment there is no hok proof in the token itself. It seems to be bound in tls. 

The spec isn't clear yet that a token is passed in 3.2. But I assumed that is what Hannes intended. 

Still since there is no comment about passing the token I guessed it would essentially be a bearer token backed by a client authenticated tls. 

Phil

---

From: John Bradley <[email-masked]>
Date: Fri, 13 Jul 2012 11:01:27 -0400

I think having the proof in the token works for SAML and JWT.

I would like to also allow for an opaque token that the RS may deference to get the key.

John B.