NETWORK WORKING GROUP N. Williams
Internet-Draft Sun
Expires: August 26, 2006 February 22, 2006
IPsec Channels: Connection Latching
draft-ietf-btns-connection-latching-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 26, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document specifies, abstractly, how to interface applications
and transport protocols with IPsec so as to create "channels" by
"latching" connections to certain IPsec Security Association (SA)
parameters for their lifetime. This can be used to protect
applications against accidental reconfiguration of IPsec that might
expose live packet flows to unintended peers, such as might happen
with Better Than Nothing Security (BTNS). Latched connections
represent IPsec channels, and as such, allow for channel binding to
IPsec.
Williams Expires August 26, 2006 [Page 1]
Internet-Draft IPsec Connection Latching February 2006
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Conventions used in this document . . . . . . . . . . . . . . 3
2. Connection Latching . . . . . . . . . . . . . . . . . . . . . 4
3. Security Considerations . . . . . . . . . . . . . . . . . . . 6
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
5. Normative . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . 8
Intellectual Property and Copyright Statements . . . . . . . 9
Williams Expires August 26, 2006 [Page 2]
Internet-Draft IPsec Connection Latching February 2006
1. Introduction
IPsec protects packets with little or no regard for stateful packet
flows associated with upper layer protocols (ULPs). This limits the
usefulness of application interfaces to IPsec and exposes
applications that rely on IPsec for session protection to risks
associated with changing IPsec configurations and weak association of
peers and their addresses.
A method is desired for creating "IPsec channels," that is, packet
flows predictably protected for their duration, even in the face of
IPsec reconfiguration or BTNS [I-D.ietf-btns-prob-and-applic] [BTNS].
The method outlined below achieves this by interfacing ULPs and
applications to IPsec and using these interfaces to bind ("latch")
connections to certain IPsec SA parameters.
1.1. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Williams Expires August 26, 2006 [Page 3]
Internet-Draft IPsec Connection Latching February 2006
2. Connection Latching
Applications create latched connections implicitly by creating
connections with the ULPs' default latching policy; alternatively,
applications MAY request IPsec protection of connections, prior to
establishment, even when the Security Policy Database (SPD) would
bypass protection provided that Peer Authentication Database (PAD)
entries exist to authenticate peers. ULPs MUST default to latching
the set of SA parameters given below when applications do not specify
any and when a connection's initiating packet is sent/received
protected by IPsec.
ULPs create latched connections by interfacing with IPsec below as
follows:
o When the ULP passes a connection's initiating packet to IP the ULP
requests feedback about the SA used to protect the outgoing
packet, if any. If the application requested IPsec protection,
then the ULP passes this request down to IPsec with the initial
packet. If the packet is protected by IPsec then the ULP records
certain parameters of the SA used to protect it in the
connection's transmission control block (TCB).
o When a ULP receives a connection's initiating packet it should
obtain, from IP/IPsec, information about how the packet was
protected; the ULP then records certain parameters of the SA used
to protect the incoming packet in the connection's TCB.
Once SA parameters are recorded in a connection's TCB the ULP
enforces the connection's latch, or binding, to these parameters as
follows:
o The ULP inspects the SA used to protect input packets and drops
packets which are either protected by SAs whose parameters do not
match the latched parameters or which are not protected at all.
o The ULP always requests that outgoing packets be protected by SAs
with the latched parameters.
This requires certain logical interfaces between ULPs and the IP/
IPsec layer, namely:
o That IPsec be able to pass up to ULPs information about how each
incoming packets was protected, if at all, including specific SA
parameters.
o That ULPs be able to request that IPsec protect outgoing packets,
including specific SA parameters.
Williams Expires August 26, 2006 [Page 4]
Internet-Draft IPsec Connection Latching February 2006
The set of SA parameters that applications may wish to latch
connections to, and which ULPs MUST allow latching to, includes, but
is not limited to:
o Type of protection: confidentiality and/or integrity protection
(e.g., ESP vs. AH).
o Quality of protection (e.g., algorithms and key sizes, replay
protection).
o Encapsulation.
o Peer identity (i.e., peers' asserted and authorized IDs, as per
the IPsec processing model [RFC4301]. This item, in particular,
is necessary to protect applications from weak peer ID<->address
binding in IPsec configurations.
ULPs MUST make available to applications the latched SA parameters,
including node/peer ID types values, and, where nodes are
authenticated using public keys, the local node and remote peer
public key values and signature or encryption algorithm identifiers.
ULPs MUST allow applications to specify all SA parameters other than
node/peer ID types and values. ULPs MAY allow applications to
specify peer ID types and values.
This method of connection latching works generally for both,
connection-oriented ULPs (e.g., TCP), and connection-less ULPs (UDP).
It also works for ULPs that support multi-homing (e.g., SCTP),
provided that a node has the same ID for all of its addresses that
may be referenced by an SCTP connection and that its peers' PAD
configurations reflect this.
For connection-less ULPs connection latching requires keeping a
virtual connection (e.g., as in connected UDP sockets in the BSD
sockets API). However, it is not necessarily the case that existing
application interfaces to connection-less ULPs can support implicit
connection latching.
This method of connection latching also works generally with key
exchange protocols, such as IKEv1 [RFC2409] and IKEv2 [RFC4306], as
well as manual SA keying, and with a variety of peer authentication
mechanisms (e.g., pre-shared keys, certified public keys, etc...).
It does not work for multi-casting however.
Inability to establish an SA with parameters that match a connection
latch is akin to inability to communicate with the peer; normal ULP
timeout handling and considerations apply.
Williams Expires August 26, 2006 [Page 5]
Internet-Draft IPsec Connection Latching February 2006
3. Security Considerations
Connection latching protects only individual connections from weak
peer ID<->address binding or changing IPsec configurations, but it
does not ensure that any two connections with the same end-point
addresses, even if one established while the other is alive, will
have the same latched peer IDs. In other words, applications that
use multiple connections between two given nodes are not protected
any more or less by use of IPsec connection latching than by use of
IPsec alone. Such multi-connection applications can, however,
examine the latched SA parameters of each connection to ensure that
each every connection with the same end-point addresses also has the
same end-point IPsec IDs.
IPsec channels are a pre-requisite for channel binding to IPsec.
Connection latching provides such channels, but the process of
binding IPsec channels (latched connections) to authentication at
application layers is not specified herein.
Williams Expires August 26, 2006 [Page 6]
Internet-Draft IPsec Connection Latching February 2006
4. IANA Considerations
There are not IANA considerations for this document.
5. Normative
[BTNS] Williams, N., "Better-Than-Nothing-Security: An
Unauthenticated Mode of IPsec", draft-btns-btns-00.txt
(work in progress), February 2006.
[I-D.ietf-btns-prob-and-applic]
Touch, J., "Problem and Applicability Statement for Better
Than Nothing Security (BTNS)",
draft-ietf-btns-prob-and-applic-00 (work in progress),
July 2005.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, November 1998.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
RFC 4306, December 2005.
Williams Expires August 26, 2006 [Page 7]
Internet-Draft IPsec Connection Latching February 2006
Author's Address
Nicolas Williams
Sun Microsystems
5300 Riata Trace Ct
Austin, TX 78727
US
Email: Nicolas.Williams@sun.com
Williams Expires August 26, 2006 [Page 8]
Internet-Draft IPsec Connection Latching February 2006
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Williams Expires August 26, 2006 [Page 9]
