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

[Simon Josefsson <[e-mail]>]

Klaas Wierenga <[e-mail]> writes:

> On 5/26/10 9:58 PM, Simon Josefsson wrote:
>
> Hi Simon,
>
>> "Scott Cantor"<[e-mail]>  writes:
>>
>>>> Scott, I'm happy to work with you to figure out if channel binding
>>>> 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 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.
>
> 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