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

[Sam Hartman <[e-mail]>]

[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.