Better-Than-Nothing Security (btns) Internet Drafts

      
 IPsec Channels: Connection Latching
 
 draft-ietf-btns-connection-latching-11.txt
 Date: 13/08/2009
 Authors: Nicolas Williams
 Working Group: Better-Than-Nothing Security (btns)
 Formats: txt xml
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.

Better-Than-Nothing Security (btns)

Last Modified: 2009-02-11

Additional information is available at tools.ietf.org/wg/btns

Chair(s):

  • Love Hornquist Astrand <lha@stacken.kth.se>

  • Julien Laganier <julien.laganier.IETF@googlemail.com>

    Security Area Director(s):

  • 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
    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)
    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  Submit problem and applicability statement to IESG (a+b)
    Done  First version of IPsec interfaces draft (e)
    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

    Internet-Drafts:

    IPsec Channels: Connection Latching (70264 bytes)
    C-Bindings for IPsec Application Programming Interfaces (32383 bytes)
    IPsec End-Point Channel Bindings and API (14770 bytes)

    Request For Comments:

    Problem and Applicability Statement for Better Than Nothing Security (BTNS) (RFC 5387) (71707 bytes)
    Better-Than-Nothing-Security: An Unauthenticated Mode of IPsec (RFC 5386) (23103 bytes)
    IETF Secretariat - Please send questions, comments, and/or suggestions to ietf-web@ietf.org.

    Return to working group directory.

    Return to IETF home page.