Re: [TLS] channel id and oob

[Dirk Balfanz <[e-mail]>]

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

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


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


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

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.


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

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


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


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

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?



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

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

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.


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

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
>> [e-mail]
>> https://www.ietf.org/mailman/**listinfo/tls<https://www.ietf.org/mailman/listinfo/tls>
>>
>>
>