Alexey Melnikov made some comments in private. They should probably go
to the ietf(_at_)ietf(_dot_)org list. Their gist: there should be an IANA
registry
of channels with channel bindings, their specifications, and a
well-known string to be prefixed to said channels' channel bindings
octet strings.
Alexey has agreed to propose text and I've agreed to consider it (though
I believe such a registry to not be necessary, I also believe it not
harmful, and if Alexey finds it useful then I don't object to that
addition).
Also, Sam Hartman wants the Introduction to be clearer on this: that
though this is derived from the GSS-API notion of channel binding it is
not just a GSS thing.
With respect to Sam's comment I propose the following addition:
The term "channel binding" as used in this document derives from the
GSS-API [RFC2743], which has a channel binding facility that was
intended for binding GSS-API authentication to secure channels at
lower network layers. The purpose and benefits of the GSS-API
channel binding facility were not discussed at length, and some
details were left unspecified. Now we find that this concept can be
very useful, therefore we begin with a generalization and
- formalization of "channel binding."
+ formalization of "channel binding" independent of the GSS-API.
+
+ Although inspired by and derived from the GSS-API, the notion of
+ channel binding described herein is not at all limited to use by
+ GSS-API applications. We envision use of channel binding by
+ applications that utilize other security frameworks, such as SASL
+ [RFC4422] and even protocols that provide their own authentication
+ mechanisms (e.g., the KDC exchanges of Kerberos V [RFC4120]). We
+ also envision use of the notion of channel binding in the analysis of
+ security protocols.
Nico
--
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf