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

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

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: Eric Rescorla <[email-masked]>
Date: Wed, 11 Jul 2012 07:21:25 -0700

> 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…

It might help if you desscribe the actual open issue.

> raw-public-key-indicator="Server, when you send me your raw public key?

Is your suggestion that this is indicating ":I would not support X.509?

> I support this out-of-band key validation using DANE." ->

Wait, who said anything about indicating DANE here? The agreed upon
indication was
"I would support a public key", nothing about DANE.

> 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?" ->

This is not a semantic associated with the client. In TLS the server
requests client auth. At most the client could say "I could
send you a raw public key for auth if you asked for it"

> 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." ->

As above.

>                           <-  server_hello,
>                               raw-public-key="Please send me your raw public key.

This is in certreq, no?

>  I use X.509 for server-side authentication",

Why would this need an indication?

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

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Wed, 11 Jul 2012 17:16:36 +0200

> I) Server uses Raw Public Keys (client authentication happens at some other layer)

If you don't need a client certificate or public key, you don't send a
certificate request.

> (the smart object use case - CORE working group)

Your draft already covers that case.

> (the OAuth Holder-of-the-Key Use case)

(server X.509 certificate, client raw public key)

I see two options. 1. You overload the ClientCertificateType of the
certificate request with a raw_rsa_sign that does what you intend. 2.
You create a new extension that modifies the format of the certificate
request to include an explicit certificate format.

regards,
Nikos

---

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

Hi Ekr, 

thanks for your quick response. 

When we started the work we just copied the functionality from RFC 6091 and that RFC defined a new "cert_type" extension. 
As it turns out RFC 6091 didn't IMHO clearly specify the semantic of the value in the cert type.

There are various scenarios, as described below. 

For example, when a client sends a cert_type="raw-key, x509" does this mean it can raw public keys for client authentication and it is OK to receive an X.509 for server authentication? Does it want to receive also a raw public key from the server when the server supports it? 

> Is your suggestion that this is indicating ":I would not support X.509?

There has to be a way to indicate what is supported. The rest is not supported. 

> "I would support a public key", nothing about DANE.
What happens if the client supports raw public keys but does not support the out-of-band validation using DNSSEC? 
While I wasn't really suggesting to provide the way to say "I want to use DANE" I see problems for interoperability here. 

> send you a raw public key for auth if you asked for it"

The important thing here is the indication that both the server and the client are able to process and accept raw public keys. 

>>                              raw-public-key="Please send me your raw public key.

I should have rather written. The certreq is asking for your raw public key since you said you support raw public keys (but you have may other certificate types). 

> Why would this need an indication?

I believe the problem is that we have to provide a way for the client to figure out what is in the certificate extension. In the raw public key case we only dump the SubjectPublicKeyInfo structure into the Certificate payload. 

We make it easier for the client to parse the content of the structure. 

Right? 

Ciao
Hannes

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 11 Jul 2012 09:06:16 -0700

> For example, when a client sends a cert_type="raw-key, x509" does this mean it can raw public keys for client authentication and it is OK to receive an X.509 for server authentication? Does it want…

Sure, the indication of what you want to do versus what you want the other side
to do seems poentially separable.

> There has to be a way to indicate what is supported. The rest is not supported.

Well, the basic state of TLS clients is that they support X.509. And of
course servers are allowed to ignore unknown extensions, so there is
always some chance that you will just get an X.509 cert anyway.

> What happens if the client supports raw public keys but does not support the out-of-band validation using DNSSEC?

What do you mean? There are only like 50 other ways to verify raw public keys,
starting with fingerprints. The indication here seems to be "if you send me a
raw key I will do something sensible"

> The important thing here is the indication that both the server and the client are able to process and accept raw public keys.

Well, what the client can say is "I would accept a raw key if you sent
it" and "I could send you a raw key
if you asked", right?

> I should have rather written. The certreq is asking for your raw public key since you said you support raw public keys (but you have may other certificate types).

OK.

> We make it easier for the client to parse the content of the structure.

Sure, I have no problem with "the certificate message contains the following"

-Ekr

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 11 Jul 2012 19:08:35 +0300

Hi Nikos, 

thanks for the response. 

> If you don't need a client certificate or public key, you don't send a

You mean: If the server does not want any client authentication then it does not send a certificate request. 
If that's what you mean then I agree with you. 

But in this scenario the server provides the raw public key. 

> Your draft already covers that case.

That's what I thought but Paul had a different understanding. 

It is not quite clear what the semantic of the cert_type="RawPublicKey" in the client hello message is. 

> (server X.509 certificate, client raw public key)
Yes. 

> certificate request with a raw_rsa_sign that does what you intend.

I currently had taken the route that I use an extension to indicate what stuff is in the certificate payload. 
It seems that RFC 6091 and the recently submitted OBC had chosen the same approach. 

> 2.

Of course the existing certificate format cannot (and should not) be changed. 
One could put an additional marker into the cert payload that makes it easy for the client and the server to differentiate the content of the payload.  

In the implementation I put together for the smart object security workshop I just used the the cert_type to determine what the content of the cert is and I didn't had to take additional steps. 

(Maybe I am making this too complicated and it is in fact trivial to differentiate the two payload types.) 

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

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Wed, 11 Jul 2012 19:36:50 +0200

> But in this scenario the server provides the raw public key. 

This is what I mean. I don't understand understand how providing the raw
public key changes this fact. Did you explicitly specified in the
draft-ietf-tls-oob-pubkey that no certificate request is expected? If
not I would expect the TLS semantics to remain.

> It is not quite clear what the semantic of the cert_type="RawPublicKey" in the client hello message is. 

Then the semantics should cleared up. What is the different
understanding? As I understand this draft, if the extension is present,
then _both_ server and client certificates are encoded in "raw" format.

> One could put an additional marker into the cert payload that makes it easy for the client and the server to differentiate the content of the payload.  

And would also be easier to mount attacks in the protocol. If you change
the format of the certificates it should be clear in the handshake what
certificate format is expected.

regards,
Nikos