Subject: [kitten] Browser or not (was RE: sasl saml and sasl openID)

From: "Scott Cantor" <[email-masked]>
Date: Mon, 15 Nov 2010 10:52:33 -0500

Stipulating that there's some way to accomplish CB by passing something on
the URL you give to the browser, it seems like it's worth having a
discussion about the more fundamental differences between the mechanisms,
namely the use of a browser vs. a desktop client.

If you're going to change the IdP and strengthen the mechanism, then it
stands to reason that the main differences left would be the client UI and
the fact that the EC mechanism will have holder of key as an option. Maybe
the latter is enough to justify it in its own right, but if not (or if you
were to allow for client TLS in order to support the SAML HoK Browser
profile) that leaves the UI.

I've heard the claim that it's somehow less secure to put my credentials
into a desktop client. I can't say that I buy that, but perhaps that's a
subjective question. I know that I trust my mail client a heck of a lot more
than I trust any browser. I'm more swayed by the fact that a browser UI
makes it much easier to implement consent-based release of attributes and
that sort of thing.

I'm also concerned about mobile devices, which seem less amenable to
launching a browser and getting control back.

-- Scott

---

From: Martin Rex <[email-masked]>
Date: Tue, 16 Nov 2010 03:27:44 +0100 (MET)

> namely the use of a browser vs. a desktop client.

Although I can not demonstrate any obvious security problem, I'm
feeling slighlty uneasy with having an app send tls-unique channel
bindings over _other_ channels than the particular TLS channel
from which they originate.  tls-unique represents the unkown part of
the plaintext for the very first encrypted message on a newly
established TLS channel.

When using it for channel binding of a gssapi handshake over this very
same TLS channel, there should not be any problem if the gssapi mechanism
transfers the channel bindings in the clear within context level
tokens, because the outer TLS channel protection applies the that
handshake in the same way it applied to the original tranfer of the
Finished handshake message from which the tls-unique CB data is created.
However, if the gssapi mechanism sends this channel bindings
data over completely distince communication channels to arbitrary
third parties during the magic that happens within gss_init_sec_context(),
it does not leave a warm cozy feeling.

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 15 Nov 2010 21:16:10 -0600

> the plaintext for the very first encrypted message on a newly

Martin, as RFC5929 explains, TLS supports integrity-protection-only
cipher suites, in which case the cleartext Finished message is available
to passive attackers.  TLS' security depends on the strength of the
Finished message construction, including the PRF that is at the core of
the Finished message construction.  We discussed this matter at some
length during the many discussions of tls-unique that we've had.  If
revealing the Finished messages could compromise TLS then TLS has big
problems because it'd mean, among other things, that the TLS PRF is
broken, and this would have far reaching impact.  I believe there's no
harm in making the TLS Finished message cleartext public.

Nico
--

---

From: Klaas Wierenga <[email-masked]>
Date: Tue, 16 Nov 2010 10:42:18 +0100

On 11/15/10 4:52 PM, Scott Cantor wrote:

Scott,

> subjective question. I know that I trust my mail client a heck of a lot more

I can not talk for others, but given that I made a remark wrt entering
credentials in my presentation at the Kitten wg meeting I think I should
clarify.
I didn't want to imply that I trust my browser more than a desktop
client. What I don't like is that a user is trained at entering his
credentials at potentially many different places. Let's assume for a
second this SASL-SAML thing takes of. It would mean that I input my
credentials in my mail client, my browser, my Jabber client, my SSH
client etc. etc. That takes away one big benefit of SSO solutions, both
from a usability and a security PoV imo..

> makes it much easier to implement consent-based release of attributes and

Good point!

> launching a browser and getting control back.

True, especially for non-multitasking OSes

Klaas

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 16 Nov 2010 16:52:54 +0100

> the plaintext for the very first encrypted message on a newly

I got that uneasy feeling too, and wrote the draft below as a more
stringent alternative to 'tls-unique':

http://tools.ietf.org/html/draft-josefsson-sasl-tls-cb

However there were not sufficient interest at that time, and SCRAM/GS2
now reference the 'tls-unique' CB explicitly so we are stuck with it.

> it does not leave a warm cozy feeling.

Agreed.

/Simon

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 16 Nov 2010 10:42:24 -0600

> now reference the 'tls-unique' CB explicitly so we are stuck with it.

Simon, your draft used the TLS PRF (same as the Finished messages used
by tls-unique) and bound only the client and server nonces, but none of
the other parts of the handshake.  Eric Rescorla, myself and others
explained at the time that binding all of the handshake is highly
desirable and why.  Lack of interest is most assuredly NOT the reason
that we proceeded with tls-unique instead of your approach: your CB
construction was actually subject to an MITM attack (see below).

Folks, a keyed PRF is supposed to be irreversible.  On top of that, the
Finished messages are supposed to remain cryptographically strong even
when used with cipher suites that do not provide confidentiality
protection.  On top of that, the Finished messages are a PRF applied to
hashes of handshake messages -- the hash algorithms used (TLS 1.2 gets
agility) don't have pre-image attacks, and the handshake messages, at
least for outer tunnels, are public anyways, and even for renegotiation,
the only private thing in the handshake would be the client's cert.

Thus what about making Finished messages public scares you?  And why not
further hash the tls-unique CB if you're concerned?

On top of that, we want to bind to all of the handshake, not just the
client and server nonces.  Consider RSA key transport... if the CB bound
only the nonces then an MITM could make sure that the CB came out the
same on both connections (the client's to the MITM and the MITM's to the
actual server) -- the MITM need only have a server cert that's
acceptable to the client, which is easy enough to achieve in the public
web.  Whereas tls-unique does NOT suffer from this attack because the
RSA key transport bits will be different if the MITM's and actual
server's RSA keys are different (if the MITM has the same keys then you
have bigger issues, to say the least) and the RSA key transport bits are
in the handshake, which gets bound into the CB data construction.

Nico
--

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 16 Nov 2010 18:05:50 +0100

> construction was actually subject to an MITM attack (see below).

That was fixed in -01 back in August 2008.

> Thus what about making Finished messages public scares you?

That the Finished message is used to solve two different but both
critical security problems: 1) to protect the TLS handshake, and 2) to
serve as CB data to detect MITM's in higher level protocols.

I see this as similar to re-using a key or nonce for two different
purposes or protocols.  That the data is re-used in different protocols
is even more disturbing to me.

The argument about integrity-only TLS is unconvincing to me: practically
nobody uses TLS without encryption, and it isn't something that is well
analyzed.  If there is a problem with it, those ciphersuites will likely
be deprecated and nobody will care.  Nobody would rightly classify that
as TLS being broken.

> And why not further hash the tls-unique CB if you're concerned?

That would solve the problem, but it introduces hash agility concerns.

Let me clarify: I'm not pushing for my solution today.  I used it as an
illustration for Martin that the time to push for something other than
tls-unique was several years ago.  To do something about the situation
today requires more than just uneasy feelings.

/Simon

---

From: "Scott Cantor" <[email-masked]>
Date: Tue, 16 Nov 2010 12:32:41 -0500

> today requires more than just uneasy feelings.

Out of curiosity, is doing tls-unique in Java possible with the usual TLS
approaches? I know it's not with my TLS environment (libcurl on top of
OpenSSL).

-- Scott

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 16 Nov 2010 11:36:13 -0600

> That was fixed in -01 back in August 2008.

Oh, I missed that when I glanced at -02.

> serve as CB data to detect MITM's in higher level protocols.

Again... the Finished messages are supposed to work even when you use
cipher suites without confidentiality protection, and their construction
is clearly either secure or TLS is badly broken.

> is even more disturbing to me.

I don't think re-using the Finished messages is remotely like re-using a
key or a nonce.  The construction of the Finished messages had better be
secure, else TLS is broken.

> be deprecated and nobody will care.  Nobody would rightly classify that

The construction of the Finished messages had better be secure, else TLS
is broken.

> That would solve the problem, but it introduces hash agility concerns.

True.  I believe there's no need to hash it.

> today requires more than just uneasy feelings.

Fair enough.  The ship has sailed.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 16 Nov 2010 11:37:33 -0600

> approaches? I know it's not with my TLS environment (libcurl on top of

I don't know.  I ask around.

I thought Sam and friends were working the libcurl angle, so eventually
you'll be able to get tls-unique via libcurl.

Nico
--

---

From: Martin Rex <[email-masked]>
Date: Tue, 16 Nov 2010 21:59:25 +0100 (MET)

Simon Josefsson wrote:
> > Folks, a keyed PRF is supposed to be irreversible.
> >  [...]

I said "slightly uneasy feeling" not "scares me" nor "disturbing",
and I am _not_ asking for a change.
(OT: if there is anything disturbing about verify_data, then that it wasn't
 increased from 12 to 20 octets for TLSv1.2 when the PRF hash was
 upgraded from SHA1(=20octets) to SHA256(32-octets)).

The specific rationale that was used when a concern about re-sending
verify_data was raised during the TLS renego discussion does not apply here:

   http://www.ietf.org/mail-archive/web/tls/current/msg04214.html

> serve as CB data to detect MITM's in higher level protocols.

I do _not_ feel uneasy with sending the verify_data of the clients Finished
message three times during TLS secure renego instead of only once.
And I do _not_ mind any additional times within GSS-API context level
tokens over that very same TLS channel.

Actively distributing originally confidential verify_data to other
parties is slightly different in nature.

> 
> The argument about integrity-only TLS is unconvincing to me

That argument applies to exactly two non-encrypting cipher suites that
are UNpopular by providing a false sense of security for binary TLS on/off
indicators, lacking to provide protection for password-based authentication
over TLS-protected channels (the primary reason why TLS is used at all),
and these non-encrypting cipher suites are disabled by default in most
implementations.

> > And why not further hash the tls-unique CB if you're concerned?

One of the objective for TLS and even more GSS-API was to keep
crypto-related operations out of the hands of the apps folks.

>From a procedural standpoint, either we know of a problem and should
then fix/update the CB spec, or use it exactly as specified.
Otherwise it is _us_ who are scaring away apps folks from rfc5929.

But if we start distributing the tls-unique channel bindings
to third-parties, we should eventually file an update-errata for
TLSv1.2 to go on record that we've decided to do that (based on rfc5929).

> That would solve the problem, but it introduces hash agility concerns.

tls-unique CB is 12 octets for all currently defined cipher suites
with protocol version TLSv1.[012], so I don't think collisions for
hashes with 20+ octets are an issue here (if anything, only the
Workfactor of the algorithm for a forward exhaustive search).

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 16 Nov 2010 15:37:42 -0600

> and I am _not_ asking for a change.

OK, good.

>  upgraded from SHA1(=20octets) to SHA256(32-octets)).

I agree, I'd have preferred to have selection of version 1.2 result in
selection of a larger verify_data_length.

To be fair, in 1.2 verify_data_length varies according to the cipher
suite chosen, so this can be addressed by... adding new versions of the
cipher suites we use the most, or all of them even.  Of course, cipher
suite code point explosion is an obnoxious aspect of TLS...

> parties is slightly different in nature.

Again, the Finished message computation is such that revealing the
Finished message plaintext is not a problem.  If that were a problem
then that would be indicative of at least a cryptographic break of the
TLS PRF, which alone would be fatal to the security of TLS regardless of
what you choose to do with Finished messages.  And it might even be
indicative of breaks of one or more cryptographic properties of the hash
algorithm applied to the handshake messages.

The fact that to extract useful information about the master_secret from
the Finished message implies a cryptographic vulnerability in all of TLS
makes me think that there's no issue at all here.  At the very least
active attacks would be enabled, possibly also passive attacks (in
combination with known plaintext attacks?).  Putting the tls-unique CB
data into out-of-band messages (to IdPs and what not) would at worst
make passive attacks possible if the PRF vulnerability only facilitated
active attacks (but only if the CB data is sent in the clear), but the
fundamental vulnerability of the PRF would be the problem.

In other words: never mind tls-unique, that TLS PRF had better be strong
for TLS' sake.

> Otherwise it is _us_ who are scaring away apps folks from rfc5929.

Exactly.  So, where's the problem?

> TLSv1.2 to go on record that we've decided to do that (based on rfc5929).

Errata?  No, the TLS WG got a chance to review RFC5929.  We considered
whether RFC5929 should update RFC5246, and IIRC Eric did not want that;
I would have preferred to update RFC5246, but the fact is that the TLS
community knows about tls-unique.

Nico
--

---

From: Martin Rex <[email-masked]>
Date: Tue, 16 Nov 2010 23:53:28 +0100 (MET)

Nicolas Williams wrote:
> Martin Rex wrote:
> Errata?

AFAIK there is just _one_ category for publishing additional/clarifying
information to a published document, and that category is labelled "Errata"

>
> No, the TLS WG got a chance to review RFC5929.  We considered

I agree that it is not necessary to make support for rfc5929 an implicit
pre-requisite of any succesor document to rfc-5246.

But if you look at any of the existing TLSv1.[012] protocol specs, then
it is pretty clear that the finished message is the very first
encrypted message (for TLS cipher suites that employ encryption).
And there is *NO* part of TLS that lightheartedly spoils the
confidentiality of that handshake message (ClientFinished.verify_data
for full handshakes and ServerFinished.verify_data for abbreviated
handshakes aka. resume).

What you definitely want to avoid is that anyone extending the
TLS protocol in the future builds assumptions on the confidentiality
of those verify_data, because a combination of two other documents
(that are not linked through the document header markings) has
decided to actively disclose that data to other parties, because
this is nothing that a reader of the TLS protocol spec can be
expected to anticipate.

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 16 Nov 2010 17:15:01 -0600

> information to a published document, and that category is labelled "Errata"

I know.  I was just expressing skepticism.  Errata is for minor errors.

> pre-requisite of any succesor document to rfc-5246.

Well, I'd like support for RFC5929 to be an explicit requirement.  For
that to happen we'll need to see more take up of RFC5929.  NEA WG is
apparently going to be using tls-unique in one EAP method to bind an
inner method to an outer tunnel.  Between that and SASL/GS2 apps I think
we'll soon see enough take up.

> encrypted message (for TLS cipher suites that employ encryption).

Yes.

> for full handshakes and ServerFinished.verify_data for abbreviated

Again, for cipher suites with confidentiality.

> this is nothing that a reader of the TLS protocol spec can be

Fair enough.  But an erratum won't do.  You should want an update to
RFC5246.

---

From: "Cantor, Scott E." <[email-masked]>
Date: Wed, 24 Nov 2010 03:14:45 +0000

>I forgot to respond to this part of your message:

Thanks, sorry for the delay in responding.

>credentials at potentially many different places.

Noting that people already do this today.

> Let's assume for a

Well, weak credentials are usually cached in clients, just as people do in
their browser. But browsers are, frankly, completely broken when it comes
to credential caching, and many (FF for one) will blindly spray
credentials all over because of the bugs in their password manager
implementations that they seem unwilling to fix by requiring user approval
to submit cached passwords.

I also am concerned that most users will be quite phishable if they're in
the middle of doing something that has nothing to do with the web, and
then suddenly end up in a browser. If they bother to check anything today
(which they don't), I think they'll be less likely to do so in such a
case. "Just get out of my way and let me check my mail..."

I grant you the SSO point, but I also kind of think that mechanisms like
this will be very good fits with the use of Kerberos to authenticate to
IdPs.

>> makes it much easier to implement consent-based release of attributes

This remains my biggest concern, but I figure if Moonshot can figure this
out, I can piggyback.

-- Scott

---

From: Josh Howlett <[email-masked]>
Date: Wed, 24 Nov 2010 13:08:52 +0000

Scott wrote:
> Klaas wrote:
> > Scott wrote:
> >> makes it much easier to implement consent-based release of attributes
> >> and that sort of thing.
> >
> >Good point!
> 

How do you see the piggyback working?

(We're expecting to tunnel this through the EAP channel).

Josh.

JANET(UK) is a trading name of The JNT Association, a company limited
by guarantee which is registered in England under No. 2881024 
and whose Registered Office is at Lumen House, Library Avenue,
Harwell Science and Innovation Campus, Didcot, Oxfordshire. OX11 0SG

---

From: "Cantor, Scott E." <[email-masked]>
Date: Wed, 24 Nov 2010 15:33:19 +0000

> (We're expecting to tunnel this through the EAP channel).

What I meant was the UI, not so much the protocol aspect. I realize that your model is intended to have the supplicant take most of the UI burden, but there's still a UI and it has to make sense.

But from experience, I know that real-time consent is difficult for all kinds of reasons, and it isn't a show-stopper to make progress, so not having it doesn't in and of itself convince me that the authentication should be handled by the worst piece of software on the box from a security PoV, the browser.

Another point is that browsers have a hopelessly broken mechanism for server authentication (in this context, authentication of the IdP). Doing that from the ground up within a mechanism provides a fresh opportunity to look at the problem.
 
-- Scott

---

From: Josh Howlett <[email-masked]>
Date: Thu, 25 Nov 2010 13:35:03 +0000

> What I meant was the UI, not so much the protocol aspect.

Ok, that fixes my confusion.
 
> But from experience, I know that real-time consent is difficult for all
> kinds of reasons, and it isn't a show-stopper to make progress, so not
> having it doesn't in and of itself convince me that the authentication
> should be handled by the worst piece of software on the box from a
> security PoV, the browser.

+1

Josh.