[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: I-D Action:draft-ietf-sasl-channel-bindings-00.txt
On Apr 14, 2009, at 4:24 PM, Kurt Zeilenga wrote:
It is the nature of SASL that such introductions will likely have an
impact upon implementation-specific abstractions to hide the details
of mechanisms from protocol implementations.
For instance, RFC 4422 is mum on the need for a framework
implementations to manage information about identities established a
lower level in order to support EXTERNAL. And with the introduction
of EXTERNAL-*, the framework implementations will likely need to
change. Instead of managing a single external identity (as most
seemed to have done), they will need to manage one per each of the
EXTERNAL-* variants. Today, it seems that the community thinks this
will be enough. But our crystal ball in not 100% clear. Maybe in 5
years, someone will want to introduce a mechanism that requires
framework implementations to provide something different.
As RFC 4422 doesn't itself attempt to abstract away the differences
between mechanisms, it can and should remain mum here.
Likewise, RFC 4422 ought not try to abstract away the differences in
mechanisms that support channel bindings. For instance, presently the
suggestion is mandate two names per mechanisms. But what if tomorrow
we find this isn't good enough. We'd have to update RFC 4422 to allow
introduction of something which was just because we were short-sighted
I do think it appropriate to encourage future mechanisms to be similar
to existing mechanisms where sensible. What I object to is us
mandating future mechanisms be the same in area based upon what we
think is sensible today.
RFC 4422, I think, tries very hard to leave the future open. This
proposal, I think, tries very hard to close our future.