Subject: Re: [TLS] channel id and oob

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 18 Oct 2013 14:03:51 +0200

Hi Dirk,

thanks for looking at the two specifications. A few remarks below:

On 08/02/2013 12:10 PM, Dirk Balfanz wrote:
> Hi guys,
>
> I was asked to write a quick analysis of draft-ietf-tls-oob-pubkey, and
> whether it can be applied to the use cases we have in mind for Channel ID.
>
> My conclusion is that it can not, or that the necessary modifications to
> the OOB draft would be too substantial to be considered during Last Call.
>
> First, the similarities: both proposals allow the client to prove
> possession of a key pair. The fact that this proof-of-possession is
> forthcoming is negotiated using the TLS extension mechanism (during
> ClientHello/ServerHello).
>
> Now for the differences:
>
>   * We don't want the client public key to be sent in the clear. It's a
>     client identifier, and shouldn't be known to anyone but the client
>     and the server.

This is an aspect the group agreed to solve via a separate extension, if 
I remember it correctly since it has wider applicability than just for 
these documents.

Recalling Ekr's presentation about TLS 1.3 from the last IETF meeting he 
mentioned that this would be one of the features of the new version. 
Whether it is useful to define an extension that can be used with TLS 
1.1/1.2 is a decision the ADs and chairs need to make.

>
>   * We don't want the proof-of-keypair-possession to be part of the
>     session state,

I am not entirely sure what you mean by "proof-of-keypair-possession to 
be part of the session state".

  for two reasons:
>       o It blows up the session state, with ramifications on the size of
>         the fleet of servers that cache this information.
> Remember that
>         in our use case, we don't intend this to be used for the
>         occasional client that wants to use non-password authentication
>         with the server; it's designed to be used by _every_ client
>         talking to big service providers like Google. Raw public keys
>         are of course smaller than full certificates, but they still
>         represent a significant increase in the size of session state.

The document does not require servers to store the received raw public key.

>       o We don't want someone who is not actually wielding the private
>         key of the keypair to make it appear to the server as if they
>         were in control of that private key. Session resumption,
>         however, gives you that power: Let's assume that the private key
>         of the keypair sits in a hardware-protected secure element, and
>         is therefore out of reach of malware. Master secrets and other
>         session information, however, is very likely kept in RAM and
>         therefore available to thieves. If such a thief extracts the
>         session data from the client and resumes the session, the server
>         will treat the thief as the holder of the original private key.
>         If the proof-of-keypair possession is explicitly declared not
>         part of the session, then a client has to re-prove possession of
>         the keypair even during abbreviated handshakes. Thus, a thief of
>         session secrets (but not of the private key) won't be able to
>         convince a server that it is in control of that private key.

You don't have to use session resumption if you do not want.

I also consider the threat a bit unrealistic. If you assume that the end 
device is compromised then what prevents the malware from obtaining the 
private key before it gets into the hardware-protected secure element. I 
believe in your scenario you are not talking about a long-term ephemeral 
key pair but rather something that is dynamically created on the end 
device or dynamically provisioned.

>
>     The oob-draft keeps the raw key in the session state, thus
>     inheriting this problem with session state and session resumption.

We actually don't say anything about keeping the key in session state 
nor about session resumption. I consider those aspects implementation 
and configuration issues.

>
>   * Channel ID keys are different from key material sent in the
>     Certificate message, and the certificate message shouldn't be
>     overloaded with this new semantics: Key material presented in the
>     Certificate message (even if it's a raw key) presumably carries some
>     semantics for the application: "this is a certain user", "this is an
>     enterprise-issued machine", etc., while the Channel-ID keys are
>     always self-generated and their semantics include (among other
>     things) "this is the key that will be nuked when the user presses
>     the 'reset my browsing state' button". It makes for tricky
>     implementations when those two different semantics get mapped to the
>     same protocol message. More importantly, applications may want to do
>     both: authenticate a user with a client cert, and then set a
>     channel-bound cookie as a result of the authentication. You can't do
>     that if you only have one proof-of-possession available in the
>     handshake.

With the raw public key we actually do not say what identity the key 
refers to.

You are correct that there is an issue if we want to provide two layers 
of authentication within TLS and I am not sure whether that is even in 
scope of your document either since it is not discussed.

>
> As mentioned above, I don't really see how this issues could possibly be
> addressed within the draft-ietf-tls-oob-pubkey draft, especially since
> it's in last-call. Just the first point above alone seemed to be
> something that folks didn't want to touch until TLS 1.3.
>
> Thoughts?

What we could do is the following:

a) Brainstorm whether we see the two layers of authentication as a valid 
use case. I don't think we both do but maybe someone else does.

b) We work on a specification that provides the confidentiality 
protection of information exchanged by the client. This could be useful 
in a number of cases, even work that is currently ongoing in the TLS 
working group right now.

c) We clarify the issues regarding the session state. I did not occur to 
me that this would be something to write about in the document but maybe 
it is worthwhile to have a discussion about it.

Ciao
Hannes

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

---

From: Dirk Balfanz <[email-masked]>
Date: Mon, 21 Oct 2013 16:12:57 -0700

On Fri, Oct 18, 2013 at 5:03 AM, Hannes Tschofenig <
[email-masked]> wrote:

> This is an aspect the group agreed to solve via a separate extension, if I
> remember it correctly since it has wider applicability than just for these
> documents.
>

Right. Which is why my take-away was that ChannelID won't be seriously
considered until TLS 1.3.

> I am not entirely sure what you mean by "proof-of-keypair-possession to be
> part of the session state".
>

When your TLS terminators resume a session with a client - what do those
terminators tell their backends about the session? If the client proved
possession of a private key/certificate during the original handshake, so
terminators not tell their backends about that key on a resumed session?
For ChannelID, we explicitly _don't_ want them to do that.

> You don't have to use session resumption if you do not want.

But I do want to use session resumption! It's saves bits during the
handshake. :-)

> private key before it gets into the hardware-protected secure element.

The key could have been created inside the secure element to begin with.

> I believe in your scenario you are not talking about a long-term ephemeral
> key pair but rather something that is dynamically created on the end device
> or dynamically provisioned.
>
>
> We actually don't say anything about keeping the key in session state nor
> about session resumption. I consider those aspects implementation and
> configuration issues.
>

That's interesting. I was looking for the part in the TLS spec that says
"thou shall make client certs part of the session state", and indeed
couldn't find it. But in practice, of course that is what people are doing,
right? If your TLS terminators didn't make a client cert part of the
session state, how could you ever resume a session with them and still be
considered authenticated with that client cert?

> With the raw public key we actually do not say what identity the key

Right - of course not; that kind of stuff doesn't belong in the spec. But
in practice these keys are used for something, and if I want to keep doing
that something, while at the same time do something else (provide key
material to which upper-layer credentials such as cookies can be bound),
then using the same message for those two somethings won't work.

> You are correct that there is an issue if we want to provide two layers of
> authentication within TLS and I am not sure whether that is even in scope
> of your document either since it is not discussed.
>
>
>
>

Let me address this by starting at the application layer: Let's say we want
a feature in which browsers authenticate themselves to servers. This should
happen transparently so that users aren't bothered by it, but it shouldn't
be so transparent that the user can't change the key material if/when they
want to. So we build this feature into the browser, including all the UI,
and now we're looking for a message in the TLS layer to put that proof of
key possession. The ClientCertificate message immediately comes to mind. So
we'll build our network stack so that the keys (that can be reset by the
user, but will be generated and selected transparently) will be used by the
ClientCertificate message.

Now someone else wants a different application-layer feature: they want CAs
to be able to issue user certificates, users to be able to install them,
explicitly select among them when connecting to a server. Again, the
ClientCertificate message seems like a natural vessel for the proof-of-key
possession that comes with this feature. So now, when we build the network
stack, it looks like the keys used in the ClientCertificate message should
be those installed by user when the receive a certificate from a CA, etc.

It's not so much that I want to do ChannelID and TLS Client Auth _at the
same time_, it's that the ClientCertificate message, and the logic around
it, becomes quite messy if it needs to serve these two different user cases
- perhaps not at the TLS layer itself (maybe that one is just given a key
pair), but someone somewhere will have to decide which keys we're using -
the self-generated transparent ones or the CA-certified ones.

The same is true at the server side. You guys may remember that the first
iteration of this ("TLS-OBC") in fact re-used the ClientCertificate
message. When we realized that we were about to turn on essentially TLS
Client Auth for a substantial fraction of the clients out there, we had to
go inside the network stack on the server and put some logic in there that
said: "if the ClientCertificate message carries one of those transparent
keys that the user can reset whenever they want, do one thing; and if it
carries one of those keys that are certified by a CA, do something else",
which started to become quite messy. We think it's easier to have two
different messages for these.

>
> b) We work on a specification that provides the confidentiality protection
> of information exchanged by the client. This could be useful in a number of
> cases, even work that is currently ongoing in the TLS working group right
> now.
>

I think there have been a couple of attempts in this direction, and the
consensus seems to be that we'll do this in TLS 1.3.

> me that this would be something to write about in the document but maybe it
> is worthwhile to have a discussion about it.
>

Yeah, I'm a bit confused about this. I was a bit surprised to not find more
explicit mention of what it means to resume a session in the TLS spec.
Clearly, a resumed session (from the server's point of view) means "the guy
on the other end knows the same master secret as I do". But in practice it
also means "the guy on the other side wields the private key corresponding
to this certain public key", if that's what was proven during the initial
handshake. If that's something that implementations simply assume without
it being called out in the spec, maybe that's something that we should
think about some more.

Dirk.

>
>
> Ciao
> Hannes
>
>
>> Dirk.
>>
>>
>>
>> ______________________________**_________________
>> TLS mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/**listinfo/tls<https://www.ietf.org/mailman/listinfo/tls>
>>
>>
>

---

From: Bodo Moeller <[email-masked]>
Date: Mon, 21 Oct 2013 19:27:14 -0400

> considered authenticated with that client cert?

In very basic usage of client certificates, a server might be configured to
only ever allow authenticated clients with certificates from a particular
CA to start sessions -- e.g., letting them access intranet content without
having to know which particular client each access is coming from.  In
simple cases like that, there's no need to keep certificate details around
in session state.

---

From: [email-masked] (Martin Rex)
Date: Tue, 22 Oct 2013 02:28:36 +0200 (CEST)

> terminators not tell their backends about that key on a resumed session?

Reverse Proxies will normally forward the authenticated client cert
PLUS any chain certificates that were received and successfully verified
during the full handshake to the backend.

Clients will normally also cache the Server certificate plus the entire
chain in the client side session cache.  Every reasonably portable and
generic TLS protocol implementation is likely going to include that
information in its SSL session cache.  Applications may not necesserily
know nor care whether the TLS handshake was a full handshake or
abbreviated handshake (aka session resume).

> considered authenticated with that client cert?

Session caching simply would not make any sense without caching
most of the attributes that were successfully established or successfully
negotiated during the full TLS handshake.  I do not see a difference
between the client caching the server's certificate chain and the
server caching the client's certificate chain.

> explicit mention of what it means to resume a session in the TLS spec.

TLS is underspecified in a lot of places.  You may remember the result
of renegotiation being underspecified. A security problem that remained
unnoticed for ~13 years.

> to this certain public key", if that's what was proven during the initial

Each peer only knows that the peer was able to perform a proof-of-posession
during the full TLS handshake.  It would be unwise to make any assumptions
about the posession of a private key for any point in time, much less any
later points in time, independent of whether the original TLS
connection has been running for a few hours, or whether this is about
a newly established TLS connection that has just been resumed from
the TLS session cache, with the original TLS handshake a few hours
in the past.

The certificate path validation (in particular when revocation checking
from remote information sources is performed) may be in the same ballpark
that the full handshake crypto operations, so typically, there is not
going to be a certificate path validation on session resume.

-Martin