Re: review of draft-wierenga-ietf-sasl-saml-00

[Sam Hartman <[e-mail]>]

>>>>> "Klaas" == Klaas Wierenga <[e-mail]> writes:

    Klaas> right, so the server would have a list of realm to idp-url
    Klaas> mappings?

In order for the proposal I made to work, the following must be true:

1) The IDP MUST verify that channel binding data is asserted by the
expected RP and has been modified by no other party

2) The client MUST verify that the channel binding data corresponds to
the channel that is in use.

Those two are enough that the user will learn through the web browser if
the connection is under attack.  However, the that's not enough to
defend against a server that fakes successful authentication or to learn
at the SASL protocol level about a channel binding failure.

3)  The client inserts a cookie into the return URL

4) The server or agents under the control of the server not see this
cookie before succesful authentication

5) The server returns the cookie to the client.

I'm not actually sure 3 is possible: I'm not sure whether the return URL
is covered by the signature.  Assuming it's possible, 4 means that the
client must be able to verify that the IDP URL it goes to is one that it
trusts.  So, ultimately, the server can pick however you like, but it
MUST pick from a list of *URLs* that the client trusts.  Anything like
the server mapping an IDP hint to a URL destroys the security property.

Note that it's possible to have multiple modes of operation with
different security properties.  That creates UI challenges, but that is
potentially doable.