Network Working Group S. Bellovin
Internet-Draft Columbia University
Intended status: Informational October 15, 2006
Expires: April 18, 2007
Towards a TCP Security Option
draft-bellovin-tcpsec-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 April 18, 2007.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
The TCP-MD5 option, commonly used to secure BGP sessions between
routers, has many serious deficiencies. We present here
justifications for designing a new, more capable version of that
option; we also discuss some of the design criteria for one.
Bellovin Expires April 18, 2007 [Page 1]
Internet-Draft TCP Security October 2006
1. Introduction
Putting a security service into the transport layer has a long
history. SP4 [SP4] [SP4P] provided that service for the Secure Data
Network System (SDNS); OSI incorporated SP4 into its protocol suite
as the Transport Layer Security Protocol (TLSP) [TLSP].
TCP/IP has not had a full-fledged equivalent, though the TCP-MD5
option [RFC2385] has served some of its purposes. In this memo, we
analyze the problem and discuss what a solution should look like,
Note that we have deliberately used the phrase "security service".
Both a confidentiality and an authentication-only service have their
place. This memo is agnostic on that point, though we note that TCP-
MD5 is authentication-only.
2. Motivation
It is quite clear that the existing TCP authentication option
[RFC2385] is inadequate. It is cryptographically unsound, requiring
a process waiver to permit its continued use with BGP [RFC4278]. It
has no key identification field, necessitating a heuristic for key
change [I-D.bellovin-keyroll2385]. And it has no provision for
automated key management [RFC4107], leading to the problems described
in [RFC3562].
What is less clear is why authentication is needed at all at the TCP
layer. IPsec [RFC4301] can protect the entire TCP header and
payload, though with help from the kernel or outboard hardware; TLS
[RFC4346] can protect any the payload of TCP connection, after
changes to the application. That said, these existing solutions have
further deficiencies.
The most serious problem with IPsec is that it is hard to protect an
individual application with it [I-D.bellovin-useipsec]. Put briefly,
IPsec operates at the IP layer (with a sprinkling of transport layer
concepts, such as port numbers, for additional flavor). It also has
problems with NAT traversal [RFC2709] [RFC3715] [RFC3947] [RFC3948]:
NAT boxes can neither examine nor modify port numbers on most IPsec-
protected traffic, which causes very real problems in many
environments (though not, admittedly, when protecting BGP). The net
result is that IPsec usage is largely limited to virtual private
network scenarios; it is rarely used or usable for individual
applications.
To be sure, BGP speakers will rarely, if ever, be behind NATs. Other
uses have been suggested for devices that need to look at and even
Bellovin Expires April 18, 2007 [Page 2]
Internet-Draft TCP Security October 2006
modify parts of the TCP header in ways barred by IPsec; typically,
these are intended to deal with link type-specific performance issues
as are seen with geostationary satellites or lossy wireless links.
While it is not clear that a TCP security option can permit, say, ACK
spoofing or modifications to the advertised window size without
creating serious security or denial of service risks, there is
sufficient demand for such facilities that the problem should at
least be investigated. [[get citations]]
IPsec has often been criticized for its interference with firewalls
and with traffic engineering, because it hides port numbers and
flags. A TCP security option could choose to expose such fields for
examination.
TLS does not suffer from any of these flaws; however, it poses issues
of its own. It has integrated key management; while this works well
in many environments, it is too heavy-weight or otherwise
inappropriate for others. A more serious issue is the limited scope
of protection provided by TLS. It operates strictly above TCP; it
thus provides no protection at all against attacks against the TCP
header itself. Even if TLS is in use, it is thus possible for
attackers to reset connections (US-CERT Advisory TA04-111A) or
perpetrate other mischief [I-D.ietf-tcpm-tcp-antispoof].
It is clear, then, that some intermediate protection mechanism can be
justfied. While we do not propose a specific design here (nor are we
convinced that there is a strong-enough market demand for general
adoption of such a scheme), we believe that the question is worthy of
more exploration and discussion.
3. Requirements for a New Option
We note here several requirements for a future TCP security option.
More details may be found in [I-D.bellovin-keyroll2385].
1. It must provide protection for crucial elements of the TCP
header, including the flags field. Further details (including,
for example, coverage of TCP options) are not specified here.
2. A proper cryptographic algorithm should be used, rather than an
ad hoc keyed hash design.
3. The option should contain some form of key identifier field to be
used for intraconnection rekeying. This field points to a
receiver data structure entry that contains the actual key, much
like an IPsec SPI (Security Parameter Index). (Often, the data
structure will also contain auxiliary information, such as an
algorithm type, but we are not prescribing any particular design
here.)
Bellovin Expires April 18, 2007 [Page 3]
Internet-Draft TCP Security October 2006
4. An automated key management scheme should be defined or
identified.
4. Security Considerations
This memo per se does not raise any non-trivial security
considerations. However, any protocol designed or used to meet its
requirements will need a security analysis.
5. References
5.1. Normative
[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5
Signature Option", RFC 2385, August 1998.
[RFC3562] Leech, M., "Key Management Considerations for the TCP MD5
Signature Option", RFC 3562, July 2003.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.1", RFC 4346, April 2006.
5.2. Informative
[I-D.bellovin-keyroll2385]
Bellovin, S., "Key Change Strategies for TCP-MD5",
draft-bellovin-keyroll2385-01 (work in progress),
July 2006.
[I-D.bellovin-useipsec]
Bellovin, S., "Guidelines for Mandating the Use of IPsec",
draft-bellovin-useipsec-04 (work in progress),
September 2005.
[I-D.ietf-tcpm-tcp-antispoof]
Touch, J., "Defending TCP Against Spoofing Attacks",
draft-ietf-tcpm-tcp-antispoof-04 (work in progress),
May 2006.
[RFC2709] Srisuresh, P., "Security Model with Tunnel-mode IPsec for
NAT Domains", RFC 2709, October 1999.
[RFC3715] Aboba, B. and W. Dixon, "IPsec-Network Address Translation
Bellovin Expires April 18, 2007 [Page 4]
Internet-Draft TCP Security October 2006
(NAT) Compatibility Requirements", RFC 3715, March 2004.
[RFC3947] Kivinen, T., Swander, B., Huttunen, A., and V. Volpe,
"Negotiation of NAT-Traversal in the IKE", RFC 3947,
January 2005.
[RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M.
Stenberg, "UDP Encapsulation of IPsec ESP Packets",
RFC 3948, January 2005.
[RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic
Key Management", BCP 107, RFC 4107, June 2005.
[RFC4278] Bellovin, S. and A. Zinin, "Standards Maturity Variance
Regarding the TCP MD5 Signature Option (RFC 2385) and the
BGP-4 Specification", RFC 4278, January 2006.
[SP4] Dinkel, C., "Secure Data Network System (SDNS) Network,
Transport, and Message Security Protocols", NISTIR 90-
4250, 1990.
[SP4P] Branstad, D., Dorman, J., Housley, R., and Randall, "SP4:
A Transport Encapsulation Security Protocol",
December 1987.
Third Aerospace Security Conference Proceedings
[TLSP] "Information technology -- Telecommunications and
Information Exchange Between Systems -- Transport Layer
Security Protocol", ISO/IEC 10736, 1995.
Author's Address
Steven M. Bellovin
Columbia University
1214 Amsterdam Avenue
MC 0401
New York, NY 10027
US
Phone: +1 212 939 7149
Email: bellovin@acm.org
Bellovin Expires April 18, 2007 [Page 5]
Internet-Draft TCP Security October 2006
Full 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.
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.
Intellectual Property
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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Bellovin Expires April 18, 2007 [Page 6]
