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

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

Hi all, 

I am trying to finish the work on draft-ietf-tls-oob-pubkey, which also covers smart objects as one use case. 
Have a look at the example message exchange below and tell me whether there is something missing here. 

Thanks. 

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
>

---

From: Robert Cragie <[email-masked]>
Date: Wed, 11 Jul 2012 18:05:19 +0100

Hi Hannes,

I think it would be easier to understand if the actual extensions were 
specified in the message diagrams. This seems to reveal a problem in the 
third use case (hybrid scenario), as it is not possible for the client 
to use a different certificate type to that selected by the server 
according to the 
http://tools.ietf.org/html/draft-ietf-tls-oob-pubkey-03/RFC 6091.

Robert

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

client_hello,
cert-type=(RawPublicKey, X.509) -> // (1)

                           <-  server_hello,
                               cert-type=RawPublicKey, // (2)
                               certificate, // (3)
                               server_key_exchange,
                               server_hello_done // (4)

client_key_exchange,
change_cipher_spec,
finished                  ->

                           <- change_cipher_spec,
                              finished

(1) Client supports both, preferring RawPublicKey. Alternatively, 
cert-type=(RawPublicKey), i.e. client supports onlyRawPublicKey
(2) Server supports and chooses RawPublicKey
(3) With raw public key (SPKI) inside
(4) Server knows OOB that it doesn't need Client certificate so doesn't 
send certificate_request (security policy for the system)

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

client_hello,
cert-type=(RawPublicKey) -> // (1)

                           <-  server_hello,
cert-type=RawPublicKey, // (2)
                               certificate, // (3)
                               server_key_exchange,
                               certificate_request, // (4)
                               server_hello_done

certificate, // (5)
client_key_exchange,
certificate_verify, // (6)
change_cipher_spec,
finished                  ->

                           <- change_cipher_spec,
                              finished

(1) Client supports only RawPublicKey
(2) Server supports only RawPublicKey
(3) With raw public key (SPKI) inside
(4) Server knows OOB that it needs Client certificate so sends 
certificate_request (security policy for the system)
(5) With raw public key (SPKI)inside
(6) Implies signing ability of raw public key

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

client_hello,
cert-type=(RawPublicKey, X.509) -> // (1)

                           <-  server_hello,
                               cert-type=X.509 // (2)
                               certificate,  // (3)
                               server_key_exchange,
                               certificate_request, // (4)
                               server_hello_done

certificate, // (5)
client_key_exchange,
certificate_verify, // (6)
change_cipher_spec,
finished                  ->

                           <- change_cipher_spec,
                              finished

(1) Client supports both, preferring RawPublicKey
(2) Server supports and chooses X.509
(3) With X.509 cert.
(4) Server knows OOB that it needs Client certificate so sends 
certificate_request(security policy for the system). **** Note it could 
be possible to request a RawPublicKey at this point. It is not clear 
that CertificateRequest supports requesting of a SPKI ****
(5) With raw public key(SPKI)inside *** This doesn't seem possible as 
X.509 has been chosen ****
(6) Implies signing ability of raw public key

On 11/07/2012 11:56 AM, Hannes Tschofenig wrote:
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>