Subject: Solving a hard MITM-problem

From: "Anders Rundgren" <[email-masked]>
Date: Fri, 13 Apr 2001 12:40:20 +0200

Hi All,
Sorry for the ramblings regarding Domain-PKI etc.

Nevertheless I wonder if you security experts could (without refraining
to the impossibility of making secure serves, or claims that the EU
will have a global employee- PKI running in September), seriously take a 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.

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 DECRIPTION:

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