Solving a potential SAML MITM-problem

[Anders Rundgren <anders.rundgren@telia.com>]

"Reprinted" from the PKIX-list

Hi All,

I wonder if you security experts could take some of your precious time to look 
on a problem that affect systems based on domain security in conjunction
with user's with web-browsers.  To this category belong: Purple, Shibboleth, 
MSFT's Passport(!), VISA's 3D Secure, and the coming OAISIS security services
standard (some use-cases).

ENTITIES:

Client: browser-user associated with an Attribute Authority (AA). 
Relying Party (RP).  The RP has a trust relationship with the AA.
The client's relation to the RP is indirect (typically an AA representative).

SCENARIO: 

The client wants to logon on a RP-controlled web-server with the use of an on-the-fly
created "ticket" that an AA web-server issues to the client on demand.  The ticket
contains a redirect to an RP URL.

PROBLEM DESCRIPTION:

The client (user) will (hopefully) to his/her "own" organization (AA), long-term authenticate using
client-certificates which eliminates MITM-attacks using SSL.  At least the AA is protected from fake clients.

A potential problem with MITM SSL-attacks remains with the redirected client-to-RP server connection 
as it is not terminated by client-certificates as they are replaced by "tickets" that has no
key/cert-binding to the client.  I.e. a MITM-attacker could during the redirected SSL-connect to
the RP (ticket consumer) "snatch" the ticket and get access to the client's resources at the RP.
This attack on SSL has been described by others so it exists although it normally requires user
to accept a rogue cert.

So what to do? 

"Tweaking" SSL seems highly unlikely and I haven't come up with any nice tweaks that 
would work anyway. 

But I have found one *possible* way that could be implemented if schemes like Purple,
Shibboleth and OASIS security services become mainstream: 

The AA (Attribute authority making redirected tickets) could in the redirect indicate 
that it expects the RP server-cert to be signed by a CA known/accepted by the AA through the
use of an OCSP lookup URL + certID for the OCSP signer cert which is specified by the AA and
that there must be one-to-one redirect host-name correlation or  the redirect will not be carried out.
I.e. this would be a [technically] rather simple "fix" in a browser.  Could be migrated into
browsers any day without giving unwanted side-effects or incompatibilities.

What do U think? 

Regards 
Anders Rundgren

SAML "lurker"