[Openswan dev] The IESG: WG Action: Better-Than-Nothing Security (btns)

Fri Apr 8 22:40:32 EDT 2005

--- begin forwarded text

To: dev at lists.openswan.org
Date: Fri, 08 Apr 2005 11:20:04 -0400
From: Michael Richardson <mcr at sandelman.ottawa.on.ca>
Subject: [Openswan dev]
	The IESG: WG Action: Better-Than-Nothing Security (btns)
Sender: dev-bounces at openswan.org

>From ietf-announce-bounces at ietf.org  Fri Apr  8 11:11:34 2005
Return-Path: <ietf-announce-bounces at ietf.org>
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71])
	by lox.sandelman.ottawa.on.ca (8.11.6p3/8.11.6) with ESMTP id j38F9HU03163
	for <mcr at sandelman.ottawa.on.ca>; Fri, 8 Apr 2005 11:09:18 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DJujb-0004aq-Be; Fri, 08 Apr 2005 10:45:23 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DJujZ-0004al-FE
	for ietf-announce at megatron.ietf.org; Fri, 08 Apr 2005 10:45:21 -0400
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27353;
	Fri, 8 Apr 2005 10:45:18 -0400 (EDT)
Message-Id: <200504081445.KAA27353 at ietf.org>
From: The IESG <iesg-secretary at ietf.org>
To: IETF-Announce at ietf.org
Date: Fri, 08 Apr 2005 10:45:18 -0400
Cc: Pekka Nikander <Pekka.Nikander at nomadiclab.com>, anonsec at postel.org,
   Love Hornquist Astrand <lha at stacken.kth.se>
Subject: WG Action: Better-Than-Nothing Security (btns)
X-BeenThere: ietf-announce at ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: ietf-announce.ietf.org
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf-announce>,
	<mailto:ietf-announce-request at ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf-announce at ietf.org>
List-Help: <mailto:ietf-announce-request at ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf-announce>,
	<mailto:ietf-announce-request at ietf.org?subject=subscribe>
Sender: ietf-announce-bounces at ietf.org
Errors-To: ietf-announce-bounces at ietf.org
X-Spam-Status: No, hits=-6.6 required=4.0
	tests=BAYES_01
	version=2.52
X-Spam-Level:
X-Spam-Checker-Version: SpamAssassin 2.52 (1.174.2.8-2003-03-24-exp)

A new IETF working group has been formed in the Security Area. For additional
information, please contact the Area Directors or the WG Chairs.

+++

Better-Than-Nothing Security (btns)
======================================

Current Status: Active Working Group

Chair(s):
Pekka Nikander <Pekka.Nikander at nomadiclab.com>
Love Hornquist Astrand <lha at stacken.kth.se>

Security Area Director(s):
Russell Housley <housley at vigilsec.com>
Sam Hartman <hartmans-ietf at mit.edu>

Security Area Advisor:
Sam Hartman <hartmans-ietf at mit.edu>

Mailing Lists:
General Discussion: anonsec at postel.org
To Subscribe: http://www.postel.org/anonsec
Archive: http://www.postel.org/anonsec

Description of Working Group:
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.

_______________________________________________
IETF-Announce mailing list
IETF-Announce at ietf.org
https://www1.ietf.org/mailman/listinfo/ietf-announce

_______________________________________________
Dev mailing list
Dev at openswan.org
http://lists.openswan.org/mailman/listinfo/dev

--- end forwarded text

-- 
-----------------
R. A. Hettinga <mailto: rah at ibuc.com>
The Internet Bearer Underwriting Corporation <http://www.ibuc.com/>
44 Farquhar Street, Boston, MA 02131 USA
"... however it may deserve respect for its usefulness and antiquity,
[predicting the end of the world] has not been found agreeable to
experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com