Network Working Group W. Eddy, Ed.
Internet-Draft Verizon
Intended status: Informational S. Bellovin
Expires: January 10, 2008 Columbia University
J. Touch
USC/ISI
R. Bonica
Juniper Networks
July 9, 2007
Problem Statement and Requirements for a TCP Authentication Option
draft-bellovin-tcpsec-01
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 January 10, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Eddy, et al. Expires January 10, 2008 [Page 1]
Internet-Draft TCP Authentication July 2007
Abstract
The TCP-MD5 option is commonly used to secure BGP sessions between
routers, although it is known to have many serious deficiencies.
This memo presents requirements for a TCP segment authentication
mechanism that is intended to replace TCP-MD5. While TCP-MD5 was
designed to protect TCP sessions whose payload is BGP, the
applicability of the mechanism described herein is broader. This
mechanism can be applied to any TCP connection, regardless of
payload.
Table of Contents
1. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1. Distinguishing Requirements . . . . . . . . . . . . . . . 8
4.2. Expected Constraints . . . . . . . . . . . . . . . . . . . 13
5. Security Considerations . . . . . . . . . . . . . . . . . . . 15
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
7. Informative References . . . . . . . . . . . . . . . . . . . . 17
Appendix A. Un-Agreed Properties . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
Intellectual Property and Copyright Statements . . . . . . . . . . 22
Eddy, et al. Expires January 10, 2008 [Page 2]
Internet-Draft TCP Authentication July 2007
1. Contributors
This document resulted from the discussions of several IETF
participants, including significant input from a design team within
the TCPM working group who included (alphabetically):
Mark Allman (mallman@icir.org)
Steve Bellovin (smb@cs.columbia.edu)
Ron Bonica (rbonica@juniper.net)
Wesley Eddy (weddy@grc.nasa.gov)
Andrew Lange (andrew.lange@alcatel.com)
Allison Mankin (mankin@psg.com)
Sandy Murphy (sandy@tislabs.com)
Joe Touch (touch@isi.edu)
Sriram Viswanathan (sriram_v@cisco.com)
Brian Weis (bew@cisco.com)
Eddy, et al. Expires January 10, 2008 [Page 3]
Internet-Draft TCP Authentication July 2007
2. 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 for some purposes. TCP-MD5 is now known
to have several problems. In this memo, we analyze the need for a
TCP-based security service in Section 3 and discuss the requirements
that a solution should meet in Section 4,
Note that we have deliberately used the phrase "security service".
The in-use TCP-MD5 provides authentication-only and no TCP-based
confidentiality mechanism is deployed or yet defined by the IETF.
This document focuses on the requirements for an authentication-only
service to replace TCP-MD5. If a TCP-based confidentiality service
is also warranted, it could share many of these requirements, but
this is beyond the scope of the current work or expressed needs from
the community.
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].
Eddy, et al. Expires January 10, 2008 [Page 4]
Internet-Draft TCP Authentication July 2007
3. Problem Statement
The TCP-MD5 mechanism described in [RFC2385], includes a Message
Authentication Code (MAC) in each TCP header. The MAC value is
computed by hashing over:
o the TCP pseudo-header
o the TCP header, excluding options, and assuming a checksum of zero
o the TCP segment data
o an independently-specified shared key or password
To successfully spoof segments to a connection using the scheme
described above, an attacker would not only have to guess TCP
sequence numbers, but would also have to obtain the key that was used
to calculate the MAC. This key never appears in the connection
stream.
[RFC3562] addresses key management considerations for TCP-MD5. Based
upon the cryptographic strength of the MD5 hashing algorithm, RFC
3562 recommends that keys be changed at least every 90 days.
Unfortunately, TCP-MD5 only permits keys to be changed during the
lifetime of a TCP connection if the change is synchronized at both
ends. This limitation has proven to be a deterrent to the effective
deployment of TCP-MD5, and necessitates a heuristic for key change
[RFC4808].
Also, TCP-MD5 is entirely dependent on the MD5 hash algorithm, for
which there are now well-known collision-finding methods. In
addition, the particular keyed-hash MAC construction used by TCP-MD5
has serious cryptographic weaknesses. An attacker who can find a
collision in the underlying hash function can forge a MAC using a
simple chosen-message attack. It is quite clear that the existing
TCP-MD5 mechanism is inadequate [I-D.manral-rpsec-existing-crypto].
It is cryptographically unsound, requiring a process waiver to permit
its continued use with BGP [RFC4278].
TCP-MD5 has also been accused of not meeting operator requirements,
even though it was originally intended for operators to protect TCP-
based routing protocol sessions with (e.g. BGP, and now also LDP).
TCP-MD5 is said to have high CPU utilization. The impact of MD5
itself is known [RFC1810], but for specific TCP-MD5 implementations,
hard data on the protocol's performance has not been made availble,
nor have direct comparisons between TCP-MD5 and IPsec AH performance.
The key management and key change synchronization difficulties
Eddy, et al. Expires January 10, 2008 [Page 5]
Internet-Draft TCP Authentication July 2007
mentioned above have also been raised as operator concerns. It has
been admitted that many operators simply do not change keys on a
regular or systematic basis, but it is not clear whether this is a
symptom of TCP-MD5's lack of capabilities, or unrelated operational
culture. Based on the importance to the Internet of security for
routing protocol sessions, it is clear that TCP-MD5 should be
improved upon, and it seems likely that an improved version could
greatly increase the use of TCP-based authentication for routing
protocols and thus the robustness of routing sessions against the
known attacks targeting TCP connections [I-D.ietf-tcpm-tcp-antispoof]
[I-D.ietf-tcpm-tcpsecure].
It is less clear why authentication is needed at all within TCP
implementations. IPsec [RFC4301] can protect the entire TCP header
and payload, and TLS [RFC4346] can protect the payload data within a
TCP connection, when used by an application. However, these existing
solutions have their own deficiencies [I-D.ietf-tcpm-tcp-antispoof].
The most serious problem with IPsec is that it is hard to protect an
individual TCP connection with it [I-D.bellovin-useipsec], due to the
lack of an API that an application can request IPsec protection for a
specific connection via. IPsec operates at the IP layer (with only a
sprinkling of transport layer concepts, such as port numbers used
within traffic selectors), and has no notion of individual transport
layer connections and their duration (only quintuples of IP
addresses, protocol, and port numbers), so "latching" a particular
TCP connection to an IPsec Security Association with a corresponding
lifetime is difficult [I-D.ietf-btns-connection-latching].
IPsec 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 over the Internet. At this point,
the primary use of the existing TCP-based security method is
protecting BGP sessions between routers. BGP speakers will rarely,
if ever, be behind NATs, so it would seem that IPsec could be
feasible in this use case. The existing TCP-MD5 is similarly
hindered by the presence of NATs. The improved TCP authentication
mechanism is intended for general use, not limited to BGP
connections. On a per-connection configurable basis, compatibility
with NATs is a goal of this work.
IPsec tunnels and ESP in transport or tunnel mode have often been
criticized for their interference with firewalls and with traffic
engineering, because they can hide port numbers and flags. A TCP
Eddy, et al. Expires January 10, 2008 [Page 6]
Internet-Draft TCP Authentication July 2007
security option might choose to expose such fields for examination.
TLS does not suffer from any of these afflictions; however, it poses
issues of its own. The integrated key management in TLS works well
in many environments, but 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, and
thus provides no protection at all against attacks against the TCP
header itself. Even if TLS is in use, it is possible for attackers
to reset connections (US-CERT Advisory TA04-111A) or perpetrate other
mischief that affects the TCP connection state before TLS processing
occurs [I-D.ietf-tcpm-tcp-antispoof].
Since TCP-MD5 is deeply flawed and neither IPsec nor TLS currently
provide the desired granularity of protection for some uses, it is
clear that an intermediate protection mechanism can be justfied.
There have been multiple proposals presented recently to fill this
void [I-D.bonica-tcp-auth] [I-D.weis-tcp-auth-auto-ks]
[I-D.touch-tcpm-tcp-simple-auth], but without an agreed-upon set of
requirements, evaluating these proposals has been postponed. In
Section 4 within this document, we provide a set of requirements that
has been agreed upon by authors of all of the currently known
proposed solutions.
Eddy, et al. Expires January 10, 2008 [Page 7]
Internet-Draft TCP Authentication July 2007
4. Requirements
In this section, we present the distinguishing requirements for a
future TCP security option, based on a consensus within the TCPM
Authentication Option design team. These requirements are intended
to be used as a means of evaluating potential solutions. These
requirements partially have some basis in [RFC4808], and also have
some commonality with other requirement sets developed for BGP
session security [I-D.behringer-bgp-session-sec-req]. We also
include some expected constraints or behaviors of a solution in
Section 4.2, that are not expected to be useful in evaluating between
differing approaches, but are refinements that could be compatible
with any solution approach. Some suggested properties that the
design team was not able to obtain a consensus for or against are
listed in Appendix A.
4.1. Distinguishing Requirements
The requirements that a solution must fulfill are:
1. Protected Elements:
A. TCP Pseudoheader
The pseudoheader of specific IPv4 or IPv6 fields used in the
computation of a segment's TCP checksum, from [RFC0793] and
[RFC2460], is protected. By including source and destination
IP addresses, this influences operation through NATs in a
similar way to IPsec's Authentication Header, so although
pseudoheader coverage MUST be possible in any viable
solution, it MUST also be optional on a per-connection basis,
For checksum purposes, the header of a TCP connection is the
combination of its TCP Pseudoheader and its TCP Header. The
IP addresses of the pseudoheader are included because they
(together with the port numbers) define the connection; other
fields are included to protect fields of the IP header that
otherwise affect the TCP connection (in the latter case,
largely by their inclusion in the TCP checksum).
B. Base TCP Header
The full base TCP header is protected, excluding any TCP
options and the TCP checksum. By covering TCP port numbers,
this influences operation through NATs in a similar way to
IPsec's Authentication Header, so while port number coverage
MUST be possible in any viable solution, it also MUST be
optional on a per-connection basis.
Eddy, et al. Expires January 10, 2008 [Page 8]
Internet-Draft TCP Authentication July 2007
The TCP Header is included by definition, since the purpose
of this security option is to protect the TCP header.
C. TCP Options
Additionally, each defined TCP option type may be either
selected for or excluded from protection. This is configured
on a per-option type, per-connection basis, and is static for
the lifetime of a TCP connection.
Other TCP options may or may not be protected by this
security option, as desired. The primary reason for
excluding options is efficiency, and because this level of
protection can be relaxed in a way that impacts only an
individual connection, this is a user choice.
Note that the authentication option itself MUST be included,
with the authentication hash zeroed out.
D. TCP Data
The payload of each TCP segment containing the data given to
applications MUST also be protected.
2. Option Structure Requirements:
A. Privacy
The authentication option MUST NOT directly expose sensitive
security parameters, so that a third party's ability to view
packets does not also permit them to inject authenticable
packets or to otherwise determine information that could be
used to compromise a particular connection, or other
connections, between a pair of hosts.
B. Allow Optional
A host capable of parsing the authentication option MUST be
able to requrie or ignore the option on received segments on
a per-connection basis.
The purposed of the option is to authenticate connections;
hosts must be able to discard segments sent to connections
intended to be authenticated (i.e. they MUST be able to
require the option's use). Authentication determines the ID
of the source of a packet; some hosts may not be interested
in verifying the ID. Presumably, use of the option would be
determined a-priori, before a connection is established by a
Eddy, et al. Expires January 10, 2008 [Page 9]
Internet-Draft TCP Authentication July 2007
separate key and/or policy management system, but it still
may be useful to offload or otherwise ignore an expensive
authentication calculation, especially if the resulting ID
confirmation is not desired.
C. Require Non-Optional
A host capable of sending the authentication option MUST be
able to coordinate in-band whether the option should be
required or might be ignored for a particular connection with
a capable receiver.
This requirement supports senders who prefer to use the
option, but who are also willing to support hosts not
implementing the option. Such coordination would typically
happen in the key management system, but since that system
could be manual, an in-band mechanism to confirm use of this
option and backoff if not supported is required. This
mechanism would also prevent backoff if the sender does not
desire that behavior.
D. Standard Parsing
The authentication option MUST be trivially parseable by
those TCP implementations that do not support it. This means
that it must follow the [RFC0793] format of including a type
and length field, so that it can be skipped over when it is
not supported by an implementation. TCP already specifies
that hosts not supporting an option ignore that option in
received segments; stating this requirement here simply
ensures that TCP authentication solutions do not alter the
format of the base TCP header or radically depart from the
typical options encoding.
E. Compatible with Large Windows
The authentication option MUST allow the concurrent use of
timestamps and window-scaling within protected connections,
as excluding these could limit its range of performance.
These options are in common use, and are needed for
performance over high-speed or high-delay paths. Use of the
authentication option thus needs to permit the use of these
options, or its practical deployability will be severely
limited.
F. Compatible with SACK
Eddy, et al. Expires January 10, 2008 [Page 10]
Internet-Draft TCP Authentication July 2007
If the use of Selective Acknowledgements (SACK) is negotiated
on a connection, the authentication option MUST allow room
for at least one SACK block to be included in the TCP
options, and preferably more.
This option, like (E), is in common use, and is needed for
performance in large-window, lossy connections. Use of the
authentication option thus needs to permit the use of SACK.
3. Cryptography Requirements
A. Baseline Defaults
There MUST be at least one set of particular cryptography
algorithms or constructions whose use is supported by all
implementations and can be safely assumed to be supported by
any implementation of the authentication option.
This requirement is intended to support interoperability of
this option, by having a single default.
B. Good Algorithms and Constructions
The authentication option MUST support default cryptography
algorithms and constructions that are accepted by the
community. This means it MUST NOT rely on non-standard or
ad-hoc hash functions, keyed-hash constructions, signature
schemes, or other functions, and MUST use published and
standard schemes (i.e. it should use a construction like HMAC
versus the form of keyed-hash used in TCP-MD5).
This requirement is intended to correct the flaws in the
strength of authentication provided by the keyed hash used in
TCP-MD5.
C. Algorithm Agility
The authentication option MUST be capable of supporting
algorithms other than its defaults, in order to adapt to
future discoveries. An implementation that supports multiple
algorithms MUST permit concurrent connections to use
different algorithms.
The existing TCP-MD5 requires substantial revision or
retirement because its algorithms cannot be replaced. This
requirement allows the authentication option to be agile to
algorithmic attacks, where additional algorithms can be added
as needed.
Eddy, et al. Expires January 10, 2008 [Page 11]
Internet-Draft TCP Authentication July 2007
D. Order-Independent Processing
Authentication MUST be performed on individual, unordered TCP
segments, so that it is not severely influenced by reasonable
amounts of packet loss or reordering.
TCP headers are processed in the order received, although the
data is reordered based on header information. As a result,
header fields must be authenticated in the order received; to
reorder them first would alter TCP semantics, and would
potentially require data in unauthenticated segments to be
quarantined (i.e. copied again) until authenticated later.
E. Parameter Changes Require Key Changes
A change in the keys used MUST accompany any change in the
other parameters the cryptography functions for the
authentication option are configured with.
This requirement allows the design of a compact option. It
allows the key ID and key itself to indicate the parameters,
rather than requiring header fields for them. It also avoids
interpreting those parameters from in-band information,
further avoiding exposing them to parties on the path.
4. Keying Requirements
A. Intraconnection Rekeying
Within the course of a single connection, the authentication
option MUST accomodate rekeying.
TCP spoofing attacks, which this option is intended to
defeat, are often targeted at relatively long-lived
connections. Use of a single key over a long connection is a
known security problem, so it would be preferable to either
limit the length of a connection or require in-band keying
support.
Unfortunately, not all applications are easy to restart.
BGP, for which this option is intended, is being augmented
for graceful restart [RFC4724] [RFC4781], but this extension
is under recent scrutiny. TCP itself has no limit on the
length of a connection, and it would be preferable to avoid
modifying this semantic.
B. Efficient Rekeying
Eddy, et al. Expires January 10, 2008 [Page 12]
Internet-Draft TCP Authentication July 2007
A rekeying event MUST NOT significantly affect performance of
the TCP connection. Most segments should be validated by a
single pass of the construction of cryptography algorithms
used for authentication, and no validations should require
more than a small, fixed number of passes.
Any aspect of this option which is inefficient is likely to
inhibit its deployment. When using this option, segments may
arrive out of order, and it would be inefficient to determine
which key is appropriate via a large number of trials. Such
trials would present a DoS vulnerability during rekeying.
This issue is discussed in [RFC4808].
C. Automated and Manual Keying
The authentication option MUST support both manual
configuration of preshared keys and automated key management.
This allows for different modes of operation depending on the
user's particular deployment environment.
D. Key-Mananagement Agnostic
The per-segment authentication is performed without regards
to the manner in which keying material is obtained. This
requirement decouples the option mechanism itself from the
key management system used, so that either multiple protocols
can be integrated, or any flawed methods can be easily
replaced in the future.
4.2. Expected Constraints
In addition to having a wire format that supports the Distinguishing
Requirements, a solution should include the following caveats in its
internal operation.
1. Silent Failure
On failure (due to incorrect or missing authentication data),
segments MUST be silently discarded, with no reply generated.
Shuch events SHOULD be logged periodically. Failed segments MUST
NOT alter the protocol state of the TCP connection itself.
Silence and the use of only periodic logging prevents the
creation of a new DoS opportunity.
2. Maximum of One Option per Segment
At most, one authentication option MUST be allowed per segment.
Eddy, et al. Expires January 10, 2008 [Page 13]
Internet-Draft TCP Authentication July 2007
The presence of multiple options MUST be treated as a failure.
Use of multiple options would present another DoS opportunity,
and provides no additional protection vs. a single option with
appropriate connection latching to other mechanisms, if desired.
3. Outgoing All-or-None Operation
Within a connection, once the authentication option is enabled,
all segments MUST carry the option.
This prevents headers and/or data from being injected into a
protected connection.
4. Incoming All-Checked Operation
An implementation capable of using the authentication option MUST
check every incoming segment's connection state to decide whether
the option's presence is required.
This requirement allows a host to determine which connections
require the option, vs. which allow it as optional. Checking
connection state for every incoming segment enforces required use
for indicated connections.
5. Non-Interaction with TCP-MD5
An implementation MUST NOT allow a connection to simultaneously
use the new authentication option and TCP-MD5. An implementation
MAY support the use of either exclusively the new authentication
option or exclusively TCP-MD5 for each individual connection.
This option is intended to supercede TCP-MD5, and in the spirit
of (2) above, only one such option is useful per connection.
Support for existing TCP-MD5 would support legacy interoperation.
6. Optional ICMP Discard
An implementation MUST be configurable to allow a protected
connection to ignore incoming ICMP Type 3 messages with Codes
2-4. This SHOULD be the default configuration.
This requirement prevents an ICMP attack on protected connections
via unprotected/unauthenticable (ICMP) packets.
Eddy, et al. Expires January 10, 2008 [Page 14]
Internet-Draft TCP Authentication July 2007
5. Security Considerations
This document does not specify any protocol; it discusses known
security problems with a currently deployed protocol, and the
requirements for fixing those problems in a new protocol. This
document is itself a set of security considerations, and its
publication raises no new security considerations.
Eddy, et al. Expires January 10, 2008 [Page 15]
Internet-Draft TCP Authentication July 2007
6. IANA Considerations
This document does not update or create any IANA registries.
Eddy, et al. Expires January 10, 2008 [Page 16]
Internet-Draft TCP Authentication July 2007
7. Informative References
[I-D.behringer-bgp-session-sec-req]
Behringer, M., "BGP Session Security Requirements",
draft-behringer-bgp-session-sec-req-01 (work in progress),
May 2007.
[I-D.bellovin-useipsec]
Bellovin, S., "Guidelines for Mandating the Use of IPsec",
draft-bellovin-useipsec-06 (work in progress),
February 2007.
[I-D.bonica-tcp-auth]
Bonica, R., "Authentication for TCP-based Routing and
Management Protocols", draft-bonica-tcp-auth-06 (work in
progress), February 2007.
[I-D.ietf-btns-connection-latching]
Williams, N., "IPsec Channels: Connection Latching",
draft-ietf-btns-connection-latching-01 (work in progress),
March 2007.
[I-D.ietf-tcpm-tcp-antispoof]
Touch, J., "Defending TCP Against Spoofing Attacks",
draft-ietf-tcpm-tcp-antispoof-06 (work in progress),
February 2007.
[I-D.ietf-tcpm-tcpsecure]
Ramaiah, A., "Improving TCP's Robustness to Blind In-
Window Attacks", draft-ietf-tcpm-tcpsecure-07 (work in
progress), February 2007.
[I-D.manral-rpsec-existing-crypto]
Manral, V., "Issues with existing Cryptographic Protection
Methods for Routing Protocols",
draft-manral-rpsec-existing-crypto-04 (work in progress),
April 2007.
[I-D.touch-tcpm-tcp-simple-auth]
Touch, J. and A. Mankin, "The TCP Simple Authentication
Option", Internet-Draft
draft-touch-tcpm-tcp-simple-auth-02 (work in progress),,
October 2006.
[I-D.weis-tcp-auth-auto-ks]
Weis, B., "Automated key selection extension for the TCP
Enhanced Authentication Option",
draft-weis-tcp-auth-auto-ks-02 (work in progress),
Eddy, et al. Expires January 10, 2008 [Page 17]
Internet-Draft TCP Authentication July 2007
March 2007.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, September 1981.
[RFC1810] Touch, J., "Report on MD5 Performance", RFC 1810,
June 1995.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5
Signature Option", RFC 2385, August 1998.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[RFC2709] Srisuresh, P., "Security Model with Tunnel-mode IPsec for
NAT Domains", RFC 2709, October 1999.
[RFC3562] Leech, M., "Key Management Considerations for the TCP MD5
Signature Option", RFC 3562, July 2003.
[RFC3715] Aboba, B. and W. Dixon, "IPsec-Network Address Translation
(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.
[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.
[RFC4724] Sangli, S., Chen, E., Fernando, R., Scudder, J., and Y.
Eddy, et al. Expires January 10, 2008 [Page 18]
Internet-Draft TCP Authentication July 2007
Rekhter, "Graceful Restart Mechanism for BGP", RFC 4724,
January 2007.
[RFC4781] Rekhter, Y. and R. Aggarwal, "Graceful Restart Mechanism
for BGP with MPLS", RFC 4781, January 2007.
[RFC4808] Bellovin, S., "Key Change Strategies for TCP-MD5",
RFC 4808, March 2007.
[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 J. Randall,
"SP4: A Transport Encapsulation Security Protocol", Third
Aerospace Security Conference Proceedings, December 1987.
[TLSP] "Information Technology -- Telecommunications and
Information Exchange Between systems -- Transport Layer
Security Protocol", ISO/IEC 10736, 1995.
Eddy, et al. Expires January 10, 2008 [Page 19]
Internet-Draft TCP Authentication July 2007
Appendix A. Un-Agreed Properties
There were some items that were suggested as requirements but which
were not ratified by all participants in the design team. These are
listed here.
1. Saves Work When Optional
A host sending TCP segments should be able to detect on a per-
connection basis whether the authentication option is required or
is being ignored by a receiver who supports the option.
2. Single-Pass Rekeying
The authentication option should support rekeying where incoming
segments are validated using a single pass of the cryptographic
construction used for authentication.
Eddy, et al. Expires January 10, 2008 [Page 20]
Internet-Draft TCP Authentication July 2007
Authors' Addresses
Wesley M. Eddy (editor)
Verizon Federal Network Systems
NASA Glenn Research Center
21000 Brookpark Rd, MS 54-5
Cleveland, OH 44135
Phone: 216-433-6682
Email: weddy@grc.nasa.gov
Steven M. Bellovin
Columbia University
1214 Amsterdam Avenue
MC 0401
New York, NY 10027
Phone: +1 212 939 7149
Email: bellovin@acm.org
Joe Touch
USC/ISI
4676 Admirality Way
Marina del Rey, CA 90292-6695
Phone: +1 (310) 448-9151
Email: touch@isi.edu
Ronald P. Bonica
Juniper Networks
2251 Corporate Park Drive
Herndon, VA 20171
Email: rbonica@juniper.net
Eddy, et al. Expires January 10, 2008 [Page 21]
Internet-Draft TCP Authentication July 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
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, THE IETF TRUST 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).
Eddy, et al. Expires January 10, 2008 [Page 22]
