2.7.1 Better-Than-Nothing Security (btns)

NOTE: This charter is a snapshot of the 64th IETF Meeting in Vancouver, British Columbia Canada. It may now be out-of-date.

Last Modified: 2005-10-24

Chair(s):

Pekka Nikander <Pekka.Nikander@nomadiclab.com>
Love Hörnquist Åstrand <lha@stacken.kth.se>

Security Area Director(s):

Russ Housley <housley@vigilsec.com>
Sam Hartman <hartmans-ietf@mit.edu>

Security Area Advisor:

Sam Hartman <hartmans-ietf@mit.edu>

Mailing Lists:

General Discussion: anonsec@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.

Goals and Milestones:

Done  Confirm on mailing list whether SPD and/or PAD extensions are needed (d)
Done  First version of problem and applicability statement (a+b)
Sep 2005  First version of SPD and/or PAD extensions draft (if needed)
Oct 2005  WG LC on problem and applicability statement (a+b)
Oct 2005  First version of IKE extensions draft (if needed)
Nov 2005  First version of IPsec interfaces draft (e)
Nov 2005  Submit problem and applicability statement to IESG (a+b)
Jan 2006  WG LC on IKE extensions (c)
Jan 2006  WG LC on SPD and/or PAD extensions (d)
Feb 2006  Submit IKE extensions to the IESG
Feb 2006  Submit SPD and/or PAD extensions to the IESG
Mar 2006  WG LC on IPsec interfaces draft
Mar 2006  Submit IPsec interfaces draft to the IESG
May 2006  Recharter or close the WG

Internet-Drafts:

  • draft-ietf-btns-prob-and-applic-01.txt

    No Request For Comments

    Current Meeting Report

     
    BTNS meeting notes

These are the minutes for the Better than nothing security (BTNS)
working group meeting, held at IETF-64 on Thursday, Nov 10, 2005, in
Vancouver.  Thanks to Jeffrey Altman, Leif Johansson, Michael
Richardson and Pekka Nikander for the notes on which these minutes are
based.  Note that these minutes do not follow the typical IETF minutes
format, transcribing the discussion, but are on a more condensed
format.

Chairs: Love Hoernquist Aastrand and Pekka Nikander

* Working group background

	Three different groups/interests:

	* protection against off-path attackers
	* working towards channel binding
	* SSH-like leap-of-faith use of IPsec

	The working group was chartered to:
	* specify extensions to IPsec so that IPsec will support
	  creation of unauthenticated SAs.
	* enable and encourage simpler and more rapid deployment of
          IPsec.

* Goals for the meeting

	* Complete discussion on Problem statement and applicability
	  statement.
	* Confirm direction of the SPD/PAD/IKE extensions document.
	* Other technical discussions.
	* Update milestones

* Decisions made

 	1. Adopt Nico BTNS document (draft-williams-btns-00.txt) as a
            working group item.

	2. Update milestones as proposed by Love.

* Current outstanding issues

	Some of these question where asked during the meeting (by
	group and chairs):

	- is leap-of-faith really in scope?
	  - leap-of-faith with changing addresses.
	- when SA going away, and exsting streams
	  get sent in clear-text, how does this affect BTNS,
	  leap-of-faith ?
	- what details for the SPD/PAD extensions?
	  - ANY/UKNOWN in PAD/SPD.
	- how do you detect BTNS?
	- should self-signed certificates or raw keys be used?
	- Is it OK to allow clear text traffic and then later kick in
          BTNS ?

* Action items

	* Publish next version of the Problem and Applicability
	  Statement hopefully in the beginning of December. Joe,
	  Yu-Shun, David.

	* Get more review of the Problem and Applicability Statement,
          chairs

	* Publish next version of Nico draft as a working-group item,
          Nico.

	* Add text in Nico draft how to the use-cases in Problem and
	  Applicability Statement is used, Nico.

* Current work

	* Problem statement and applicability statement

	* An Unauthenticated Mode of IPsec

* Points to pay attention to

	* Leap of faith is hard, maybe we shouldn't try to solve all
          problems related to this.

	* Describe the problems in Applicability and Problem statement
	  that we can check if we solve in subsequent document.

* Presentation: Discussion on Applicability and Problem statement

	Joe Touch made a presentation on the Problem and Problem
	statement draft. He had recived comments from about 5 people
	on the draft. 

	Joe thought he would have a updated draft out by the end of
	the month or early December. There are known open issues, the
	editors would send mail to the people the made the comments
	and see if they comments are addressed. And if it was not, ask
	the person to clarify the issue.

* Presentation: An Unauthenticated Mode of IPsec

	Nico Williams made a presentation about his individual
	submission about how to implement the BTNS using IKE by
	introducing new states to either PAD and/or PAD.

	The issue if UNKNOWN in SPD was really the right solution came
	up, and it was some discussion if UNKNOWN should live in the
	PAD or the SPD,

	Steve Kent voiced concerned that draft needs to prove why this
	approach does not break existing access control.

	Sam Hartman would like to see use-cases in the draft, show its
	possible to solve the problems given in the problem statement.

	There as a good discussion about how leap-of-faith mode could
	work. The where consensus that having a leap-of-faith mode was
	hard, but not impossible.

	Michael Richardson points out that in the case where the peer
	goes away and the SA is killed any data that still is in
	progress will go out in clear-text on the wire. Nico Williams
	confirms that this is an issue for standalone BTNS. Sam
	Hartman thinks this need to examined, at the very least
	mentioned in the Security Considerations section.

* Updating milestones

	Updated milesstones a proposed by Love, no commentes received
	during the meeting.

	Old	New	Milestone
	Sep 05	Sep 05	First version of SPD and/or PAD extensions draft
	Oct 05	Jan 06	WG LC on problem and applicability statement (a+b)
	Oct 05	Jan 06	First version of IKE extensions draft (if needed)
	Nov 05	Feb 06	First version of IPsec interfaces draft (e)
	Nov 05	Feb 06	Submit problem and applicability statement to IESG (a+b)
	Jan 06	Mar 06	WG LC on IKE extensions (c)
	Jan 06	Mar 06	WG LC on SPD and/or PAD extensions (d)
	Feb 06	Apr 06	Submit IKE extensions to the IESG
	Feb 06	Apr 06	Submit SPD and/or PAD extensions to the IESG
	Mar 06	Jun 06	WG LC on IPsec interfaces draft
	Mar 06  Jun 06	Submit IPsec interfaces draft to the IESG
	Mar 06	Mar 06	Recharter or close the WG


* Other issues

	None.

    Slides

    BTNS Agenda
    Joe Touch's BTNS Problem and Applicability Statement Presentation
    Nico William's BTNS presentation