doc: Add RFC documents

1 files changed, 675 insertions, 0 deletions

diff --git a/doc/rfc/rfc4344.txt b/doc/rfc/rfc4344.txt
new file mode 100644
index 0000000..44f0e44
--- /dev/null
+++ b/doc/rfc/rfc4344.txt
@@ -0,0 +1,675 @@
+
+
+
+
+
+
+Network Working Group                                         M. Bellare
+Request for Comments: 4344                                      T. Kohno
+Category: Standards Track                                   UC San Diego
+                                                           C. Namprempre
+                                                    Thammasat University
+                                                            January 2006
+
+
+        The Secure Shell (SSH) Transport Layer Encryption Modes
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2006).
+
+Abstract
+
+   Researchers have discovered that the authenticated encryption portion
+   of the current SSH Transport Protocol is vulnerable to several
+   attacks.
+
+   This document describes new symmetric encryption methods for the
+   Secure Shell (SSH) Transport Protocol and gives specific
+   recommendations on how frequently SSH implementations should rekey.
+
+Table of Contents
+
+   1. Introduction ....................................................2
+   2. Conventions Used in This Document ...............................2
+   3. Rekeying ........................................................2
+      3.1. First Rekeying Recommendation ..............................3
+      3.2. Second Rekeying Recommendation .............................3
+   4. Encryption Modes ................................................3
+   5. IANA Considerations .............................................6
+   6. Security Considerations .........................................6
+      6.1. Rekeying Considerations ....................................7
+      6.2. Encryption Method Considerations ...........................8
+   Normative References ...............................................9
+   Informative References ............................................10
+
+
+
+
+
+Bellare, et al.             Standards Track                     [Page 1]
+
+RFC 4344          SSH Transport Layer Encryption Modes      January 2006
+
+
+1.  Introduction
+
+   The symmetric portion of the SSH Transport Protocol was designed to
+   provide both privacy and integrity of encapsulated data.  Researchers
+   ([DAI,BKN1,BKN2]) have, however, identified several security problems
+   with the symmetric portion of the SSH Transport Protocol, as
+   described in [RFC4253].  For example, the encryption mode specified
+   in [RFC4253] is vulnerable to a chosen-plaintext privacy attack.
+   Additionally, if not rekeyed frequently enough, the SSH Transport
+   Protocol may leak information about payload data.  This latter
+   property is true regardless of what encryption mode is used.
+
+   In [BKN1,BKN2], Bellare, Kohno, and Namprempre show how to modify the
+   symmetric portion of the SSH Transport Protocol so that it provably
+   preserves privacy and integrity against chosen-plaintext, chosen-
+   ciphertext, and reaction attacks.  This document instantiates the
+   recommendations described in [BKN1,BKN2].
+
+2.  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].
+
+   The used data types and terminology are specified in the architecture
+   document [RFC4251].
+
+   The SSH Transport Protocol is specified in the transport document
+   [RFC4253].
+
+3.  Rekeying
+
+   Section 9 of [RFC4253] suggests that SSH implementations rekey after
+   every gigabyte of transmitted data.  [RFC4253] does not, however,
+   discuss all the problems that could arise if an SSH implementation
+   does not rekey frequently enough.  This section serves to strengthen
+   the suggestion in [RFC4253] by giving firm upper bounds on the
+   tolerable number of encryptions between rekeying operations.  In
+   Section 6, we discuss the motivation for these rekeying
+   recommendations in more detail.
+
+   This section makes two recommendations.  Informally, the first
+   recommendation is intended to protect against possible information
+   leakage through the MAC tag, and the second recommendation is
+   intended to protect against possible information leakage through the
+   block cipher.  Note that, depending on the block length of the
+
+
+
+
+
+Bellare, et al.             Standards Track                     [Page 2]
+
+RFC 4344          SSH Transport Layer Encryption Modes      January 2006
+
+
+   underlying block cipher and the length of the encrypted packets, the
+   first recommendation may supersede the second recommendation, or vice
+   versa.
+
+3.1.  First Rekeying Recommendation
+
+   Because of possible information leakage through the MAC tag, SSH
+   implementations SHOULD rekey at least once every 2**32 outgoing
+   packets.  More explicitly, after a key exchange, an SSH
+   implementation SHOULD NOT send more than 2**32 packets before
+   rekeying again.
+
+   SSH implementations SHOULD also attempt to rekey before receiving
+   more than 2**32 packets since the last rekey operation.  The
+   preferred way to do this is to rekey after receiving more than 2**31
+   packets since the last rekey operation.
+
+3.2.  Second Rekeying Recommendation
+
+   Because of a birthday property of block ciphers and some modes of
+   operation, implementations must be careful not to encrypt too many
+   blocks with the same encryption key.
+
+   Let L be the block length (in bits) of an SSH encryption method's
+   block cipher (e.g., 128 for AES).  If L is at least 128, then, after
+   rekeying, an SSH implementation SHOULD NOT encrypt more than 2**(L/4)
+   blocks before rekeying again.  If L is at least 128, then SSH
+   implementations should also attempt to force a rekey before receiving
+   more than 2**(L/4) blocks.  If L is less than 128 (which is the case
+   for older ciphers such as 3DES, Blowfish, CAST-128, and IDEA), then,
+   although it may be too expensive to rekey every 2**(L/4) blocks, it
+   is still advisable for SSH implementations to follow the original
+   recommendation in [RFC4253]: rekey at least once for every gigabyte
+   of transmitted data.
+
+   Note that if L is less than or equal to 128, then the recommendation
+   in this subsection supersedes the recommendation in Section 3.1.  If
+   an SSH implementation uses a block cipher with a larger block size
+   (e.g., Rijndael with 256-bit blocks), then the recommendations in
+   Section 3.1 may supersede the recommendations in this subsection
+   (depending on the lengths of the packets).
+
+4.  Encryption Modes
+
+   This document describes new encryption methods for use with the SSH
+   Transport Protocol.  These encryption methods are in addition to the
+   encryption methods described in Section 6.3 of [RFC4253].
+
+
+
+
+Bellare, et al.             Standards Track                     [Page 3]
+
+RFC 4344          SSH Transport Layer Encryption Modes      January 2006
+
+
+   Recall from [RFC4253] that the encryption methods in each direction
+   of an SSH connection MUST run independently of each other and that,
+   when encryption is in effect, the packet length, padding length,
+   payload, and padding fields of each packet MUST be encrypted with the
+   chosen method.  Further recall that the total length of the
+   concatenation of the packet length, padding length, payload, and
+   padding MUST be a multiple of the cipher's block size when the
+   cipher's block size is greater than or equal to 8 bytes (which is the
+   case for all of the following methods).
+
+   This document describes the following new methods:
+
+     aes128-ctr       RECOMMENDED       AES (Rijndael) in SDCTR mode,
+                                        with 128-bit key
+     aes192-ctr       RECOMMENDED       AES with 192-bit key
+     aes256-ctr       RECOMMENDED       AES with 256-bit key
+     3des-ctr         RECOMMENDED       Three-key 3DES in SDCTR mode
+     blowfish-ctr     OPTIONAL          Blowfish in SDCTR mode
+     twofish128-ctr   OPTIONAL          Twofish in SDCTR mode,
+                                        with 128-bit key
+     twofish192-ctr   OPTIONAL          Twofish with 192-bit key
+     twofish256-ctr   OPTIONAL          Twofish with 256-bit key
+     serpent128-ctr   OPTIONAL          Serpent in SDCTR mode, with
+                                        128-bit key
+     serpent192-ctr   OPTIONAL          Serpent with 192-bit key
+     serpent256-ctr   OPTIONAL          Serpent with 256-bit key
+     idea-ctr         OPTIONAL          IDEA in SDCTR mode
+     cast128-ctr      OPTIONAL          CAST-128 in SDCTR mode,
+                                        with 128-bit key
+
+   The label <cipher>-ctr indicates that the block cipher <cipher> is to
+   be used in "stateful-decryption counter" (SDCTR) mode.  Let L be the
+   block length of <cipher> in bits.  In stateful-decryption counter
+   mode, both the sender and the receiver maintain an internal L-bit
+   counter X.  The initial value of X should be the initial IV (as
+   computed in Section 7.2 of [RFC4253]) interpreted as an L-bit
+   unsigned integer in network-byte-order.  If X=(2**L)-1, then
+   "increment X" has the traditional semantics of "set X to 0."  We use
+   the notation <X> to mean "convert X to an L-bit string in network-
+   byte-order."  Naturally, implementations may differ in how the
+   internal value X is stored.  For example, implementations may store X
+   as multiple unsigned 32-bit counters.
+
+   To encrypt a packet P=P1||P2||...||Pn (where P1, P2, ..., Pn are each
+   blocks of length L), the encryptor first encrypts <X> with <cipher>
+   to obtain a block B1.  The block B1 is then XORed with P1 to generate
+   the ciphertext block C1.  The counter X is then incremented, and the
+   process is repeated for each subsequent block in order to generate
+
+
+
+Bellare, et al.             Standards Track                     [Page 4]
+
+RFC 4344          SSH Transport Layer Encryption Modes      January 2006
+
+
+   the entire ciphertext C=C1||C2||...||Cn corresponding to the packet
+   P.  Note that the counter X is not included in the ciphertext.  Also
+   note that the keystream can be pre-computed and that encryption is
+   parallelizable.
+
+   To decrypt a ciphertext C=C1||C2||...||Cn, the decryptor (who also
+   maintains its own copy of X) first encrypts its copy of <X> with
+   <cipher> to generate a block B1 and then XORs B1 to C1 to get P1.
+   The decryptor then increments its copy of the counter X and repeats
+   the above process for each block to obtain the plaintext packet
+   P=P1||P2||...||Pn.  As before, the keystream can be pre-computed, and
+   decryption is parallelizable.
+
+   The "aes128-ctr" method uses AES (the Advanced Encryption Standard,
+   formerly Rijndael) with 128-bit keys [AES].  The block size is 16
+   bytes.
+
+      At this time, it appears likely that a future specification will
+      promote aes128-ctr to be REQUIRED; implementation of this
+      algorithm is very strongly encouraged.
+
+   The "aes192-ctr" method uses AES with 192-bit keys.
+
+   The "aes256-ctr" method uses AES with 256-bit keys.
+
+   The "3des-ctr" method uses three-key triple-DES (encrypt-decrypt-
+   encrypt), where the first 8 bytes of the key are used for the first
+   encryption, the next 8 bytes for the decryption, and the following 8
+   bytes for the final encryption.  This requires 24 bytes of key data
+   (of which 168 bits are actually used).  The block size is 8 bytes.
+   This algorithm is defined in [DES].
+
+   The "blowfish-ctr" method uses Blowfish with 256-bit keys [SCHNEIER].
+   The block size is 8 bytes.  (Note that "blowfish-cbc" from [RFC4253]
+   uses 128-bit keys.)
+
+   The "twofish128-ctr" method uses Twofish with 128-bit keys [TWOFISH].
+   The block size is 16 bytes.
+
+   The "twofish192-ctr" method uses Twofish with 192-bit keys.
+
+   The "twofish256-ctr" method uses Twofish with 256-bit keys.
+
+   The "serpent128-ctr" method uses the Serpent block cipher [SERPENT]
+   with 128-bit keys.  The block size is 16 bytes.
+
+   The "serpent192-ctr" method uses Serpent with 192-bit keys.
+
+
+
+
+Bellare, et al.             Standards Track                     [Page 5]
+
+RFC 4344          SSH Transport Layer Encryption Modes      January 2006
+
+
+   The "serpent256-ctr" method uses Serpent with 256-bit keys.
+
+   The "idea-ctr" method uses the IDEA cipher [SCHNEIER].  The block
+   size is 8 bytes.
+
+   The "cast128-ctr" method uses the CAST-128 cipher with 128-bit keys
+   [RFC2144].  The block size is 8 bytes.
+
+5.  IANA Considerations
+
+   The thirteen encryption algorithm names defined in Section 4 have
+   been added to the Secure Shell Encryption Algorithm Name registry
+   established by Section 4.11.1 of [RFC4250].
+
+6.  Security Considerations
+
+   This document describes additional encryption methods and
+   recommendations for the SSH Transport Protocol [RFC4253].
+   [BKN1,BKN2] prove that if an SSH application incorporates the methods
+   and recommendations described in this document, then the symmetric
+   cryptographic portion of that application will resist a large class
+   of privacy and integrity attacks.
+
+   This section is designed to help implementors understand the
+   security-related motivations for, as well as possible consequences of
+   deviating from, the methods and recommendations described in this
+   document.  Additional motivation and discussion, as well as proofs of
+   security, appear in the research papers [BKN1,BKN2].
+
+   Please note that the notion of "prove" in the context of [BKN1,BKN2]
+   is that of practice-oriented reductionist security: if an attacker is
+   able to break the symmetric portion of the SSH Transport Protocol
+   using a certain type of attack (e.g., a chosen-ciphertext attack),
+   then the attacker will also be able to break one of the transport
+   protocol's underlying components (e.g., the underlying block cipher
+   or MAC).  If we make the reasonable assumption that the underlying
+   components (such as AES and HMAC-SHA1) are secure, then the attacker
+   against the symmetric portion of the SSH protocol cannot be very
+   successful (since otherwise there would be a contradiction).  Please
+   see [BKN1,BKN2] for details.  In particular, attacks are not
+   impossible, just extremely improbable (unless the building blocks,
+   like AES, are insecure).
+
+   Note also that cryptography often plays only a small (but critical)
+   role in an application's overall security.  In the case of the SSH
+   Transport Protocol, even though an application might implement the
+   symmetric portion of the SSH protocol exactly as described in this
+   document, the application may still be vulnerable to non-protocol-
+
+
+
+Bellare, et al.             Standards Track                     [Page 6]
+
+RFC 4344          SSH Transport Layer Encryption Modes      January 2006
+
+
+   based attacks (as an egregious example, an application might save
+   cryptographic keys in cleartext to an unprotected file).
+   Consequently, even though the methods described herein come with
+   proofs of security, developers must still execute caution when
+   developing applications that implement these methods.
+
+6.1.  Rekeying Considerations
+
+   Section 3 of this document makes two rekeying recommendations: (1)
+   rekey at least once every 2**32 packets, and (2) rekey after a
+   certain number of encrypted blocks (e.g., 2**(L/4) blocks if the
+   block cipher's block length L is at least 128 bits).  The motivations
+   for recommendations (1) and (2) are different, and we consider each
+   recommendation in turn.  Briefly, (1) is designed to protect against
+   information leakage through the SSH protocol's underlying MAC, and
+   (2) is designed to protect against information leakage through the
+   SSH protocol's underlying encryption scheme.  Please note that,
+   depending on the encryption method's block length L and the number of
+   blocks encrypted per packet, recommendation (1) may supersede
+   recommendation (2) or vice versa.
+
+   Recommendation (1) states that SSH implementations should rekey at
+   least once every 2**32 packets.  If more than 2**32 packets are
+   encrypted and MACed by the SSH Transport Protocol between rekeyings,
+   then the SSH Transport Protocol may become vulnerable to replay and
+   re-ordering attacks.  This means that an adversary may be able to
+   convince the receiver to accept the same message more than once or to
+   accept messages out of order.  Additionally, the underlying MAC may
+   begin to leak information about the protocol's payload data.  In more
+   detail, an adversary looks for a collision between the MACs
+   associated to two packets that were MACed with the same 32-bit
+   sequence number (see Section 4.4 of [RFC4253]).  If a collision is
+   found, then the payload data associated with those two ciphertexts is
+   probably identical.  Note that this problem occurs regardless of how
+   secure the underlying encryption method is.  Also note that although
+   compressing payload data before encrypting and MACing and the use of
+   random padding may reduce the risk of information leakage through the
+   underlying MAC, compression and the use of random padding will not
+   prevent information leakage.  Implementors who decide not to rekey at
+   least once every 2**32 packets should understand these issues.  These
+   issues are discussed further in [BKN1,BKN2].
+
+   One alternative to recommendation (1) would be to make the SSH
+   Transport Protocol's sequence number more than 32 bits long.  This
+   document does not suggest increasing the length of the sequence
+   number because doing so could hinder interoperability with older
+   versions of the SSH protocol.  Another alternative to recommendation
+   (1) would be to switch from basic HMAC to a another MAC, such as a
+
+
+
+Bellare, et al.             Standards Track                     [Page 7]
+
+RFC 4344          SSH Transport Layer Encryption Modes      January 2006
+
+
+   MAC that has its own internal counter.  Because of the 32-bit counter
+   already present in the protocol, such a counter would only need to be
+   incremented once every 2**32 packets.
+
+   Recommendation (2) states that SSH implementations should rekey
+   before encrypting more than 2**(L/4) blocks with the same key
+   (assuming L is at least 128).  This recommendation is designed to
+   minimize the risk of birthday attacks against the encryption method's
+   underlying block cipher.  For example, there is a theoretical privacy
+   attack against stateful-decryption counter mode if an adversary is
+   allowed to encrypt approximately 2**(L/2) messages with the same key.
+   It is because of these birthday attacks that implementors are highly
+   encouraged to use secure block ciphers with large block lengths.
+   Additionally, recommendation (2) is designed to protect an encryptor
+   from encrypting more than 2**L blocks with the same key.  The
+   motivation here is that, if an encryptor were to use SDCTR mode to
+   encrypt more than 2**L blocks with the same key, then the encryptor
+   would reuse keystream, and the reuse of keystream can lead to serious
+   privacy attacks [SCHNEIER].
+
+6.2.  Encryption Method Considerations
+
+   Researchers have shown that the original CBC-based encryption methods
+   in [RFC4253] are vulnerable to chosen-plaintext privacy attacks
+   [DAI,BKN1,BKN2].  The new stateful-decryption counter mode encryption
+   methods described in Section 4 of this document were designed to be
+   secure replacements to the original encryption methods described in
+   [RFC4253].
+
+   Many people shy away from counter mode-based encryption schemes
+   because, when used incorrectly (such as when the keystream is allowed
+   to repeat), counter mode can be very insecure.  Fortunately, the
+   common concerns with counter mode do not apply to SSH because of the
+   rekeying recommendations and because of the additional protection
+   provided by the transport protocol's MAC.  This discussion is
+   formalized with proofs of security in [BKN1,BKN2].
+
+   As an additional note, when one of the stateful-decryption counter
+   mode encryption methods (Section 4) is used, then the padding
+   included in an SSH packet (Section 4 of [RFC4253]) need not be (but
+   can still be) random.  This eliminates the need to generate
+   cryptographically secure pseudorandom bytes for each packet.
+
+   One property of counter mode encryption is that it does not require
+   that messages be padded to a multiple of the block cipher's block
+   length.  Although not padding messages can reduce the protocol's
+   network consumption, this document requires that padding be a
+   multiple of the block cipher's block length in order to (1) not alter
+
+
+
+Bellare, et al.             Standards Track                     [Page 8]
+
+RFC 4344          SSH Transport Layer Encryption Modes      January 2006
+
+
+   the packet description in [RFC4253] and (2) not leak precise
+   information about the length of the packet's payload data.  (Although
+   there may be some network savings from padding to only 8-bytes even
+   if the block cipher uses 16-byte blocks, because of (1) we do not
+   make that recommendation here.)
+
+   In addition to stateful-decryption counter mode, [BKN1,BKN2] describe
+   other provably secure encryption methods for use with the SSH
+   Transport Protocol.  The stateful-decryption counter mode methods in
+   Section 4 are, however, the preferred alternatives to the insecure
+   methods in [RFC4253] because stateful-decryption counter mode is the
+   most efficient (in terms of both network consumption and the number
+   of required cryptographic operations per packet).
+
+Normative References
+
+   [AES]       National Institute of Standards and Technology, "Advanced
+               Encryption Standard (AES)", Federal Information
+               Processing Standards Publication 197, November 2001.
+
+   [DES]       National Institute of Standards and Technology, "Data
+               Encryption Standard (DES)", Federal Information
+               Processing Standards Publication 46-3, October 1999.
+
+   [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
+               Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2144]   Adams, C., "The CAST-128 Encryption Algorithm", RFC 2144,
+               May 1997.
+
+   [RFC4250]   Lehtinen, S. and C. Lonvick, Ed., "The Secure Shell (SSH)
+               Protocol Assigned Numbers", RFC 4250, January 2006.
+
+   [RFC4251]   Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
+               Protocol Architecture", RFC 4251, January 2006.
+
+   [RFC4253]   Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
+               Transport Layer Protocol", RFC 4253, January 2006.
+
+   [SCHNEIER]  Schneier, B., "Applied Cryptography Second Edition:
+               Protocols algorithms and source in code in C", Wiley,
+               1996.
+
+   [SERPENT]   Anderson, R., Biham, E., and Knudsen, L., "Serpent: A
+               proposal for the Advanced Encryption Standard", NIST AES
+               Proposal, 1998.
+
+
+
+
+
+Bellare, et al.             Standards Track                     [Page 9]
+
+RFC 4344          SSH Transport Layer Encryption Modes      January 2006
+
+
+   [TWOFISH]   Schneier, B., et al., "The Twofish Encryptions Algorithm:
+               A 128-bit block cipher, 1st Edition", Wiley, 1999.
+
+Informative References
+
+   [BKN1]      Bellare, M., Kohno, T., and Namprempre, C.,
+               "Authenticated Encryption in SSH: Provably Fixing the SSH
+               Binary Packet Protocol", Ninth ACM Conference on Computer
+               and Communications Security, 2002.
+
+   [BKN2]      Bellare, M., Kohno, T., and Namprempre, C., "Breaking and
+               Provably Repairing the SSH Authenticated Encryption
+               Scheme: A Case Study of the Encode-then-Encrypt-and-MAC
+               Paradigm", ACM Transactions on Information and System
+               Security, 7(2), May 2004.
+
+   [DAI]       Dai, W., "An Attack Against SSH2 Protocol", Email to the
+               ietf-ssh@netbsd.org email list, 2002.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bellare, et al.             Standards Track                    [Page 10]
+
+RFC 4344          SSH Transport Layer Encryption Modes      January 2006
+
+
+Authors' Addresses
+
+   Mihir Bellare
+   Department of Computer Science and Engineering
+   University of California at San Diego
+   9500 Gilman Drive, MC 0404
+   La Jolla, CA 92093-0404
+
+   Phone: +1 858-534-8833
+   EMail: mihir@cs.ucsd.edu
+
+
+   Tadayoshi Kohno
+   Department of Computer Science and Engineering
+   University of California at San Diego
+   9500 Gilman Drive, MC 0404
+   La Jolla, CA 92093-0404
+
+   Phone: +1 858-534-8833
+   EMail: tkohno@cs.ucsd.edu
+
+
+   Chanathip Namprempre
+   Thammasat University
+   Faculty of Engineering
+   Electrical Engineering Department
+   Rangsit Campus, Klong Luang
+   Pathumthani, Thailand 12121
+
+   EMail: meaw@alum.mit.edu
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bellare, et al.             Standards Track                    [Page 11]
+
+RFC 4344          SSH Transport Layer Encryption Modes      January 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.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is provided by the IETF
+   Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Bellare, et al.             Standards Track                    [Page 12]
+