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

[<Pasi.Eronen at nokia.com>]

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:Chris.Newman at Sun.COM] 
> Sent: 06 September, 2007 22:48
> To: tls at ietf.org
> Subject: [TLS] Application state binding with TLS session state
> 
> 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
TLS at lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls