|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
##
##
##
##
##
## BTNSwg
##
##
##
##
##
##
##
##
##
##
##
##
##
|
|
|
|
|
|
|
|
|
Last Update: Apr 15, 2008
-- Color Legend: RFC Editor Queue
/ Processed by IESG
/ ID Exists
/ Recently Expired
-- Each I-D name is a link to an I-D description, which points to a text version, a two-page and fit-in-window PDF version, as well as the IETF Tools' HTML version.
|
|
|
|
|
|
|
|
|
##
##
##
##
##
## BTNSwg
##
##
##
##
##
##
##
##
##
##
##
##
##
|
|
|
|
|
|
|
|
|
|
|
|
##
##
##
##
##
## BTNSwg
##
##
##
##
##
##
##
##
##
##
##
##
|
|
|
|
|
|
| The charter of the BTNS working group
is reported below.
|
|
|
|
Current Internet Protocol security protocol (IPsec) and Internet Key
Exchange protocol (IKE) present somewhat of an all-or-nothing
alternative; these protocols provide protection from a wide array of
possible threats, but are sometimes not deployed because of the need
for pre-existing credentials. There is significant interest in
providing anonymous (unauthenticated) keying for IPsec to create
security associations
(SAs) with peers who do not possess authentication credentials that
can be validated. Examples of such credentials include self-signed
certificates or "bare" public keys. This mode would protect against
passive attacks but would be vulnerable to active attacks.
The primary purpose of this working group is to specify extensions to
the IPsec architecture, and possibly extensions or profiles of IKE, so
that IPsec will support creation of unauthenticated SAs. The goal of
the
resulting RFCs is to enable and encourage simpler and more rapid
deployment of IPsec in contexts where use of unauthenticated SAs is
deemed
appropriate, to enable and encourage the use of network security where
it has been difficult to deploy--notably, to enable simpler, more
rapid deployment.
Any IKE and IPsec extensions/profiles developed in this WG must not
undermine the security facilities already defined for IPsec.
Specifically, the access control facilities that are central to IPsec
must not be degraded when unauthenticated SAs are employed
concurrently with authenticated SAs in the same IPsec implementation.
Two related problems emerged during the discussion of this problem.
First, there is a desire in the KITTEN, RDDP, NFSv4 and potentially
other working groups to make use of unauthenticated IPsec SAs, and
later cryptographically bind these SAs to applications, which perform
their own authentication. The specification of how this binding is
performed for IPsec and the specification of how the binding interacts
with application authentication protocols are out of scope for this
working group. However, interactions between this cryptographic
channel binding and IPsec (e.g., the PAD, SPD, SAD, etc.) are expected
to be similar to those for the unauthenticated mode with no
binding. To avoid duplication of effort, This working group needs to
consider how to support channel bindings when developing extensions to
IPsec, specifically the PAD and SPD elements.
Secondly, BTNS and the channel bindings work both encourage IPsec to
be used to secure higher layer protocols. As such we need to determine
what information these higher layer protocols need from IPsec.
Two proposals are under discussion for providing unauthenticated SA
support for IPsec: bare RSA keys transported by IKE and self-signed
certificates transported by IKE.
The WG has the following specific goals:
|
|
| a) |
Develop an informational framework document to describe the
motivation and goals for having security protocols that support
anonymous keying of security associations in general, and IPsec and
IKE in
particular
|
| b) |
Develop an informational applicability statement, describing a set
of threat models with relaxed adversary capability assumptions, to
characterize the contexts in which use of unauthenticated SAs is
appropriate
|
| c) |
If necessary, specify standards-track IKE extensions or profiles
that support one or both of the bare RSA keys or self-signed
certificates
|
| d) |
Specify standards-track extensions to the SPD and PAD to support
unauthenticated SAs for IPsec and cryptographic channel bindings for
IPsec
|
| e) |
Develop an informational document describing the interfaces that
IPsec implementations should provide to allow IPsec SAs to be used to
secure higher layer protocols
|
|
|
The final goal is expected to complement work going on elsewhere in
establishing best current practice for higher layer protocols secured
by IPsec.
|
|
|
|
|
|
|
|
##
##
##
##
##
## BTNSwg
##
##
##
##
##
##
##
##
##
##
##
##
##
|
|
|
|
|
|
|
|
| -
|
|
|
|
|
|
|
|
|
##
##
##
##
##
## BTNSwg
##
##
##
##
##
##
##
##
##
##
##
##
##
|
|
|
|
|
|
|
|
| -
|
|
|
|
|
|
|
|
|
##
##
##
##
##
## BTNSwg
##
##
##
##
##
##
##
##
##
##
##
##
##
|
|
|
|
|
|
|
|
|
|
| | |
btns-core-06
IESG Evaluation::
AD Followup
Jan 3, 2008
(16 p.)
[pdf(2)]
[html]
|
N. Williams
M. Richardson |
|
Better-Than-Nothing-Security: An Unauthenticated Mode of IPsec |
|
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).
|
|
|
| |
| Up List |
Intended Status: | Standards Track |
|
|
|
|
|
|
|
|
| | |
btns-prob-
and-applic-06
IESG Evaluation::
Revised ID Needed
Oct 2, 2007
(26 p.)
[pdf(2)]
[html]
|
J. Touch
D. Black
Y. Wang |
|
Problem and Applicability Statement
for Better Than Nothing Security (BTNS) |
|
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.
|
|
|
| |
| Up List |
Intended Status: | Informational |
|
|
|
|
|
|
|
|
|
|
|
|
##
##
##
##
##
## BTNSwg
##
##
##
##
##
##
##
##
##
##
##
##
##
|
|
|
|
|
|
|
|
|
|
| | |
btns-abstract-api-01
ID Exists
Feb 17, 2008
(22 p.)
[pdf(2)]
[html]
|
M. Richardson |
|
An abstract interface between applications and IPsec |
|
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.
|
|
|
|
|
|
|
|
|
|
|
| | |
btns-c-api-03
ID Exists
Feb 19, 2008
(15 p.)
[pdf(2)]
[html]
|
M. Richardson
N. Williams
M. Komu
S. Tarkoma |
|
IPsec Application Programming Interfaces |
|
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.
|
|
|
| |
| Up List |
Intended Status: | Informational |
|
|
|
|
|
|
|
|
| | |
btns-connection-
latching-07
ID Exists
Apr 14, 2008
(24 p.)
[pdf(2)]
[html]
|
N. Williams |
|
IPsec Channels: Connection Latching |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
##
##
##
##
##
## BTNSwg
##
##
##
##
##
##
##
##
##
##
##
##
##
|
|
|
|
|
|
|
|
| -
|
|
|
|
|
|
|
|
|
|
|
