Subject: [kitten] SASL resumption?

From: Simon Josefsson <[email-masked]>
Date: Thu, 12 Apr 2012 11:26:57 +0200

All,

When experimenting with the OPENID20/SAML20 mechanisms, I've been
reminded that a usual pattern for SASL clients is to open several
connections to a server.  Traditionally this hasn't been a problem: the
passphrase or Kerberos ticket is cached so the client re-handshakes SASL
using CRAM-MD5, SCRAM-SHA-1 or GSS-API.

Both OPENID20 and SAML20 potentially need human interaction that can be
be slow.  Other mechanisms (e.g., SAML20EC and GSS-EAP) are less
dependent on human interaction but can still be slow.

Thus we have a problem that 1) clients expect to be able to open
multiple connections, and 2) some mechanisms may be costly to perform.

I see some solutions:

1) Recommend that OPENID20 and SAML20 are deployed in ways that minimize
human interaction.  Normally, IdPs have an option of remembering an
authorization decision of a user, so by using that, OPENID20/SAML20 can
complete more quickly: the user would just see several browser windows
flash by.  This mitigate the consequences of the problem, but doesn't
solve it.

2) Consider a SASL resumption mechanism.  This could work by having the
server compute a cookie that the client could present later on to get
the same access it got last time.  I'm not sure if this is best done by
extending core SASL with resumption features or adding a new
mechanism-negotiating-mechanism that handles resumption and invokes some
other mechanism.  Neither approach is appealing to me.

3) Rely on the secure channel resumption capabilities.  Clients appear
to be able to implement TLS resume.  We could use an EXTERNAL-like
mechanism that leverages the SASL state associated with the last TLS
channel, e.g. EXTERNAL-RESUME-TLS.  I don't think EXTERNAL will work,
its semantics is too under-specified and the failures are difficult to
recover from.  If the EXTERNAL-RESUME-TLS mechanism is advertised the
server has some SASL state stored for the client, and the client could
decide to leverage that, or start a completely new handshake.  The
client could also more gracefully handle failures in EXTERNAL-RESUME-TLS
(e.g., session expiration) and fall back to the initial SASL mechanism
used.  The EXTERNAL-RESUME-TLS could be GSS-API mechanism too.

Are there other solutions?  Thoughts?

The background for this is the following discussion: 
http://thread.gmane.org/gmane.comp.security.lasso.devel/171/focus=187

/Simon

---

From: Dave Cridland <[email-masked]>
Date: Thu, 12 Apr 2012 10:48:11 +0100

> used.  The EXTERNAL-RESUME-TLS could be GSS-API mechanism too.

I proposed this a few years ago, and was met with a combination of  
mistrust and apathy, so I never bothered persuing it:

http://tools.ietf.org/draft/draft-cridland-sasl-tls-sessions/

An alternative would be to construct a slightly different approach  
wherein a client used some shared secret property of the existing TLS  
channel as a shared secret for some (simple) mechanism. Of course,  
this has the disadvantage that you'd be implicitly provisioning your  
account with a plaintext equivalent shared secret...

One problem with either approach is that if you use a public  
terminal, you implicitly allow reuse of the established credential -  
as such, my gut feeling is that the TLS channel would need to be  
explicitly enabled as possible to reuse for authentication, and so  
would need some extensions to TLS to make it work well.

Dave.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 12 Apr 2012 12:03:59 +0200

Dave Cridland <[email-masked]> writes:

>> 3) Rely on the secure channel resumption capabilities.
>

Perhaps, as they say, the time for it has come.

I'm not sure re-using EXTERNAL for this will work well in practice
though.  There are other use-cases for EXTERNAL which makes it difficult
for clients and servers to know whether your draft or something else is
intended.  To me, EXTERNAL is difficult to deploy in any interoperable
fashion.  (That was the motivation for [1] btw...)

> account with a plaintext equivalent shared secret...

Right.  If the mechanism is specific for this use-case, I'm not that
concerned with security issue you mentioned: servers can refuse to
advertise the mechanism if they don't like its properties, and clients
can refuse to use the mechanism if they don't like its properties.

> One problem with either approach is that if you use a public terminal,
> you implicitly allow reuse of the established credential -  

The decision whether to allow the current session for resumption or not
could be made in the application protocol too.  However I agree this is
a serious problem, and maybe it applies to all solutions in this space.

/Simon

[1] https://tools.ietf.org/html/draft-josefsson-sasl-external-channel-04

---

From: "Cantor, Scott" <[email-masked]>
Date: Thu, 12 Apr 2012 14:59:29 +0000

> dependent on human interaction but can still be slow.

In the case of SAMLEC, a likely solution is to get moved to holder of key so that a longer lived assertion can be issued to the client and then used as a multi-use token. That isn't 100% drop-in to the existing profile but it's very doable when the client isn't braindead.

I still think you need a solution, just saying I was aware of the problem and had at least some long term plan for it.

> to be able to implement TLS resume.

Assuming that's true, do servers? How often? What if there are concentrators and offloading involved, which is true of the vast majority of deploys. If you're depending on the server having actual access to the TLS session in some way, that's probably a non-starter. I don't know enough about TLS to know if that's what you're assuming.

-- Scott

---

From: Dave Cridland <[email-masked]>
Date: Thu, 12 Apr 2012 16:26:53 +0100

> fashion.  (That was the motivation for [1] btw...)
Yes, I follow your logic - I've personally found EXTERNAL to be fine,  
albeit I've also found that for reliable usage one always need to  
specify an authzid somehow.

The rest of your mail I entirely agree with.

Dave.

---

From: Dave Cridland <[email-masked]>
Date: Thu, 12 Apr 2012 16:28:13 +0100

On Thu Apr 12 15:59:29 2012, Cantor, Scott wrote:
> Assuming that's true, do servers? How often? What if there are  
> concentrators and offloading involved, which is true of the vast  
> majority of deploys. If you're depending on the server having  
> actual access to the TLS session in some way, that's probably a  
> non-starter. I don't know enough about TLS to know if that's what  
> you're assuming.

I think that's true only for HTTPS - for other protocols, such as  
XMPP or IMAP, I'd have thought that TLS offloaders and/or proxies  
would be fairly rare. These types of protocols are the hunting-ground  
here - IMAP clients often open multiple connections, and XMPP clients  
need very rapid reconnect.

Dave.

---

From: "Cantor, Scott" <[email-masked]>
Date: Thu, 12 Apr 2012 15:47:33 +0000

> need very rapid reconnect.

AFAIK, it's not at all rare. Especially for mail. At some enterprises, there are pushes to consolidate all TLS handling in a load balancer and maintain the certs there, regardless of the protocol.

Leaving that aside, am I correct that it would be a deal breaker? We can disagree whether it's a problem (or leave that as a community specific question), but it's useful for me in evaluating the potential of the suggestion.

-- Scott

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 12 Apr 2012 21:29:46 +0200

> Leaving that aside, am I correct that it would be a deal breaker? We can disagree whether it's a problem (or leave that as a community specific question), but it's useful for me in evaluating the p…

If the TLS stack used doesn't support TLS resumption, there is no way
that we can implement SASL resumption using TLS resumption, so that
would indeed be a deal breaker for that approach.

I agree with Dave that I think this view of TLS stacks is HTTPS-biased.
In my experience, with SMTP/IMAP/XMPP you cannot terminate the TLS
session at one point and then forward the unencrypted session somewhere
else and expect that the "somewhere else" will work without special
customization to both the TLS stack and the SMTP/IMAP/XMPP side.  It
messes up authorization and STARTTLS negotiations.  Do you have any
pointers to implementations of TLS load balancers that support
SMTP/IMAP/XMPP with STARTTLS?  My point is that if there is some
protocol between the TLS stack and SMTP/IMAP/XMPP servers to send the
necessary TLS information, that protocol could be enhanced with the
TLS-resume related information.  I'm hoping that these environments are
rare though.

However, SASL resume would be a new feature, so it isn't unreasonable
for it to require certain things which aren't unversally implemented.
Of course, it would be better if we could implement SASL-resume using
something that we know was available everywhere already.  But maybe it
is better to have solved the problem for a subset of installations than
to not have solved the problem at all.

/Simon

---

From: William Mills <[email-masked]>
Date: Fri, 13 Apr 2012 09:21:15 -0700 (PDT)

I would argue that for things like IMAP that require multiple connections and reconnections that you want something like OAuth credentials to use.  Your resource server could issue a bearer or SAML (or other) token to use on reconnect as a result of the initial negotiation, but it would seem cleaner to put up an OAuth 2 style flow with OpenID as the authn mechanism.

We certainly encountered the problem of multiple simultaneous connections in the IMAP context for the OAuth stuff.  My tentative solution was that the client needs to understand that it's fetching a reusable credential and it locks the cred store if it needs to authenticate.  As such it's an implementation feature rather than a protocol one.  

>________________________________
> From: Simon Josefsson <[email-masked]>
>To: [email-masked] 
>Sent: Thursday, April 12, 2012 2:26 AM
>Subject: [kitten] SASL resumption?
> 
>All,
>
>_______________________________________________
>Kitten mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/kitten
>
>
>

---

From: "Cantor, Scott" <[email-masked]>
Date: Fri, 13 Apr 2012 16:29:27 +0000

On 4/12/12 3:29 PM, "Simon Josefsson" <[email-masked]> wrote:
>messes up authorization and STARTTLS negotiations.

What I'm familiar with is not STARTTLS but straight TLS wrapping of IMAP
and things like that, so it's purely a tunnel and the load balancer strips
the tunnel off and forwards it along.

>Do you have any
>SMTP/IMAP/XMPP with STARTTLS?

No.

>to not have solved the problem at all.

What I was trying to say was that if I was fairly sure I'd have lots of
customers that would need the issue dealt with, and I didn't think they
could use TLS resumption, then I'd feel obligated to work out a viable
path to do it in the mechanism I'm designing. Which is more or less how I
feel at the moment. I can wait on it, but I know that I'll need it, and it
was something I thought about a bit.

-- Scott