2.6.2 Better-Than-Nothing Security (btns)

NOTE: This charter is a snapshot of the 63rd IETF Meeting in Paris, France. It may now be out-of-date.

Last Modified: 2005-07-06


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

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

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


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

    No Request For Comments

    Current Meeting Report

    BTNS meeting notes

    These are the minutes for the Better then nothing security (BTNS) working group meeting, held at IETF-63 on Thursday, August 4, 2005, in Paris. Thanks to Tero Kivinen and Jeffrey Altman 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 Hörnquist Åstrand 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

    • * get WG feeling for problem and applicability statement.
      * Initiate work on SPD/PAD/IKE extensions.
      * Need to update the milestones to more realistic goals.
      * Other technical discussion.

    • Decisions made

      1. Need to support tunnel mode where inner address is the same as outer address.
      2. This is because of requirements of other protocols, such as iSCSI that have tunnel mode as MUST.

      3. Start to Work on IKE v2, and got back and see what changes is needed for IKE v1.

  • Current outstanding issues

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

    - what details for the SPD/PAD extensions?
    - 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 ?

  • Current work

  • - SPD/PAD extensions

    For the next item the WG will work on is the SPD/PAD extensions draft, target is to have it out well before Vancouver meeting.

    The people volunteering to be on the design team, if one is formed, are: Nico Williams, Bill Sommerfeld, Stephen Kent, Charlie Kaufmann, Soichi Sakane, Tero Kivinen, Joe (Touch ?).

    Sam Hartman is willing to participate but cannot be part of a design team due to conflict of role. One way to get Sam input is to have the discussion on the list, but Sam can't be involved to much in the discussion because of the conflict of roles.

    The WG will attempt to proceed without a formal design team, but if that fails, the chairs will form and announce a design team as it becomes necessary.
  • Points to pay attention to

  • Charlie Kaufmann: Its not should I send authentication but does the other care what the authentication info is?

    Sam Hartman (AD) considers it breaking IPsec if the users doesn't upgrade to full IKE to keep the functionality of BTNS. Its in the group charter to not break IPsec.
  • Updating milestones

  • These are the proposed dates by the chairs based on the discussing in the meeting, the dates are pushed forward 3 months.
    Sep 05 First version of SPD and/or PAD extensions draft (if needed)
    Oct 05 WG LC on problem and applicability statement (a+b)
    Oct 05 First version of IKE extensions draft (if needed)
    Nov 05 First version of IPsec interfaces draft (e)
    Nov 05 Submit problem and applicability statement to IESG (a+b)
    Jan 05 WG LC on IKE extensions (c)
    Jan 05 WG LC on SPD and/or PAD extensions (d)
    Feb 05 Submit IKE extensions to the IESG
    Feb 05 Submit SPD and/or PAD extensions to the IESG
    Mar 06 WG LC on IPsec interfaces draft
    Mar 06 Submit IPsec interfaces draft to the IESG
    May 06 Re-charter or close the WG
  • Discussion on Applicability and Problem statement

  • Joe Touch made a presentation on the Applicability and Problem statement. The initial draft was issued the first of July.

    Joe requested more feedback on the document, questions asked was:

    Style feedback:
    - Are there issues missing?
    - Are there issues that should be dropped?

    Items to be addressed:
    - auto detect
    - auto upgrade to security as needed
    - Any aspect of solution requirements

    Issues needed to be clarified:
    * why application security is not good enough
    * the costs of redundancy
    * why are we starting with IPsec

    Current feedback
    -repetitions, acronyms
    - more info on why application layer isn't sufficient
    - add redundancy of cost, as well as configuration
    - explain why IKE was chosen.

    There was agreement in the room that Joe should use the right terminology following the WG that created the terminology. It might be good to add a glossary.

    Joe asks contributors to mark what kind of comment they are making style, structure, or clarifications.

    Joe will put off changes until we know what we are keeping. He plans to integrate current comments and issue a new draft in 3-4 weeks.

    The PS/AS statement will need 1-3 cycles before we can send it to WGLC. The target for WGLC is late sept/early October.

    Sam Hartman (as AD) points out that it is in the group's charter that BTNS must interoperate with full IKE. We would be violating that if for example the BTNS specification or common BTNS policies made it undesirable to add IKE credentials to a node and start using those credentials.

    Russ Housley: The question of asymmetric case was up during charter discussion in the BOF, needs to be supported. Pekka proposes that we should start with no authentication case and work of the other parts later. Provide guidance in the document as to witch problems should be dealt with first.
  • Nico Williams' presentation - Thinking about BTNS

  • Slides:
    • Basics

    • - Forget what I have in my -00 individual submission ID on BTNS.
      - Just do IKE with base public key as CERT and with ID type to assert the base public key as the ID.
      - Add a bit of the PAD to allow for rules that say "any BTNS peer can use the IP addresses from these ranges".
      - If anyone cares, a "this bare public key, use this address". (This is needed for leap-of-faith BTNS.)

      - No real authentication
      - Protects against passive attackers
      - Protects against off-path injection attacks
      - Active attackers that can take over a victim's DIP can negotiate new SAs and go from there
      - But it can't take over existing connections
      - This is only slightly worse than plain IPsec in that at least in plain IPsec one can tie non-mobile devices' IDs to their static IP address; not so easy for BTNS This comment about IPsec applies when wildcard ID matching rules are involved.

      Nico also presented ideas for an API/connection latching, this is for a slightly out of charter/later work item, but was allowed to continue because there was still time left and this was the last issue. Charter allows for API, channel bindings are out of the charter.

    • IPsec APIs: Connection Latching

    • - Latch all packets send/received by a transport (e.g., TCP) for a given connection to all SAs with some algs/IDs/etc...
      - record algs/IDs of SA negotiated and used for the first packet sent or received for a connection
      - Subsequently send or accept only packets protected with similar SAs
      - In KAME, Solaris, a socket option
      - Adds more protection against active attacks

    • IPsec APIs: Connection Latching

    • - Even UDP data-grams can be latches, through without a UDP "connection" you probably only want to bind each data-gram (and its fragments) to a single SA.

    • IPsec APIs: Retrieve IDs/CERTs for latched connection

    • - if applications can latch connections then applications could ask the transports for information about the ends of the connections
      - Latched IDs, CERTs and certificates chain used in certificate validation for initial connection packet.
      - Then ...

    • IPsec Channels and Channel Bindings

    • - Much more protection against active attackers.
      As strong as upper layer authentication, against early active attacks ...
  • Other issues

  • Joe Touch: If you are going to turn on IPsec, it is possible to produce a DoS by sending junk. There is a new mailing list "triage" to address this issue.


    Agenda and Open issues
    Problem and Applicability Statement
    Thinking about BTNS