ietf-sasl

[Prev] Thread [Next]  |  [Prev] Date [Next]

Re: Poll: use of TLS channel bindings in SCRAM Kurt Zeilenga Fri May 29 18:00:31 2009



On May 29, 2009, at 3:05 PM, Nicolas Williams wrote:


On Fri, May 29, 2009 at 06:02:39PM -0400, Jeffrey Hutzelman wrote:
--On Friday, May 29, 2009 02:47:39 PM -0700 Kurt Zeilenga
<[EMAIL PROTECTED]> wrote:
I am a bit concerned that that current proposal might preclude certain negotiation strategies from consideration as they would be difficult to retrofit in. In particular, I am concerned that the current proposal might preclude purely in-the-mechanism-exchange negotiation of channel
binding types.

You mean, a strategy in which each mechanism is responsible for managing
negotiation of channel binding types, and we don't get to do that
negotiation until after we've selected a mechanism?

That's not quite my interpretation of what Kurt wants.  Kurt is not
being terribly clear.

I am trying my best to offer clarification.

His primary goal is clearly to allow for YAP and
its dependence on unique channel binding types.

If it wasn't for you and others occasionally bringing up YAP in the context of SCRAM and GS2 discussions, I doubt I would see much (if any) need to comment on it. At present, I don't see anything in recent discussions (aside from suggested changes to RFC 4422) that would preclude publication of YAP (as it now specified, or how I might revise the I-D). [If someone does see something that would interfere with the publication of YAP (as now specified, or how they think I might revise the I-D), I hope they would bring this to my attention (off-list please).]

While certainly I have, do, and will oppose any change to RFC 4422 which unduly restrict the design of mechanisms, my concerns apply generally. I have and will use YAP as well as existing mechanisms as examples of how such changes might unduly restrict the design of particular mechanisms in hopes that folks might see how changes might impact future mechanisms.

I've tried to focus on negotiation solutions suitable for SCRAM and GS2, while considering the possible optional reuse of the solution in future mechanisms. What I like is a solution for SCRAM which could be reused by other mechanisms.

-- Kurt