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

[Klaas Wierenga <[e-mail]>]

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

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