Subject: [TLS] Application state binding with TLS session state

From: Chris Newman <[email-masked]>
Date: Thu, 06 Sep 2007 12:48:09 -0700

During IESG review of draft-salowey-tls-rfc4507bis, I raised this issue:

---
If an application performs user-level authentication subsequent to
initiation of the TLS tunnel (e.g. via GSSAPI or SASL), it would be
possible for the application to trigger a TLS-level renegotiation that
includes a NewSessionTicket embedding information about the app-level
authentication.  Alternatively, the application could have a mechanism
to bind the user-level authentication to a given session ticket
(although this would involve server state).  Then on re-connection,
the application could use app-level mechanisms to automatically resume
the user session (e.g. IMAP PREAUTH or SASL EXTERNAL).  It's not clear
to me if this is a good/bad idea, what the security risks would be, or
if TLS stacks should be advised to include APIs to facilitate such use
of the mechanism.  This document is silent on such interaction with
applications.  Were this a first version, I'd ask for this issue to be
considered and addressed if there was consensus.  But I don't want to
delay an obvious bugfix to an already published RFC.
---

We felt this issue would require significant WG discussion to address and it 
was more important to get the 4507 bugfix out promptly.

However, I do want the working group to consider this and decide what to do 
about it.  As there's a general issue of binding application state to a TLS 
session, some text in the TLS 1.2 specification addressing this might be 
appropriate.

What do others think about this topic?

                - Chris

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

---

From: <[email-masked]>
Date: Fri, 7 Sep 2007 12:36:24 +0300

Binding of application state to TLS session applies not only 
to 4507bis, but ordinary TLS session resumption as well.

Current TLS implementations usually have some kind of APIs that 
allow applications to store application-specific data in the TLS 
session cache entry (e.g., SSL_SESSION_set_ex_data() in OpenSSL 
and SSLSession.putValue() in Java JSSE), but this is not really
mentioned anywhere in the TLS RFCs.

As long as this is purely a local implementation detail, maybe 
it even doesn't need to be mentioned in protocol standards...
But if some application protocols would start assuming that
this feature exists (in a way that has to be implemented in TLS
layer, and can't be implemented by the application calling TLS),
then things become more complicated...

Best regards,
Pasi

> -----Original Message-----
> From: ext Chris Newman [mailto:[email-masked]] 
> Sent: 06 September, 2007 22:48
> To: [email-masked]
> Subject: [TLS] Application state binding with TLS session state
> 
> possible for the application to trigger a TLS-level renegotiation
> that includes a NewSessionTicket embedding information about the
> app-level authentication.  Alternatively, the application could have
> a mechanism to bind the user-level authentication to a given session
> ticket (although this would involve server state).  Then on
> re-connection, the application could use app-level mechanisms to
> automatically resume the user session (e.g. IMAP PREAUTH or SASL
> EXTERNAL).  It's not clear to me if this is a good/bad idea, what
> the security risks would be, or if TLS stacks should be advised to
> include APIs to facilitate such use of the mechanism.  This document
> is silent on such interaction with applications.  Were this a first
> version, I'd ask for this issue to be considered and addressed if
> there was consensus.  But I don't want to delay an obvious bugfix to
> an already published RFC.
> ---
> 
> We felt this issue would require significant WG discussion to
> address and it was more important to get the 4507 bugfix out
> promptly.
> 
> However, I do want the working group to consider this and decide
> what to do about it.  As there's a general issue of binding
> application state to a TLS session, some text in the TLS 1.2
> specification addressing this might be appropriate.

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 07 Sep 2007 12:46:34 -0700

> then things become more complicated...

Pasi's assessment looks right to me as well.

- This can only be used for soft state, because neither client or
  server is required to offer/accept resumption.
- This doesn't affect the wire protocol at all for ordinary resumption.
- RFC 4507 resumption does affect the wire protocol in the sense
  that the tickets change, but since they're opaque the client
  does not need to understand the ticket, so it should be 
  interoperable in either case.
- No stack support is actually required with ordinary resumption 
  because the app can simply store its own data keyed by the
  session ID.
- Stack support is required with 4507-style resumption, because
  the data has to be stored in the ticket.

-Ekr