* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Btns Status Pages

Better-Than-Nothing Security (Concluded WG)
Sec Area: Roman Danyliw, Benjamin Kaduk | 2005-Apr-08 — 2010-Mar-16 

2009-09-04 charter

Better-Than-Nothing Security (btns)


 Current Status: Active

     Julien Laganier <julienl@qualcomm.com>
     Love Hornquist Astrand <lha@stacken.kth.se>

 Security Area Directors:
     Tim Polk <tim.polk@nist.gov>
     Pasi Eronen <pasi.eronen@nokia.com>

 Security Area Advisor:
     Tim Polk <tim.polk@nist.gov>

 Mailing Lists:
     General Discussion: btns@ietf.org
     To Subscribe:       https://www.ietf.org/mailman/listinfo/btns
     Archive:            http://www.ietf.org/mail-archive/web/btns/current/maillist.html

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
  resulting RFCs is to enable and encourage simpler and more rapid
  deployment of IPsec in contexts where use of unauthenticated SAs is
  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

  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

  c) If necessary, specify standards-track IKE extensions or profiles
  that support one or both of the bare RSA keys or self-signed

  d) Specify standards-track extensions to the SPD and PAD to support
  unauthenticated SAs for IPsec and cryptographic channel bindings for

  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)
  Done     - First version of SPD and/or PAD extensions draft (if needed)
  Done     - First version of IKE extensions draft (if needed)
  Done     - WG LC on problem and applicability statement (a+b)
  Done     - First version of IPsec interfaces draft (e)
  Done     - Submit problem and applicability statement to IESG (a+b)
  Feb 2007 - WG LC on IKE extensions (c)
  Done     - WG LC on SPD and/or PAD extensions (d)
  Mar 2007 - Submit IKE extensions to the IESG
  Done     - Submit SPD and/or PAD extensions to the IESG
  Oct 2007 - WG LC on IPsec interfaces draft
  Nov 2007 - Submit IPsec interfaces draft to the IESG
  Nov 2007 - Recharter or close the WG

All charter page changes, including changes to draft-list, rfc-list and milestones:

Generated from PyHt script /wg/btns/charters.pyht Latest update: 24 Oct 2012 16:51 GMT -