Subject: [lemonade] TLS reauth hack

From: Dave Cridland <[email-masked]>
Date: Fri, 09 Nov 2007 23:33:36 +0000

I finally got around to publishing  
draft-cridland-sasl-tls-sessions-00.txt

This describes a potential hack using TLS session resumption and SASL  
EXTERNAL to essentially give single RTT reauthentication to any SASL  
mechanism supporting channel binding. I don't know we actually *have*  
any SASL mechanisms supporting channel binding yet, but nevertheless,  
hypothetical comments would be welcome, in theory.

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

_______________________________________________
lemonade mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/lemonade
Supplemental Web Site:
http://www.standardstrack.com/ietf/lemonade

---

From: Tony Finch <[email-masked]>
Date: Sat, 10 Nov 2007 12:52:38 +0000

On Fri, 9 Nov 2007, Dave Cridland wrote:

> I finally got around to publishing draft-cridland-sasl-tls-sessions-00.txt

Can you resolve the ambiguity problem by requiring that the client observe
that the server does not advertise EXTERNAL for a full TLS negotiation but
does when the client re-uses a TLS session ID that was set up by a
connection that used channel-bound SASL? The client then knows that the
EXTERNAL is related to the TLS session, and therefore knows that it'll get
the same authzid as previously.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
NORTHEAST SOLE LUNDY FASTNET: NORTHWESTERLY 5 OR 6. MODERATE. MAINLY FAIR.
GOOD.

---

From: Dave Cridland <[email-masked]>
Date: Mon, 12 Nov 2007 10:19:41 +0000

> the same authzid as previously.

This is probably a conversation for the SASL mailing list rather than  
here - I mentioned the draft here because it has applicability here.

If a naïve client is trying to setup two connections, say  
imap://[email-masked]/ and imap://[email-masked]/,  
and reuses the TLS session for both connections, it could quite  
easily accidentally use EXTERNAL mistakenly on whichever IMAP  
connection was second to be brought up, causing all sorts of fun and  
games. Clients do tend to use EXTERNAL blindly if advertised.

I suspect this will end up being PREAUTH-TLS-SESSION, and we'll end  
up with a whole family of PREAUTH-*.

Dave.

---

From: Tony Finch <[email-masked]>
Date: Mon, 12 Nov 2007 12:26:02 +0000

> here - I mentioned the draft here because it has applicability here.

I assumed that discussions should follow up to your original message,
since you didn't say otherwise. I'll leave the thread here since the sasl
list lacks the context.

> imap://[email-masked]/ and imap://[email-masked]/, and reuses
> the TLS session for both connections, it could quite easily accidentally use
> EXTERNAL mistakenly on whichever IMAP connection was second to be brought up,
> causing all sorts of fun and games.

In that case the client would be buggy, since it got its TLS sessions
mixed up. Perhaps that implies another requirement for the draft.

> Clients do tend to use EXTERNAL blindly if advertised. I suspect this
> will end up being PREAUTH-TLS-SESSION, and we'll end up with a whole
> family of PREAUTH-*.

That seems rather lame to me. Clients should know what authentication
mechanism they are using even if it spans multiple layers, so I don't
think it makes sense to use EXTERNAL blindly, and I don't think they need
extra help from the protocol to tell them which code path they are in the
middle of. Perhaps I'm failing to think of some circumstances in which
this is not possible.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
SHANNON: VARIABLE 3 BECOMING NORTHWEST 4 OR 5. MODERATE OR ROUGH. RAIN LATER.
MODERATE OR GOOD.

---

From: Dave Cridland <[email-masked]>
Date: Mon, 12 Nov 2007 12:44:08 +0000

> since you didn't say otherwise. I'll leave the thread here since  
Yes. I've not even mentioned the draft there, yet.

> > imap://[email-masked]/ and  
> imap://[email-masked]/, and reuses
Yes, it probably does.

> middle of. Perhaps I'm failing to think of some circumstances in  

I certainly think that using EXTERNAL blindly is a bad idea, but  
equally, it's how clients are behaving in the field, so it's quite  
possibly too late to do anything about.

Dave.