Adding channel bindings to signed SAML Requests

["Scott Cantor" <cantor.2@osu.edu>]

I had a long on-list conversation a few weeks ago with Nico Williams about
adding channel bindings to the SASL/GSS mechanism I proposed based on ECP.
The purpose of the CBs in that context was to link the SAML exchange to the
generally unauthenticated TLS connection between the client and the server.

We came up with a way to do this through the IdP as a broker, and I have
plans to write all that up, but while I was thinking about the problem, it
occurred to me that this might be generalizable to other request/response
cases in SAML. In particular, I've always had a conceptual problem with
relying on signed SAML requests to authenticate the SAML SOAP binding,
rather than client TLS certificates. It's quite a leap from "the message was
signed within the last few minutes" to "there's no MITM".

Obviously sometimes you may not care about a MITM, but sometimes you do, and
it's pretty expensive to do extra encryption operations when there's already
nominally a TLS layer. Particularly on the server end where you might be
returning user data, and would be able to enforce the use of the CB before
returning the data (or toggle to returning the data encrypted at the XML
layer).

What I was thinking was that it would be a simple matter to define an
extension to carry channel bindings, and that extension could be used either
in a SOAP header or as a SAML Request extension. My GSS use case would use
both of those (client uses the SOAP header, RP server uses the Request
extension in its AuthnRequest). But a simple SOAP exchange (e.g. attribute
queries) could include the CB data in the Request.

This seems like a pretty straightfoward use of the concept of CB to me. You
sign the message, using an authenticated key, and the signature over the CB
data (usually the server cert) guarantees the server that the client was
talking to it and not some other guy.

Am I missing something, or is this reasonable?

It's not a round trip ahead of the requester sending its message, so you
don't get the benefit on the requester side, but on that side you usually
know who you're talking to already (assuming server TLS). I think it's a
nice potential win for the responder end.

-- Scott