On Mon, Nov 03, 2008 at 02:47:02AM -0600, Nicolas Williams wrote:
> Now, if anyone had built a language binding based strictly on RFC2743
> then they'd have only an OCTET STRING input. What to do? Well, since
> those "network addresses" in the RFC2744 channel binding structure
> turned out to be utterly useless[*] and since such a language binding
> would not have intended for network-addresses-as-channel-bindings, the
> simplest choice is as given above.
I left out the footnote I'd intended to add:
[*] The only GSS-API application to use network addresses as channel
bindings that I know of _was_ the MIT krb5 ftp/ftpd. And it didn't
use them for the main purpose of channel bindings (which is to
detect MITM, and if there isn't one, defer session protection to
lower-layer channel). Instead the MIT krb5 ftp/ftpd use of network
addresses as channel bindings simply made it impossible to traverse
NAT.
Now, NAT is an MITM, but it's one everyone wants to successfully
traverse, and one which does not compromise any end-to-end security
protocols (IPsec, TLS, SSHv2, ...).
The thing is that network addresses as channel bindings provide no
security unless coupled with IPsec, but that coupling would be very
loose: the application has no idea whether it's there at all, not
without checking local IPsec configuration. Which is why we're
pursuing draft-ietf-btns-connection-latching (IPsec channels), BTNS
itself, and true cryptographic channel bindings for IPsec channels.
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
