Subject: [saag] FW: [secdir] Reminder

From: Tina Tsou <[email-masked]>
Date: Tue, 29 Mar 2011 16:37:03 +0200

Hi all,
Hokey's summary is attached.

We keep our promises with one another - no matter what!

Best Regards,
Tina TSOU
http://tinatsou.weebly.com/contact.html

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 31 Mar 2011 03:27:16 +0100

All,

As I spoke about at the Secir lunch, here is a channel binding solution
for the applet use case that I would like to discuss at saag if possible.

http://aaa-sec.com/_temp/CHannel%20binding_Applet_02.pdf

As I fear that time will not permit this to take up time at the saag
meeting, but I would welcome as much comments as possible.
Not only just on the proposal as such, but whether a solution to this use
case could have it's place in an RFC.

The problem is to protect a user, having contact with a service provider
through a browser and an applet from MitM attacks.
Part of this use case is that the Applet provider is part of a secure
infrastructure, capable of validating signatures of legitimate service
providers.

The user has an assumed MitM free channel to a service provider. This
service provider responds with an html page including an Applet tag with
signed parameters. The signed parameters includes a the signed end point
channel bindings of the server.

The signed applet is loaded from the Applet Provider (AP) and is given the
signed parameters from the server.

1) The Applet retrieves the browsers server certificate and compares this
with the signed channel bindings from the server without validating the
signature (it is assumed that the applet don't have a TA for this
verification. The applet opens a second secure channel to the service
provider. This might be another host than the one communicating with the
browser. The Applet receives a signed challenge from the SP.

2) The applet generates a public/private key pair and uses the pre-stored
public key of the AP to encrypt a bunch of signed data to the AP

- TLS Session ID of the A-AP session (to prevent replay attacks)
- Its own version (to prevent downgrade attacks by handing the user an old
applet)
- Its public key (to allow an encrypted response
- The signed channel bindings and challenge received from the SP
- It's own observed channel bindings for its two secure channels

This is only sent if the applet agrees with the channel bindings received
for the SP-Browser session

3) The AP validates the signatures from the SP hosts and determines that
these originates from a valid SP. The AP also verifies the channel binding
and session data from the applet. Upon match the AP creates a signed
response to the challenge from the Applet-SP session, including the
channel bindings observed by the applet and also signs the signed channel
bindings from the Browser-SP session.

4) The Applet decrypt the data from AP and verifies its signatures. Upon
success it relay the data to the SP.

5) The SP verifies the response against its own observed channel bindings
towards the Applet and also verifies that the signed end point bindings
obtained from the SP server in the SP-Browser channel is consistent with a
legitimate SP web server.

The applet can now assume that both the browser-SP channel and the
applet-SP channel are consistent with one legitimate SP and MitM free.
The applet will also know that it has a MitM free channel to the AP.

The user will rely on this being setup properly simply by validating the
signature of the signed applet.

The user can now use the applet to authenticate to the AP to obtain
security services from the AP to assist the user in its engagement with
the SP such as payments.
A key in this use case is that the user never should need to authenticate
to the SP to obtain channel binding of both channels to the SP.

/Stefan

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 31 Mar 2011 13:37:37 +0100

Had an interesting discussion about this at lunch and it basically drills
down to the applet's ability to retrieve the browsers end-point channel
bindings (The server certificate used by the browser to connect with the
SP). It seems that this is not possible for some browsers, including IE.

A major objective for this discussed solution is to make sure that the
browser and the applet talk to the same SP entity on a MitM free channel.
So this is a serious issue.

Any thoughts on ways around this problem or are we essentially screwed?

/Stefan

On 11-03-31 3:27 AM, "Stefan Santesson" <[email-masked]> wrote:

>_______________________________________________
>saag mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/saag

---

From: Nico Williams <[email-masked]>
Date: Thu, 31 Mar 2011 12:15:35 -0500

> Any thoughts on ways around this problem or are we essentially screwed?

We talked today for a bit.  There's two issues: a) is the applet
authenticated with the same PKI (trust anchors) as the server? b) how
to extract the server's certificate from the browser so as to use it
as the channel binding.

(b) is possible for some browsers.  For example, Firefox:

https://developer.mozilla.org/En/How_to_check_the_security_state_of_an_XMLHTTPRequest_over_SSL

You'd have to do an XMLHttpRequest for a dummy resource just so you
could learn the server's certificate, but that's fine, I'm sure.

(a) may be trickier -- I don't know if there's a way to configure
different TAs for applet signature validation than for TLS, though I
sure hope there is!  As a last resort you can self-sign the applet
signing certificate and tell the user how to manually validate the
certificate (ha! right, that'll work, not).

Anyways, there's enough here to do a demo.

I've wanted to build a similar thing, but I hadn't thought of signed
applets -- I always figured I'd need a plugin/add-on for the browser,
with all attendant difficulties.  But a plugin/add-on has its
advantages, such as that authentication of it only needs to be done
once, so in the worst case you have an SSH-style leap-of-faith
mitigated by the fact that the leap is one-time, which limits the
opportunities for MITM attacks.  Another advantage of going with a
plugin/add-on approach is that you could use native SSPI/GSS-API
facilities not normally available in the browser.

Quite aside from how you should move forward (solve (a) and (b)), I
think there's an issue of what advice we might be able to give to
browser implementors, likely via the W3C.  Here's my advice to them:

1) Add FF-like XmlHttpRequest interfaces for discovering the server's cert.
2) Add XmlHttpRequest interfaces for setting up an HTTPS channel and
learning its tls-unique channel bindings (to be used in the HTTP
request about to be sent by the script over that channel).
3) And this is the piece de resistance: add JavaScript objects by
which to access GSS-API mechanisms and credentials (through GSS-API or
SSPI interfaces).

(2) is optional, but nice to have.
(1) is absolutely required.
(2) is necessary to avoid the signed applet thing, and would add much,
much user convenience.  (It will also create demand for GSS-API
mechanisms that work outside the enterprise and on an Internet scale.)

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Thu, 31 Mar 2011 12:17:40 -0500

> browser implementors, likely via the W3C.  Here's my advice to them:

Also, I could really use some advice/help with the conveying of the
above to the W3C and browser implementors.  It might be useful to
produce a document with IETF consensus that we could flog at them.
Thoughts?  Help!

Nico
--