Solution

[Dan Lyke]

On Mon, 23 Oct 2006 12:37:44 -0700, Alaric Dailey wrote:
> ok maybe I throw out my idea for solving these problems.
> 1. require SSL for any data transfer from IdP to RP ( assuming data  
> isn't going the other way)

When you say SSL, do you mean that there's a fourth party like a CA  
asserting the identity of the IdP, or just that communication between  
the IdP and the RP is encrypted.

If the former, what attack is this protecting against? One where the  
DNS of *both* the user and the RP have been compromised, or one where  
only one of those has been compromised?

> 2. sign or encrypt the logon token (however or whereever it is  
> stored)

Are we talking about the cookie that the IdP or the RP offers to the  
user, or something else?

> 3. expire the logon after a certain period of time (  )

 From the IdP or the RP? I know I loathe the idea of expiring my login  
tokens from RPs, I end up retyping my LiveJournal password far too  
often as it is. And what happens between the IdP and the user is  
between the IdP and the user, because:

> 4. require ssl for IdPs for logon pages etc...

I'd strongly object to this for one specific reason: It slows the  
adoption of other systems for the user to assert their identity to  
their IdP, key cards, biometrics, whatever, that happen through  
browser enhancements. Yes, that information should be encrypted, but  
requiring SSL as the mode of communication seems like it's locking  
people in to potentially non-optimal solutions.

> 5. Heavily recommend that IdP's use

ie: Run a data center.

I've adminned fully exposed hosts on the net since 1993, I've had  
hosts compromised, had my drives fdisk'd by people trying to cover  
their tracks, I've even been pretty careful about checking SSH  
identities when I log in to a host for the first time, and the one  
time my credit card got stolen was 'cause I left a desktop machine  
logged in and the cleaning staff went rooting through my "back" button.

At some point it comes down to physical security, and if you want a  
secure machine, encase it in concrete and drop it somewhere that  
nobody will find it.

I guess I really don't understand the vulnerability that's been hinted  
at here, and I want to figure out what it is before the protocol gets  
more complex. The vulnerability that's been hinted at involves  
compromisinng the user's hosts file. I don't understand how that'd  
work without it either being a flaw in the IdP's implementation, or  
compromising the RP's hosts file or DNS as well, and if the user's  
machine is compromised anyway, then a keylogger is a hell of a lot  
simpler to install and use.

Would someone who's proposing SSL and CAs go through the spec and give  
me specific section numbers which need to be encrypted or have a  
fourth party (ie: a CA) assert an identity? ie: "Section 3.3: Consumer  
site fetches the Identifier URL by SSL with host authenticated by CA  
in the following list..."?

Until someone gets either that specific with the nature of the  
compromise or that specific with the changes in the spec, we're just  
spinning wheels here, and the only thing all of this banter is doing  
is wasting time.

Dan