Internet DRAFT - draft-weis-tcp-mac-option
draft-weis-tcp-mac-option
TCPM Working Group B. Weis
Internet-Draft C. Appanna
Expires: June 5, 2006 D. McGrew
A. Ramaiah
Cisco Systems
December 2, 2005
TCP Message Authentication Code Option
draft-weis-tcp-mac-option-00
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 June 5, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This memo describes a TCP [RFC0793] extension to enhance security for
BGP [I-D.ietf-idr-bgp4] and other TCP-based protocols requiring
message authentication. It provides message authentication using a
Message Authentication Code (MAC), which is a superior authentication
method to the keyed MD5 method previously used. The option also
includes provision for automatic generation and distribution of MAC
Weis, et al. Expires June 5, 2006 [Page 1]
Internet-Draft TCP MAC Option December 2005
keys. A set of MAC algorithms are specified, as well as guidance
when to use each one.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements notation . . . . . . . . . . . . . . . . . . 3
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Proposal . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Option Header . . . . . . . . . . . . . . . . . . . . . . 6
3.1.1. MAC Algorithm ID Types . . . . . . . . . . . . . . . . 6
3.2. Authentication Data . . . . . . . . . . . . . . . . . . . 7
3.2.1. Authentication Data Size . . . . . . . . . . . . . . . 8
3.3. Encrypted Key . . . . . . . . . . . . . . . . . . . . . . 8
3.3.1. KEK Algorithm ID Types . . . . . . . . . . . . . . . . 8
4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.1. Key Management Methods . . . . . . . . . . . . . . . . . . 10
4.1.1. Locally Managed MAC Keys . . . . . . . . . . . . . . . 10
4.1.2. Automatic Generation of Keys . . . . . . . . . . . . . 10
4.2. MAC Option Size . . . . . . . . . . . . . . . . . . . . . 11
4.2.1. Authentication Data Only . . . . . . . . . . . . . . . 11
4.2.2. Adding an Encrypted Key . . . . . . . . . . . . . . . 11
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
7.1. Normative References . . . . . . . . . . . . . . . . . . . 14
7.2. Informative References . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
Intellectual Property and Copyright Statements . . . . . . . . . . 17
Weis, et al. Expires June 5, 2006 [Page 2]
Internet-Draft TCP MAC Option December 2005
1. Introduction
The TCP MD5 Signature Option [RFC2385] specifies an option to provide
integrity protection to BGP sessions using the MD5 algorithm and a
key in a keyed MAC construction. MD5 does not provide a sufficient
level of security, and recently published attacks motivate its
replacement. Also, the keyed hash MAC construction used by RFC2385
has serious cryptographic weaknesses. An attacker who can find a
collision in the underlying hash function can forge a message
authentication code using a simple chosen-message attack [MACS].
This proposal describes a set of message authentication codes used to
verify integrity of a TCP message. Message authentication codes are
a well-accepted method of verifying message integrity.
This proposal can use message authentication codes that require
unique nonces. This is important because at present the best-
performing MACs all have this requirement. The MAC Option can also
securely transport new key material between end-points, using a long-
lived encryption key. Neither of these options is mandatory to
implement, in order to ensure that the MAC Option can easily be
implemented in current TCP stacks.
1.1. Requirements notation
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].
1.2. Terminology
Key Encrypting Key (KEK). A key used with a cryptographic algorithm
to encrypt another key.
Message Authentication Code (MAC). A keyed cryptographic checksum on
data that uses a secret key to detect modifications of a message
(e.g., a TCP segment). An attacker who does not know the secret
key is unable to generate the MAC corresponding to a particular
message, with very high probability. This is true even when the
attacker can perform a chosen-message attack, and cause a
legitimate user of the system to authenticate messages of its
choice.
Weis, et al. Expires June 5, 2006 [Page 3]
Internet-Draft TCP MAC Option December 2005
2. Proposal
This proposal describes a means of using a Message Authentication
Code (MAC) algorithm to authenticate a TCP segment. Modern MAC
algorithms were developed specifically for detecting modification to
data (e.g., TCP segments) and are significantly stronger
cryptographic methods than the TCP MD5 Signature Option. A number of
MAC algorithms may be used, each of which has different strengths and
weaknesses (described later in this proposal). The key used to
create the MAC is assumed to be known only to the TCP end-points.
The MAC authentication data is created by applying a MAC algorithm
and a key to the following data:
1. the TCP pseudo-header (in the order: source IP address,
destination IP address, zero-padded protocol number, and segment
length)
2. the TCP header, excluding options, and assuming a checksum of
zero
3. the TCP segment data (if any)
Creating a MAC in this manner, an attacker does not only need to
create a valid TCP segment (including a valid TCP sequence number),
but also must be able to create a valid MAC. Creating a valid MAC
requires knowledge of the key used to create the MAC.
Unlike RFC 2385, this proposal does not apply the MAC algorithm to
the key in the same manner as the MAC algorithm is applied to the TCP
pseudo-header, header, and data. The MAC algorithms defined for this
option use the key as a direct input to the algorithm, so there is no
need to additionally include it in the MAC data. Additionally,
including the key in the hashed data may weaken the MAC. This is
because using the key as part of the message interferes with the
reduction-based methods used to design encryption algorithms and to
prove their security [KDM].
This proposal includes an option for passing the MAC key in-band,
encrypted under a Key Encrypting Key (KEK) known to both TCP end-
points. When an encrypted key is included in a TCP option, it is
used to authenticate the current segment, and all subsequent segments
in the TCP exchange until a new key is chosen by one or the other of
the TCP end-points. Algorithms used with the KEK MUST be strong
enough so that an attacker observing the segment cannot determine the
key in a reasonable amount of time. One strong KEK algorithm is
described below.
Weis, et al. Expires June 5, 2006 [Page 4]
Internet-Draft TCP MAC Option December 2005
Several methods of key management are possible with this proposal,
and are discussed later in this document.
Weis, et al. Expires June 5, 2006 [Page 5]
Internet-Draft TCP MAC Option December 2005
3. Syntax
This option has three parts: TCP option header, authentication data,
and an optional encrypted key for use verifying integrity of this and
future segments within this TCP flow.
3.1. Option Header
The option header has the following format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Kind | Length | MAC Alg ID |K| Key ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
o Kind (8 bits). Value that identifies this option as the
Cryptographic Option.
o Length (8 bits). Length in octets of the option, including its
header.
o MAC Alg ID (7 bits). Unique identifier describing the
cryptographic algorithm and mode to be used as the MAC algorithm.
o K (1 bit). When set to 1, signals that an encrypted key is
included in the option.
o Key ID (8 bits). A value identifying a particular key to both the
sender and receiver. If K is set to one, the Key ID identifies
the KEK used to protect encrypted MAC key. A value of 0 indicates
that the key in use has no identifier.
3.1.1. MAC Algorithm ID Types
The following MAC Algorithms are strong MAC algorithms suitable for
use with this option.
o HMAC-SHA-1-96. HMAC with the SHA-1 hash function, with output
truncated to 96 bits [FIPS.198.2002]. This algorithm MAY be
implemented for an implementation to conform to this option.
o AES-128-GMAC-96. AES [FIPS.197.2001] with a 128-bit key in the
GMAC [GMAC] mode of operation, with a 96-bit tag. This algorithm
requires a 96-bit unique nonce. The nonce is formed as follows.
The leftmost 56 bits are all set to zero. The next eight bits
contain a direction byte; its binary value is 00000000 for the
sender, and 00000001 for the receiver. The rightmost 32 bits are
Weis, et al. Expires June 5, 2006 [Page 6]
Internet-Draft TCP MAC Option December 2005
copied from the Sequence Number field. This algorithm MAY be
implemented for an implementation to conform to this option.
o AES-128-CMAC-96. AES with a 128-bit key in the CMAC mode of
operation [FIPS.800-38B], with output truncated to 96 bits. The
AES-128-CMAC-96 algorithm MUST be implemented for an
implementation to conform to this option.
o AES-128-UMAC-96. The UMAC-96 message authentication code [UMAC]
with a 96-bit output tag. This algorithm also requires a nonce.
For the purposes of this document the nonce will be 40 bit nonce.
The nonce is formed as follows. The first eight bits contain a
direction byte; its binary value is 00000000 for the sender, and
00000001 for the receiver. The rightmost 32 bits are copied from
the Sequence Number field. This algorithm MAY be implemented for
an implementation to conform to this option.
3.2. Authentication Data
The authentication data provides segment integrity. If the MAC
algorithm does not requires a nonce, then the Authentication Data is
simply comprised of the MAC bytes, as follows.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Message Authentication Code ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Message Authentication Code (variable). The size of the MAC
varies according to the MAC algorithm (see table at the end of
this section).
If the MAC algorithm requires a nonce for its operation, it MUST be
included at the beginning of the Authentication data, as follows.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Message Authentication Code ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Sequence Number (32 bits). A unique monotonically increasing
value used as a base for a nonce for algorithms requiring a unique
value for each ICV value generated with a particular key. When a
sequence number reaches the maximum value, the key MUST NOT be
Weis, et al. Expires June 5, 2006 [Page 7]
Internet-Draft TCP MAC Option December 2005
used to authenticate any further packets.
o Message Authentication Code (variable). The size of the MAC
varies according to the MAC algorithm (see table at the end of
this section).
3.2.1. Authentication Data Size
The size of the authentication data field varies depending on the
output of the MAC algorithm and whether or not the MAC algorithm
requires a sequence number field. The following table lists the MAC
algorithms identified in this proposal and the resulting size of the
authentication data field.
+-----------------+---------------------------------+
| MAC Algorithm | Authentication Data Size (bits) |
+-----------------+---------------------------------+
| HMAC-SHA-1-96 | 96 |
| AES-128-GMAC-96 | 128 |
| AES-128-CMAC-96 | 96 |
| AES-128-UMAC-96 | 128 |
+-----------------+---------------------------------+
3.3. Encrypted Key
When K is set to 1, the encrypted key is included in the TCP MAC
Option following the authentication data. The length of the key can
be determined from the algorithm type, and need not be explicitly
included in the option.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ KEK Alg ID | Encrypted Key ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o KEK Alg ID (8 bits) -- This field contains an algorithm type to be
used with the key encrypting key.
o Encrypted Key (variable). The size of the encrypted key field
depends upon the size of the encrypted key (see below).
3.3.1. KEK Algorithm ID Types
The following algorithms are suitable to be used with a key
encrypting key.
Weis, et al. Expires June 5, 2006 [Page 8]
Internet-Draft TCP MAC Option December 2005
AES-128-ECB. The MAC key is encrypted using an AES 128-bit key
encrypting key, resulting in a 128-bit encrypted key. Use of ECB
mode is acceptable because only one block is being encrypted.
This algorithm MUST NOT be used to encrypt a MAC key larger than
128 bits. (An example of an algorithm that could be used to
encrypt a MAC larger than 128 bits is the NIST Key Wrap
[KEYWRAP].)
Weis, et al. Expires June 5, 2006 [Page 9]
Internet-Draft TCP MAC Option December 2005
4. Discussion
4.1. Key Management Methods
Experience with key management for RFC 2385 have shown that key
management for TCP option keys is subject to varying operational
constraints. A single pre-configured MAC key is neither secure, nor
operationally sound. This proposal provides for several different
methods of managing multiple MAC keys, depending on the operational
requirements of the communicating TCP end-points. Two of these
methods are described in detail below.
4.1.1. Locally Managed MAC Keys
In this method, two TCP end-points each configure one or more MAC
keys. When keys have a unique Key ID, it is placed in the option
header to declare which key was used to calculated the MAC. In order
to guarantee that keys are not used longer than their cryptographic
lifetime, keys must be periodically changed. Some methods of
changing keys is described in [I-D.ramaiah-key-rollover].
When locally managed MAC keys are used, the proposed option only
contains the option header and authentication data. K in the option
header is never set to 1 when locally managed MAC keys are used. A
MAC algorithm requiring a nonce MUST NOT be used in this mode due to
the risk of re-using a nonce.
4.1.2. Automatic Generation of Keys
In this method, the two TCP end-points configure one or more KEKs
having a long lifetime. A KEK is used to encrypt a randomly
generated MAC key, which is then included in the Encrypted Key
portion of the TCP option. This allows for the scheduled automatic
generation of keys that can be periodically replaced or based on the
policy of either TCP.
Each KEK has a Key ID associated with it. When a particular KEK is
used to generate a MAC key, the TCP endpoint places its Key ID in the
option header to declare which key was used to encrypt the MAC key.
When a TCP end-point begins to send with a new key, it SHOULD retain
the previous key until the peer also begins to encrypt using the new
key. Doing so allows a continued receipt of TCP segments from the
peer, including ack messages indicating that the segment with the new
MAC key was not received.
MAC algorithms requiring a nonce can be used safely, since the keys
are randomly chosen.
Weis, et al. Expires June 5, 2006 [Page 10]
Internet-Draft TCP MAC Option December 2005
4.2. MAC Option Size
The cumulative number of TCP option bytes is currently limited to 40
bytes. The TCP MAC Option can consume more or fewer bytes, depending
on a number of factors. The following sections describe several
scenarios.
4.2.1. Authentication Data Only
The option consumes four bytes for the option header. If K is not
set to one, then the total size of the TCP MAC option is only the
additional number of bytes needed by the MAC algorithm. All MAC
algorithms described in this proposal not requiring a nonce require
12 bytes. This gives a total of 16 bytes for the TCP MAC option,
which is four bytes less than used by RFC 2385.
MAC algorithms requiring a nonce require an additional four bytes to
carry a sequence number in the authentication data portion of the
option. This results in a total of 20 bytes. However, MAC
algorithms requiring a nonce tend to consume fewer software and/or
hardware resources than other MAC algorithms. Using a MAC algorithm
requiring a nonce trades off of an additional four bytes in the
segment for a faster cryptographic algorithm.
4.2.2. Adding an Encrypted Key
If K is set to one, then the encrypted key field is added to the MAC
option. This adds the ability to do in-band keying, and simplify key
management operations, but with a cost of additional TCP option
bytes. When an encrypted key is included, one byte is always needed
to describe the KEK algorithm used to encrypt the MAC key. The KEK
algorithm also determines the number of bytes needed for the
encrypted MAC key. The one KEK algorithm defined in this proposal
requires 16 bytes, which results in a total of 17 bytes for the
encrypted key.
Thus, 33 bytes total bytes are required when paired with a MAC
algorithm not needing a nonce (although 36 bytes may be used if
padding is added). A total of 37 bytes are required when paired with
a MAC algorithm needing a nonce (or 40 bytes if padding is added).
However, the encrypted key is only required when one of the TCP end-
points requires a new key (i.e., at the start of a TCP session, or
when the security policy mandates a change later on in the session.)
All other segments in the TCP session contain only the Authentication
Data portion, which remains a modest size.
Weis, et al. Expires June 5, 2006 [Page 11]
Internet-Draft TCP MAC Option December 2005
5. IANA Considerations
The terms "Standards Action" and "Private Use" in this section
indicate the polices described for these terms in [RFC2434].
A new TCP Option Kind value must be defined in the IANA TCP
Parameters registry.
The option header contains an 8-bit message type, for which IANA is
to create and maintain a registry entitled "MAC Algorithm IDs". This
document defines the following message authentication code types:
MAC Algorithm ID Value
---------------- -----
RESERVED 0
HMAC-SHA-1-96 1
AES-128-GMAC-96 2
AES-128-CMAC-96 3
AES-128-UMAC-96 4
Standards Action 5-64
Private Use 65-127
The option header contains an 8-bit message type, for which IANA is
to create and maintain a registry entitled "Key Encrypting Key
Algorithm IDs". This document defines the following KEK types:
KEK Algorithm ID Value
---------------- -----
RESERVED 0
AES-128-ECB 1
Standards Action 2-128
Private Use 129-254
Note to RFC Editor: this section may be removed on publication as an
RFC.
Weis, et al. Expires June 5, 2006 [Page 12]
Internet-Draft TCP MAC Option December 2005
6. Security Considerations
This proposal describes a strong authentication method for
authenticating TCP segments. It defines the use of cryptographic MAC
algorithms, which are considered state-of-the-art. As such, their
expected lifetime of usefulness extends for several years. But
cryptographic algorithms have an effective lifetime, depending on
advancing processor speed and cryptographic research. This proposal
provides for the future addition of new MAC algorithms as they are
needed.
MAC algorithms requiring a unique nonce per segments (e.g., AES-128-
GMAC-96) MUST NOT be used be used with manually configured keys. If
the sequence number used as an input to the nonce wraps (or is re-
initializing after a system reboot), a single nonce would be used
multiple times with a single key. This would cause a catastrophic
cryptographic failure, with the amount of damage dependant upon the
actual algorithm.
Management of RFC 2385 keys has been a significant operational
problem, both in terms of key synchronization and key selection.
Current guidance [RFC3562] warns against sharing RFC 2385 keys
between systems, and recommends changing keys according to a
schedule. The same general operational issues are relevant for the
management of MAC keys. This proposal allows for in-band automatic
re-keying, which provides the following key management benefits:
o Automated key lifetime management. A system can rollover keys
triggered by any means chosen by the system (e.g., volume
lifetime, time lifetime).
o Automated key selection. Keys chosen with a good random number
generator are superior in quality to manually chosen keys.
o Keys are chosen for use of a particular TCP session, and not
shared between TCP session to different peers.
Use of in-line key management requires a static KEK with a long
lifetime. Whereas the KEK needs to be changed periodically, the
length of the period should be very long, compared to the lifetime of
the MAC keys.
Weis, et al. Expires June 5, 2006 [Page 13]
Internet-Draft TCP MAC Option December 2005
7. References
7.1. Normative References
[FIPS.197.2001]
National Institute of Standards and Technology, "Advanced
Encryption Standard (AES)", FIPS PUB 197, November 2001, <
http://csrc.nist.gov/publications/fips/fips197/
fips-197.pdf>.
[FIPS.198.2002]
National Institute of Standards and Technology, "The
Keyed-Hash Message Authentication Code (HMAC)", FIPS PUB
198, March 2002, <http://csrc.nist.gov/publications/fips/
fips198/fips-198a.pdf>.
[FIPS.800-38B]
National Institute of Standards and Technology,
"Recommendation for Block Cipher Modes of Operation: The
CMAC Mode for Authentication", FIPS PUB 800-38B, May 2005,
<http://csrc.nist.gov/publications/nistpubs/800-38B/
SP_800-38B.pdf>.
[GMAC] McGrew, D. and J. Viega, "Galois/Counter Mode of Operation
(GCM)", Submission to NIST modes of operation, May 2005,
<http://csrc.nist.gov/CryptoToolkit/modes/proposedmodes/
gcm/gcm-revised-spec.pdf>.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, September 1981.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
7.2. Informative References
[I-D.ietf-idr-bgp4]
Rekhter, Y., "A Border Gateway Protocol 4 (BGP-4)",
draft-ietf-idr-bgp4-26 (work in progress), October 2004.
[I-D.ramaiah-key-rollover]
Ramaiah, A., Mynam, S., and C. Appanna, "Key rollover
schemes for TCP-based routing applications",
draft-ramaiah-key-rollover-00 (work in progress),
Weis, et al. Expires June 5, 2006 [Page 14]
Internet-Draft TCP MAC Option December 2005
November 2005.
[KDM] Black, J., Rogaway, P., and T. Shrimpton, "Encryption-
Scheme Security in the Presence of Key-Dependent
Messages", Selected Areas in Cryptography 2002 (SAC 2002),
Lecture Notes in Computer Science, vol. 2595, Springer-
Verlag, 2003., May 2002,
<http://www.cs.ucdavis.edu/~rogaway/papers/kdm.html>.
[KEYWRAP] "Draft NIST AES Key Wrap Specification", November 2001,
<http://csrc.nist.gov/CryptoToolkit/kms/key-wrap.pdf>.
[MACS] Bellare, M., Canetti, R., and H. Krawczyk, "Keying Hash
Functions for Message Authentication", Proceedings of
Crypto'96 , LNCS 1109, pp. 1-15., June 1996, <An extended
version of this paper is available at
http://www.research.ibm.com/security/bck2.ps>.
[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.
Weis, et al. Expires June 5, 2006 [Page 15]
Internet-Draft TCP MAC Option December 2005
Authors' Addresses
Brian Weis
Cisco Systems
170 W. Tasman Drive
San Jose, California 95134-1706
USA
Phone: +1-408-526-4796
Email: bew@cisco.com
Chandrashekhar Appanna
Cisco Systems
170 W. Tasman Drive
San Jose, California 95134-1706
USA
Phone: +1-408-526-6198
Email: achandra@cisco.com
David McGrew
Cisco Systems
170 W. Tasman Drive
San Jose, California 95134-1706
USA
Phone: +1-301-349-5815
Email: mcgrew@cisco.com
Anantha Ramaiah
Cisco Systems
170 W. Tasman Drive
San Jose, California 95134-1706
USA
Phone: +1-408-525-6486
Email: ananth@cisco.com
Weis, et al. Expires June 5, 2006 [Page 16]
Internet-Draft TCP MAC Option December 2005
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 (2005). 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.
Weis, et al. Expires June 5, 2006 [Page 17]
