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

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:

>> 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.
> 
> 
> 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
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth