RE: [security-services] question re saml-channel-binding-ext

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

> Sorry to be late in the process with questions.

They're not substantive issues, so please do vote because I need these documents finalized so that I can complete the GSS-API draft at IETF.

> I find it hard to understand from the spec if the channel binding is limited to a
> single request/response, or is there a way to reuse an established binding to
> do additional exchanges without additional authentication and protection at
> the assertion level.

The point of channel binding is to connect an unauthenticated channel sitting underneath an application protocol to the application protocol if that protocol is secured with SAML messages. In practice, the channel is TLS. The application can be anything, but is generally a GSS-API protected application because that's all that uses CB today.

So the basic use case is to extend SAML to handle message content that allows SAML SSO over TLS to actually authenticate the TLS endpoints. If that's done, then a client and server actually know they're talking to each other, if they trust the SAML exchange, and the rest of the application session can be associated strongly with a TLS session if you don't put a bunch of TLS offloading hardware in the middle.

The profile that's actually in the document is a different animal of a specialized nature. I only included it as a thought experiment and because XML Encryption was such a mess that having a way to figure out if you have a confidential channel before you return data seemed like a nice trick.
  
> Also people might find it useful to get an overview of the use of channel
> binding with respect to holder-of-key and bearer tokens.

Channel binding is too low level for that, it's a building block for other profiles to use. It doesn't directly involve assertions in and of themselves.

The ECP spec more fully fleshes out CB behavior and in that context, I can explain what it does and how.

-- Scott