"Problem and Applicability Statement for Better Than Nothing Security (BTNS)", Joseph Touch, David Black, Yu-Shun Wang, 3-Oct-07. ( bytes)

The Internet network security protocol suite, IPsec, consisting of IKE, ESP, and AH, generally requires authentication of network layer entities to bootstrap security. This authentication can be based on mechanisms such as pre-shared symmetric keys, certificates and associated asymmetric keys, or the use of Kerberos. The need to deploy authentication information and its associated identities to network layer entities can be a significant obstacle to use of network security. This document explains the rationale for extending the Internet network security suite to enable use of IPsec security mechanisms without authentication. These extensions are intended to protect communication in a "better than nothing" (BTNS) fashion. The extensions may be used on their own (Stand Alone BTNS, or SAB), or may be useful in providing network layer security that can be authenticated by higher layers in the protocol stack, called Channel Bound BTNS (CBB). This document also explains situations in which use of SAB and CBB extensions are appropriate. Conventions used in this document In examples, "C:" and "S:" indicate lines sent by the client and server respectively.

"Better-Than-Nothing-Security: An Unauthenticated Mode of IPsec", Nicolas Williams, Michael Richardson, 4-Jan-08. ( bytes)

This document specifies how to use the Internet Key Exchange (IKE) protocols, such as IKEv1 and IKEv2, to setup "unauthenticated" security associations (SAs) for use with the IPsec Encapsulating Security Payload (ESP) and the IPsec Authentication Header (AH). No changes to IKEv2 bits-on-the-wire are required, but Peer Authorization Database (PAD) and Security Policy Database (SPD) extensions are specified. Unauthenticated IPsec is herein referred to by its popular acronym, "BTNS" (Better Than Nothing Security).

"IPsec Channels: Connection Latching", Nicolas Williams, 14-Apr-08. ( bytes)

This document specifies, abstractly, how to interface applications and transport protocols with IPsec so as to create "channels" by latching "connections" (packet flows) to certain IPsec Security Association (SA) parameters for the lifetime of the connections. Connection latching is layered on top of IPsec and does not modify the underlying IPsec architecture. Connection latching can be used to protect applications against accidentally exposing live packet flows to unintended peers, whether as the result of a reconfiguration of IPsec or as the result of using weak peer identity to peer address associations. Weak association of peer ID and peer addresses is at the core of Better Than Nothing Security (BTNS), thus connection latching can add a significant measure of protection to BTNS IPsec nodes. Finally, the availability of IPsec channels will make it possible to use channel binding to IPsec channels.

"IPsec Application Programming Interfaces", Michael Richardson, Nicolas Williams, Miika Komu, Sasu Tarkoma, 18-Feb-08. ( bytes)

IPsec based security is usually transparent for applications and and they have no standard APIs for gathering information about protected network connections and for detecting the underlying security mechanisms. This document specifies an API that increases the visibility of IPsec to applications. The API allows applications to allow BTNS extensions, control the channel bindigs, and control also other security properties related to IPsec.

"An abstract interface between applications and IPsec", Michael Richardson, 19-Feb-08. ( bytes)

This document explains in the abstract (no language bindings are provided) how an application may learn that IPsec has been applied to a conversation or specify that IPsec should be used. Though this is useful in general it is particularly useful for applications that wish to use BTNS (Better Than Nothing Security -- a mode of IPsec keying), either in conjunction with channel binding or otherwise.

Return to Internet-Draft directory.

Return to IETF home page.