Re: [TLS] Should exporter keys be updated with post-handshake authentication and/or KeyUpdate?

[Andrei Popov <[e-mail]>]

Hi Douglas,

As currently defined, post-handshake client auth allows the same client to present different identities, but not to repudiate a previously presented identity. So in your example, from the TLS perspective, the client is both Alice and Bob, and therefore I think the same EKM value makes sense.

Cheers,

Andrei

-----Original Message-----
From: TLS [mailto:[e-mail]] On Behalf Of Douglas Stebila
Sent: Monday, July 11, 2016 12:40 PM
To: [e-mail]
Subject: [TLS] Should exporter keys be updated with post-handshake authentication and/or KeyUpdate?

Some of the discussions I've had with people about post-handshake client authentication have raised the question of whether application traffic secrets should be updated automatically upon post-handshake client authentication: the thinking being that every change in context should be accompanied by a change in keying material.  I used to think that was a good idea for TLS 1.3, although it was recently argued to me that if we view the application traffic secrets as being "internal" to the TLS protocol, then the change in client authentication status doesn't change the confidential or integrity properties of the record layer, it just serves as a "marker" to the application that certain portions of the application data were associated with certain authentication contexts.  I was convinced that this can be safely accomplished without a change in application traffic secret key material.

But I'm not sure that the same applies to *exporter* keys.  Should exported keying material change as the authentication context changes?

Consider a long-lived TLS connection, where different users come and go.  For example, a web browser on a public terminal may have established a long-lived TLS connection to a particular website, and send subsequent requests to the same website over the same TLS connection.  Now imagine two users use the terminal one after another:

1: initial handshake on a public terminal
2: [time passes]
3: Alice starts browsing
4: Alice does post-handshake client authentication
5: Alice purchases something
6: Alice hits "logout" at the application layer
7: [time passes]
8: Bob starts using the terminal
9: Bob does post-handshake client authentication
10: Bob purchases something
11: Bob hits "logout" at the application layer

TLS 1.3 will tell the application about events 4 and 9.  Events 6 and 11 happen at the application layer rather than the TLS layer (since I don't think TLS 1.3 has a client-de-authentication option).  But putting this all together, the application will learn all the correct authentication contexts: 1-3 is anonymous, 4-5 is Alice, 6-8 is anonymous, 9-10 is Bob, 11-onwards is anonymous.

Now imagine that we use keying material exporters in on lines 5 and 10:

1: initial handshake on a public terminal
2: [time passes]
3: Alice starts browsing
4: Alice does post-handshake client authentication
*5: Alice presses the "export keying material" button
6: Alice hits "logout" at the application layer
7: [time passes]
8: Bob starts using the terminal
9: Bob does post-handshake client authentication
*10: Bob presses the "export keying material" button
11: Bob hits "logout" at the application layer

Since the exporter master secret is not updated when client authentication changes, Alice and Bob will export the same keying material at steps 5 and 10.  If the intended goal of this exported key is for Alice to obtain confidentiality in some other use, this will not be achieved, since Bob will obtain the same exported key.

Now, a proviso is that RFC 5705 allows for the application to mix a "context value" into the export, which could mitigate this, but that is optional.

So it seems to me like in at least some scenarios, exported keying material should be associated with authentication context.  It is less clear to me if the same holds true for KeyUpdates.

Douglas
_______________________________________________
TLS mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/tls