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

From: Sam Hartman <[email-masked]>
Date: Tue, 25 May 2010 16:36:30 -0400

[Tim copied because this document came up on a recent call]

Hi.  I've been promising the authors of the SASL SAML mechanism a review
for a while and I realized that the only way it would happen is if I sit
down and write it up.

For those who haven't read the document, the idea is to permit the use
of an existing SAML IDP for SASL authentication.  The flow is as
follows:

1) The server sends a URI to redirect to to the client.

2) The client pops up a browser and sends it to that URI

3) The client sends an empty response to the server

4) At some later point the server says authentication succeeded or
failed.

What's presumably happening behind the covers is that the client is
interacting with a browser and an identity provider.  Eventually if
authentication is successful the client will be directed back to a URI
on the server.  Once the authentication is received  over this URI  then
the server will respond that SASL has succeeded.

I think this mechanism may be the best approach possible given the
technical constraints, especially in the case where the IDP URI is
provided by the server or where an IDP discovery mechanism is used.

However the security properties of this mechanism are a lot closer to
SASL plain or anonymous than more modern SASL mechanisms such as SCRAM.
It's not as bad as plain: long-term secrets are not sent over the wire
in the clear.  However it seems vulnerable to the following attacks:

1) The client has no assurance provided by this mechanism that it is
talking to the intended server.  So, this mechanism provides no
protection against man-in-the-middle attacks.

2) There is no channel binding or security layer provided.  If this
mechanism is used with TLS, there is no assurance that  the endpoints of
TLS are related to the endpoints of SASL.

3) The client has no to weak assurance that authentication actually
happened.  The server  could return successful authentication at any
point after the client sends the empty response.  We've learned from
discussion of phishing attacks that often it's valuable to force someone
to believe they have authenticated to a site when they have not done
so.  They will be willing to enter confidential information--after all,
they did manage to log in.

4) The fact that the server provides the IDP or IDP discovery URI opens
the system to fairly classic phishing attacks.

Some of these attacks are addressed by using TLS between the client and
server.  That's only true if certificates are validated and if the user
does not accept invalid certificates.  It's also important that the name
in the certificate be properly checked.

A mechanism similar to this could provide significantly better security
guarantees if the client knew its own IDP URI.

1) Channel binding could be provided.  In some portion of the
authentication request covered by the signature, the SASL server
includes the channel binding data for the channel.  The client can
verify that the correct channel binding data is included.  The client
cannot yet tell that there is no man in the middle.

2) The return URI should provide some space for the client to include
some token.  The client includes this token in the return URI as it
passes the authentication request to the browser.  The server echoes
this returned token back to the client in the success message.  Because
the server has never seen this token before it provides some assurance
that the server interacted with the IDP.  Naturally this only provides
value if the IDP is selected by the client rather than the server.

I think that if these two additions can be fleshed out and if there are
significant use cases where clients could know their IDP, then the
mechanism should be modified to support these use cases.

However, as I mentioned, I don't know how to do better than the current
mechanism given the common requirement that the server provide an IDP
discovery URI.  I do understand that requirement is important.  Any
mechanism we publish in this space should have a clear applicability
statement and a good explanation of these attacks in the security
considerations section.

---

From: "Scott Cantor" <[email-masked]>
Date: Tue, 25 May 2010 16:46:39 -0400

> guarantees if the client knew its own IDP URI.
...
> mechanism should be modified to support these use cases.

That is in essence the reason I am still planning to propose an alternative
design that makes direct use of the SAML profile that was designed for this
basic scenario of a client that's been modified. It does not impose
significant technical barriers to clients (they don't have to know much
about SAML or create XML Signatures or any of the other common complaints).

I believe the cost of deploying a client is such that it's absolutely
essential to use that change to move discovery to it.

I was hoping to have an I-D submitted by now, but I haven't found the time.
Hopefully fairly soon.

> discovery URI.  I do understand that requirement is important. 

I haven't seen a compelling argument for why it's important. It's actually
been a problem for federation since its inception, and when you can avoid
it, you really have to.

It's something you can work around in cases in which the application relies
on identifiers that resemble email addresses and can be used to perform an
implicit kind of discovery, but that's not a generalized case, and it still
results in the additional security issues you mentioned.

-- Scott

---

From: Klaas Wierenga <[email-masked]>
Date: Wed, 26 May 2010 16:17:34 +0200

Hi Sam,.

Thanks for your review! I agree with most of your observations. To 
address your mitigating measures:

- IdP discovery

I don't think that in the use cases I am thinking of currently (jabber, 
imap etc.) IdP discovery is that important. I can very well live with 
having the client specify the IdP instead of relying on a discovery url 
provided by the server. I wanted to be as flexible as possible, but 
given your and others feedback I can change that. I see 2 options: 
introduce an "IdP hint" provided by the client and fall back to one 
provided by the server and discuss this in the security considerations 
or have the client always provide the IdP. I guess you prefer the 
latter, what do others think?

- token provided by client

Interesting idea. I had been toying with the idea of having the server 
provide a nonce, but that would not have helped. I have to think if/how 
that could be done.

- channel binding

How useful is channel binding if there is still a MITM possible?

Thanks again,

Klaas

---

From: Klaas Wierenga <[email-masked]>
Date: Wed, 26 May 2010 16:23:10 +0200

On 5/25/10 10:46 PM, Scott Cantor wrote:

Scott,

> about SAML or create XML Signatures or any of the other common complaints).

I am assuming you refer to the ECP profile. How different would this be 
from the SASL point of view? I.e. what difference would it make on the 
"SASL wire"?

> been a problem for federation since its inception, and when you can avoid

There is no compelling argument other than that this is the way it is 
done in most identity federations today and I wanted to stay as close as 
possible to today's implementations and not fall into the trap of trying 
to introduce something new and at the same time try to fix all other 
problems in the world.

> results in the additional security issues you mentioned.

Agreed.

Klaas

---

From: "Scott Cantor" <[email-masked]>
Date: Wed, 26 May 2010 11:08:29 -0400

> from the SASL point of view? I.e. what difference would it make on the

Significantly different from yours, since there's no empty response and no
callback communication between the SP and the IdP, but I believe it can be
compatible with SAML ECP on the IdP side, and is essentially a direct
mapping from using HTTP as a "container" for the SP/client SOAP envelopes to
using the SASL messages.

It suffers the same MITM issues that Sam mentioned, since that's what
happens if you punt that to TLS without any channel bindings. I'm not in a
position to address that without help, I just believe there's a better
non-web flow here. It also creates a much more flexible field for phishing
to be addressed, since the client/IdP exchange is not a browser and a web
site.

The only issue to address in translating the profile over to SASL is the
fact that in a non-web case there's no real "responseURL" involved, which is
something that's baked into the standard ECP profile, but I think it can be
"emulated" with no particular effort in the interest of compatibility, or
removed at the cost of same.
 
> to introduce something new and at the same time try to fix all other

This makes sense if you're remaining compatible with something people *want*
to deal with, but IdP discovery is the last thing anybody operating an SP
*wants* to deal with. It's a gigantic usability problem, and arguably the
biggest reason why federation has scaling issues.

Anyway, it's on me to produce the draft, which I've started on (using yours
as a starting point, which I hope is ok).

-- Scott

---

From: Klaas Wierenga <[email-masked]>
Date: Wed, 26 May 2010 17:42:02 +0200

> mapping from using HTTP as a "container" for the SP/client SOAP envelopes to

right, but that than comes at the expense of more complex SASL 
interaction, i.e. you are going to send the AuthenticationStatement as a 
response to the AuthentionRequest challenge over SASL, right?

> biggest reason why federation has scaling issues.

ok, fair point

> as a starting point, which I hope is ok).

obviously! Looking forward to the draft.

Klaas

---

From: "Scott Cantor" <[email-masked]>
Date: Wed, 26 May 2010 11:55:21 -0400

> response to the AuthentionRequest challenge over SASL, right?

It's a SAML Response (the statement is well buried), but why is that more
complex than an empty response, running a web server to handle a SSO
response, and then making a callback?

I think it's a much simpler flow. Request, Response.

I'm coming at this with probably insufficient SASL knowledge, though I'm
trying to rectify that. Maybe I'm missing something.

-- Scott

---

From: Sam Hartman <[email-masked]>
Date: Wed, 26 May 2010 14:26:30 -0400

>>>>> "Scott" == Scott Cantor <[email-masked]> writes:

    >> I am assuming you refer to the ECP profile. How different would
    >> this be from the SASL point of view? I.e. what difference would
    >> it make on the "SASL wire"?

    Scott> It suffers the same MITM issues that Sam mentioned, since
    Scott> that's what happens if you punt that to TLS without any
    Scott> channel bindings. I'm not in a position to address that
    Scott> without help, I just believe there's a better non-web flow
    Scott> here. It also creates a much more flexible field for phishing
    Scott> to be addressed, since the client/IdP exchange is not a
    Scott> browser and a web site.

Scott, I'm happy to work with you to figure out if channel binding
support is possible in your approach.

---

From: Sam Hartman <[email-masked]>
Date: Wed, 26 May 2010 14:28:42 -0400

>>>>> "Klaas" == Klaas Wierenga <[email-masked]> 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.

---

From: "Scott Cantor" <[email-masked]>
Date: Wed, 26 May 2010 14:41:32 -0400

> support is possible in your approach.

I plan to take you up on it. To ease the process of comparing the
approaches, I think it's easiest to produce a simple draft initially, which
highlights some of the issues you mentioned, but leaves things as is for the
same compatibility reasons that Klaas had. The result may be a merging of
the proposals, or not.

Related to this, for example, I'm in favor of supporting a way to tie the
SAML assertion in the response to a key at the TLS layer (holder of key via
client TLS, in other words). That's an addition to the SAML profile I'm
basing this work on, which is why I'm not starting there, to simplify the
compatibility story. I probably will go back to OASIS to get a HoK version
of the ECP profile created, and then I can just reference it.

I'm fairly far along since starting on this last night so I should have
something soon.

-- Scott

---

From: "Scott Cantor" <[email-masked]>
Date: Wed, 26 May 2010 14:43:30 -0400

> is covered by the signature.

The signature in a SAML redirect binding URL is over a defined set of
parameters in a particular order, and is not perturbed by additional
parameters (though of course they are not protected by it).

-- Scott

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 26 May 2010 21:58:50 +0200

> of the ECP profile created, and then I can just reference it.

I would prefer if channel bindings is done in a GS2 compatible way, to
allow a SAML SASL mechanism to be usable as a GSS-API mechanism as well.
By using the GS2 prefix, you also get support for authorization
identities.

If authors are interested here, I could help with the GS2 prefix part so
that it causes minimal confusion for non-GSS-API people and still allows
that variant.  I made this suggestion for the OpenID SASL mechanism as
well.

/Simon

---

From: "Scott Cantor" <[email-masked]>
Date: Wed, 26 May 2010 16:17:34 -0400

> that variant.  I made this suggestion for the OpenID SASL mechanism as

I'm completely open to any and all SASL/GSS-related suggestions and
improvements. This is sort of a 5 year old work item for me that dates back
to SAML 2's initial design work, which I intended to demonstrate as a fit
for SASL and never got the time or the perceived interest to get done.

I just want to get a proposal out that "fits" my original intention for how
this would look, and then let the experts on the non-SAML parts whack it
into shape once there's an understanding of the compatibility trade-offs.

-- Scott

---

From: Klaas Wierenga <[email-masked]>
Date: Thu, 27 May 2010 14:34:14 +0200

> trying to rectify that. Maybe I'm missing something.

No sorry, what I meant to say is that at the client it is easier to do 
"please open a browser with the following url" as opposed to "here is a 
saml assertion, deal with it and send me back your 
AuthenticationStatement", for the SASL interaction it is not more 
difficult indeed.

Klaas

---

From: Klaas Wierenga <[email-masked]>
Date: Thu, 27 May 2010 17:19:16 +0200

On 5/26/10 8:28 PM, Sam Hartman wrote:

Sam,

Just to understand, what does channel binding buy you if you still can 
not prevent the MiTM? The SAML interactions can:

- give you a return url to the Relying Party and a 'transaction id'
- have you authenticate at your IdP
- have the IdP verify that the RP is a 'trusted' one
- have the (trusted) SP verify that it indeed issued that authentication 
request

Klaas

>>>>>> "Klaas" == Klaas Wierenga<[email-masked]>  writes:
>

---

From: Klaas Wierenga <[email-masked]>
Date: Thu, 27 May 2010 17:27:31 +0200

On 5/26/10 9:58 PM, Simon Josefsson wrote:

Hi Simon,

> "Scott Cantor"<[email-masked]>  writes:
>

Thanks for the kind offer! My concern is that one of the design goals I 
started out with was not having to touch the existing IdP's. I lack here 
knowledge (have to read up on GSS-API), but would that be possible?

Klaas

---

From: Martin Rex <[email-masked]>
Date: Thu, 27 May 2010 20:00:09 +0200 (MEST)

Klaas Wierenga wrote:
> not prevent the MiTM?

That is a misunderstanding.  (Cryptographic) channel bindings reliably
protects you from MitM attacks.  But it can not protect you from
an attacker that can successfully impersonate a "trusted" server,
and neither from an inappropriately trusted "rogue" server.

Successfully impersonating a "trusted" server does not necessarily
require a full compromise of that server.  Being able to pass those
few superficial checks that the client performs in order to verify
the authentication of a server is perfectly sufficient -- and is
usually much easier than breaking into the real server in order to get
hold of its credentials.  Think of PKI, X.509 certs, server endpoint
identification similar to HTTP over TLS (rfc2818) and the problem
of lots of software dealing with embedded NUL chars in names,
or the problem of huge amounts of interchangeably-trusted root CAs.

-Martin

---

From: Sam Hartman <[email-masked]>
Date: Thu, 27 May 2010 14:10:34 -0400

>>>>> "Martin" == Martin Rex <[email-masked]> writes:

    Martin> Klaas Wierenga wrote:
    >> > 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.
    >> 
    >> Just to understand, what does channel binding buy you if you
    >> still can not prevent the MiTM?

Ah, I think I finally understand the question.

So, the channel binding does detect the MITM, but the question is how is
this communicated and to whom.

the two changes above are sufficient that the user would get an
authentication failure error in the browser.  However it's not
sufficient that the client application would be able to learn of this
failure without somehow parsing the web page.  The other changes I
proposed were sufficient for both the web browser and the client
application to learn of the attack.

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 28 May 2010 08:19:16 +0200

Klaas Wierenga <[email-masked]> writes:

> Thanks for the kind offer! My concern is that one of the design goals
> I started out with was not having to touch the existing IdP's. I lack
> here knowledge (have to read up on GSS-API), but would that be
> possible?

I am not certain.  The important part is traditionally to make the
client and server agree on the channel binding, and refuse connections
when they don't match.  I don't see any value in having the IdP also
necessarily have to be involved in this negotiation.

The transfer of the channel binding needs to be integrity protected, and
it needs to be tied with the authentication.  Thus, a simple way to
achieve this would be for the client to include it in a attribute that
it signs and sends to the server.  I don't think the IdP would need to
do anything with a field like that, but it needs to be preserved and
presented to the server.  I'm not enough of a SAML expert to tell
whether this is easy to achieve or not?  I do operate a SAML server for
a company, and when we did the integration with some RPs, there were
many places were you could put extension fields, so I strongly suspect
the answer is "yes" but it needs to be confirmed.

/Simon

---

From: Sam Hartman <[email-masked]>
Date: Fri, 28 May 2010 08:40:49 -0400

Simon, I think the IDP may end up involved in the channel binding
discussion because the client and server may happen not to have another
mechanism for an integrity protected channel.  In cases where the client
and server directly share a key or a key falls out of the SAML exchange,
I agree with you, no IDP interaction is required.

---

From: Simon Josefsson <[email-masked]>
Date: Sat, 29 May 2010 11:34:49 +0200

> I agree with you, no IDP interaction is required.

Right.  I think there is some advantage in having a key fall out of a
SAML exchange, but it may also make a SAML SASL mechanism unnecessarily
complex.  I'm concerned that IDPs (and potentially other middle parties)
can see the TLS Finished messages for connections between clients and
servers though.

/Simon