On Channel Binding
My Internet-Draft on channel binding is in IETF Last Call. Those of you interested in the topic should go review it. Those who are not aware of this topic but are interested in cryptographic protocols should review it as well. Comments should be sent to ietf at ietf.org and should cc me (my e-mail address is on the document).
So what is channel binding and what’s it for? It’s a way to cryptographically bind end-to-end authentication at the application layer to a secure channel at a lower layer. This cryptographic binding is a way to eliminate MITMs in that secure channel. It is particularly useful to applications that intend to rely on TLS or IPsec for session/transport security.
Channel bindings are also stimulating the development of APIs for IPsec and an unauthenticated mode of IPsec. Without such APIs it is very difficult for application protocols to rely on IPsec. See the IETF BTNS Working Group charter page and presentations made at past IETF meetings of the BTNS WG (see IETF proceedings; the latest ones are here).
Interestingly, Solaris already has a modicum of an IPsec interface in the form of the which, incidentally, relies on “connection latching.” Connection latching is described in the ipsecconf(1M) man page and in a BTNS WG Internet-Draft. The IPsec APIs that the BTNS WG is working on amount to adding fields, if you wish, to the IP_SEC_OPT socket option that deal with local and peer node naming (though that’s not necessarily how Solaris will implement such an extension — the C bindings of the proposed API deal in opaque types and constructor/accessor/destructor functions).