Subject: [OAUTH-WG] Fwd: draft-ietf-tls-oob-pubkey: The Open Issue

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 11 Jul 2012 13:57:47 +0300

It would be good to get your feedback here as well as this document relates to the the holder-of-the-key concept (with the exchange of the raw public key in TLS). 

Ciao
Hannes

Begin forwarded message:

> From: Hannes Tschofenig <[email-masked]>
> Date: July 11, 2012 1:56:40 PM GMT+03:00
> To: [email-masked]
> Cc: Hannes Tschofenig <[email-masked]>
> Subject: draft-ietf-tls-oob-pubkey: The Open Issue
> 
> Hi all, 
> 
> draft-ietf-tls-oob-pubkey specifies a new TLS certificate type for exchanging raw public keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) for use with out-of-band public key validation.
> 
> Here is the latest draft: 
> http://tools.ietf.org/html/draft-ietf-tls-oob-pubkey-03
> 
> I would be great to get your feedback on an open issue that concerns the semantic of the exchange. I believe there are three use cases we would like to support with this work. Below, I provide high level message exchanges to explain those: 
> 
> I) Server uses Raw Public Keys (client authentication happens at some other layer)
> (the DANE use case)
> 
> client_hello, 
> raw-public-key-indicator="Server, when you send me your raw public key? I support this out-of-band key validation using DANE." ->
> 
>                          <-  server_hello,
>                              raw-public-key="OK. The certificate structure below contains my raw public key.",
>                              certificate, // with raw public key inside 
>                              server_key_exchange,
>                              server_hello_done
> 
> client_key_exchange,
> change_cipher_spec,
> finished                  ->
> 
>                          <- change_cipher_spec,
>                             finished
> 
> Application Data        <------->     Application Data
> 
> 
> II) Client and Server use Raw Public Keys
> (the smart object use case - CORE working group)
> 
> client_hello, 
> raw-public-key="Server, please send me your raw public key and I will then send you mine. Are you OK processing my raw public key for client authentication?" ->
> 
>                          <-  server_hello,
>                              raw-public-key="Below you find my raw public key and please send me your raw public key for client 
> 							   authentication",
>                              certificate, // raw public key
>                              server_key_exchange,
>                              certificate_request,
>                              server_hello_done
> 
> certificate, // with client's raw public key
> client_key_exchange,
> certificate_verify,
> change_cipher_spec,
> finished                  ->
> 
>                          <- change_cipher_spec,
>                             finished
> 
> Application Data        <------->     Application Data
> 
> 
> II) Hybrid Scenario
> (the OAuth Holder-of-the-Key Use case)
> 
> client_hello, 
> raw-public-key="I would like to use my raw public key for client authentication with OAuth. I also process X.509 for server-side authentication." ->
> 
>                          <-  server_hello,
>                              raw-public-key="Please send me your raw public key. I use X.509 for server-side authentication",
>                              certificate,  // with X.509 cert.
>                              server_key_exchange,
>                              certificate_request,
>                              server_hello_done
> 
> certificate, // with client's raw public key
> client_key_exchange,
> certificate_verify,
> change_cipher_spec,
> finished                  ->
> 
>                          <- change_cipher_spec,
>                             finished
> 
> Application Data        <------->     Application Data
> --------
> 
> QUESTION: Are these all the message exchanges we need? Are there some problems with the exchanges? 
> 
> Ciao
> Hannes
>