headers
Chris Newman | 6 Sep 2007 21:48
Picon

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?
(Continue reading)

Permalink | Reply | 2 comments |
headers
Pasi.Eronen | 7 Sep 2007 11:36
Picon

RE: Application state binding with TLS session state

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
(Continue reading)

Permalink | Reply | 1 comment |
headers
Eric Rescorla | 7 Sep 2007 18:52

Re: TLS 1.2 hash agility

At Thu, 9 Aug 2007 12:34:07 +0300,
<Pasi.Eronen <at> nokia.com> wrote:
> 
> Mike (mike-list <at> pobox.com) wrote:
> 
> > I think the solution we need is to specifically list each supported
> > signature algorithm, e.g.
> > 
> >      enum {
> >        rsa_with_md5(0),    rsa_with_sha1(1),
> >        rsa_with_sha256(2), rsa_with_sha384(3),
> >        rsa_with_sha512(4), dsa_with_sha1(5),
> >        (65535)
> >      };
> > 
> > These may not be specific enough, as I've seen suggestions for,
> > e.g. rsa_pkcs1v1_5_with_sha1, and I've heard that some algorithms
> > need parameters, but I think I've made my point.
> 
> I think your suggestion looks good; it seems to handle the DSA and
> ECDSA cases better than just a list of hashes, and it's more
> in TLS style than sending DER-encoded AlgorithmIdentifiers. 
> And then we could change Signature structure to
> 
>    struct {
>       SignatureAlgorithm signature_algorithm;
>       opaque signature_value<0..2^16-1>;
>    } Signature;  
> 
> Eric, what's your opinion?
(Continue reading)

Permalink | Reply | 0 comments |
headers
Eric Rescorla | 7 Sep 2007 21:46

Re: Application state binding with TLS session state

At Fri, 7 Sep 2007 12:36:24 +0300,
<Pasi.Eronen <at> nokia.com> wrote:
> 
> 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...

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
(Continue reading)

Permalink | Reply | 0 comments |
headers
Simon Josefsson | 11 Sep 2007 10:21
Favicon
Gravatar

Review of draft-santesson-tls-gssapi-03

Hi.  We'd like to support GSS-API user authentication in GnuTLS.  I
don't care strongly about which approach to use to achieve that goal.
I've seen several drafts that could work, and believe it is important
that we reach consensus on one approach or we'll have different
approaches deployed soon.  I reviewed this draft since it appears to be
the most recent one still being worked on.  Generally I believe the
document looks good.

1) One major concern I have is that section 6 specifies a new GSS-API
mechanism that appear to be mostly unrelated the specification of the
gss_api TLS extension.  I believe it would simplify things considerably
if this section was moved to a separate document.  The GSS-API mechanism
is unlikely to be implemented by a TLS library, and is thus not within
the scope of the TLS WG.  Frankly, I'm not convinced it is useful to
have that GSS-API mechanism on the standards track in the IETF.  The
document says:

   It is possible to design a GSS-API mechanism that can be used with
   FKA-TLS in order to, for example, provide client authentication, and
   is so weak that its GSS- API token MUST NOT be in clear text over the
   open network.  A good example is a GSS-API mechanism that implements
   basic authentication.  Although such mechanisms are unlikely to be
   standardized and will be encouraged in no circumstance, they exist
   for practical reasons.

If that is indeed the only motivation for section 6, I strongly believe
it doesn't belong in this document.

Further, section 6 seems to be underspecified and needs more work.  For
example, there is no discussion how the inner TLS channel is terminated.
(Continue reading)

Permalink | Reply | 10 comments |
headers
Larry Zhu | 12 Sep 2007 02:24
Picon
Favicon

RE: Review of draft-santesson-tls-gssapi-03

Simon Josefsson wrote:
> We'd like to support GSS-API user authentication in GnuTLS.

This is great to hear. Thanks for posting the message to the list.

>  Generally I believe the
> document looks good.

Thanks for the positive feedback.

> 1) One major concern I have is that section 6 specifies a new GSS-API
> mechanism that appear to be mostly unrelated the specification of the
> gss_api TLS extension.

This was added to address Martin's comments. I had offline email with Martin, Sam, and Pasi, in which I proposed
to use TLS-renegotiation to replace section 6. In other words, section 6 is completely removed in -04, with
the following new text added in the section related to how to choose a GSS mechanism.

   It is generally beneficial to provide privacy protection for
   mechanisms that send client identifiers in the clear.  Furthermore,
   encrypting the GSS-API data can improve the strength of the overall
   systems, and when applicable complicate offline dictionary attacks
   against users' secrets based on which the keying materials are
   derived.  Therefore unless otherwise specified, TLS-renegotiation as
   defined in section 7.4.1.1 of [RFC4346] MUST be used to encrypt the
   GSS data in FXA-TLS gss_api extension.  This implies that the client
   and server negotiate FKA-TLS after completing a certificate-based
   TLS-handshake, typically to facilitate client authentication.

> What is intended here?  Does the middle paragraph refer to the situation
(Continue reading)

Permalink | Reply | 9 comments |
headers
Larry Zhu | 12 Sep 2007 04:56
Picon
Favicon

RE: Review of draft-santesson-tls-gssapi-03

Note that -04 is available here: http://www.secure-endpoints.com/tls-gss/draft-santesson-tls-gssapi-04.txt.

Thanks,

--larry

-----Original Message-----
From: Larry Zhu
Sent: Tuesday, September 11, 2007 5:24 PM
To: Simon Josefsson; tls <at> lists.ietf.org
Subject: RE: [TLS] Review of draft-santesson-tls-gssapi-03

Simon Josefsson wrote:
> We'd like to support GSS-API user authentication in GnuTLS.

This is great to hear. Thanks for posting the message to the list.

>  Generally I believe the
> document looks good.

Thanks for the positive feedback.

> 1) One major concern I have is that section 6 specifies a new GSS-API
> mechanism that appear to be mostly unrelated the specification of the
> gss_api TLS extension.

This was added to address Martin's comments. I had offline email with Martin, Sam, and Pasi, in which I proposed
to use TLS-renegotiation to replace section 6. In other words, section 6 is completely removed in -04, with
the following new text added in the section related to how to choose a GSS mechanism.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Simon Josefsson | 12 Sep 2007 08:25
Favicon
Gravatar

Re: Review of draft-santesson-tls-gssapi-03

Larry Zhu <lzhu <at> windows.microsoft.com> writes:

>> 1) One major concern I have is that section 6 specifies a new GSS-API
>> mechanism that appear to be mostly unrelated the specification of the
>> gss_api TLS extension.
>
> This was added to address Martin's comments. I had offline email with Martin, Sam, and Pasi, in which I proposed
> to use TLS-renegotiation to replace section 6. In other words, section 6 is completely removed in -04,
with the following new text added in the section related to how to choose a GSS mechanism.
>
>    It is generally beneficial to provide privacy protection for
>    mechanisms that send client identifiers in the clear.  Furthermore,
>    encrypting the GSS-API data can improve the strength of the overall
>    systems, and when applicable complicate offline dictionary attacks
>    against users' secrets based on which the keying materials are
>    derived.  Therefore unless otherwise specified, TLS-renegotiation as
>    defined in section 7.4.1.1 of [RFC4346] MUST be used to encrypt the
>    GSS data in FXA-TLS gss_api extension.  This implies that the client
>    and server negotiate FKA-TLS after completing a certificate-based
>    TLS-handshake, typically to facilitate client authentication.

I like this.

This text leads to an even stronger argument for permitting X.509 client
authentication in the first authentication step.  Otherwise you are
vulnerable to tunneling attacks of the GSS-API authentication step since
there appear to be no channel binding used.

Btw, I forgot to bring up channel bindings.  Have you considered
supporting it?  It is not critical to me, I consider X.509 or OpenPGP
(Continue reading)

Permalink | Reply | 5 comments |
headers
Martin Rex | 12 Sep 2007 18:12
Picon
Favicon

Re: Review of draft-santesson-tls-gssapi-03

Larry Zhu wrote:
> 
> > 5) Does the wire protocol differentiate between GSS_S_CONTINUE_NEEDED
> > and GSS_S_COMPLETE?  I'm thinking if the initial GSS_Init_sec_context
> > call returns GSS_S_COMPLETE.  The server will call
> > GSS_Accept_sec_context which shouldn't return any data.  The server
> > sends back a 0b string.  How can the client differentiate this from when
> > GSS_Accept_sec_context returned GSS_S_CONTINUE_NEEDED?  Perhaps the
> > answer is that the client simply disconnect in this situation, but maybe
> > that has to be noted.
> 
> A note is added as follows:
> 
>    As implied by GSS-API, a GSS-API token SHOULD NOT be received after
>    the context is established (GSS_S_COMPLETE is returned), the receiver
>    MUST tear down the connection in this case.

Only nitpicking: In the GSS-API original design, it is possible to
receive a context-level token after having seen GSS_S_COMPLETE from
the local context establishment function.

The obvious and non-controversial case has been deprecated
(the context deletion token).  The specified behaviour was too
pass this token to gss_process_context_token().

Whether or not an peer is allowed to create an context-level error
token (not a delete token) that the peer does not expect is fairly
unclear, however.  Implementations of the Kerberos 5 gssapi
mechanisms send such error tokens (containing a KRB_ERROR message)
in some situations.  I don't know whether these implementations refrain
(Continue reading)

Permalink | Reply | 1 comment |
headers
Martin Rex | 12 Sep 2007 19:16
Picon
Favicon

Re: Re: Review of draft-santesson-tls-gssapi-03

Simon Josefsson wrote:
> 
> >    It is generally beneficial to provide privacy protection for
> >    mechanisms that send client identifiers in the clear.  Furthermore,
> >    encrypting the GSS-API data can improve the strength of the overall
> >    systems, and when applicable complicate offline dictionary attacks
> >    against users' secrets based on which the keying materials are
> >    derived.  Therefore unless otherwise specified, TLS-renegotiation as
> >    defined in section 7.4.1.1 of [RFC4346] MUST be used to encrypt the
> >    GSS data in FXA-TLS gss_api extension.  This implies that the client
> >    and server negotiate FKA-TLS after completing a certificate-based
> >    TLS-handshake, typically to facilitate client authentication.
> 
> I like this.

I also like this text better (however I still don't like the entire
proposal and want to come up with an alternative proposal--unfortunately
personal and health issues are severely draining my time at the moment).
It adds round-trips, though.

> 
> This text leads to an even stronger argument for permitting X.509 client
> authentication in the first authentication step.  Otherwise you are
> vulnerable to tunneling attacks of the GSS-API authentication step since
> there appear to be no channel binding used.

I fully agree.  I mentioned a couple of times that I consider it
important to make it as easy as possible for consumers to enable
cert-based server authentication along with GSS-API client authentication.
(this doesn't help the "simple" (unidirectional) gssapi mechanisms,
(Continue reading)

Permalink | Reply | 1 comment |

Gmane