Re: [TLS] draft-ietf-tls-oob-pubkey: The Open Issue

[Robert Cragie <[e-mail]>]

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

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


(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

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

(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

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

(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:
> 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
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>