draft-ietf-secsh-newmodes-02.txt   draft-ietf-secsh-newmodes-03.txt 
Network Working Group M. Bellare Network Working Group M. Bellare
Internet-Draft T. Kohno Internet-Draft T. Kohno
Expires: November 27, 2004 UC San Diego Expires: September 22, 2005 UC San Diego
C. Namprempre C. Namprempre
Thammasat University Thammasat University
May 27, 2004 March 22, 2005
SSH Transport Layer Encryption Modes SSH Transport Layer Encryption Modes
draft-ietf-secsh-newmodes-02.txt draft-ietf-secsh-newmodes-03.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is subject to all provisions
all provisions of Section 10 of RFC2026. of Section 3 of RFC 3667. 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 become aware will be disclosed, in accordance with
RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on November 27, 2004. This Internet-Draft will expire on September 22, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract Abstract
Researchers have recently discovered that the authenticated Researchers have recently discovered that the authenticated
encryption portion of the current SSH Transport Protocol is encryption portion of the current SSH Transport Protocol is
vulnerable to several attacks. vulnerable to several attacks.
skipping to change at page 2, line 15 skipping to change at page 2, line 19
Bellare, Kohno, and Namprempre [ACM CCS 2002] prove that if an SSH Bellare, Kohno, and Namprempre [ACM CCS 2002] prove that if an SSH
application implements the modifications described in this document, application implements the modifications described in this document,
then the symmetric cryptographic portion of that application will then the symmetric cryptographic portion of that application will
provably resist chosen-plaintext, chosen-ciphertext, reaction-based provably resist chosen-plaintext, chosen-ciphertext, reaction-based
privacy and integrity/authenticity attacks. privacy and integrity/authenticity attacks.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions Used in This Document . . . . . . . . . . . . . . 2 2. Conventions Used in This Document . . . . . . . . . . . . . . 3
3. Rekeying . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Rekeying . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1 First Rekeying Recommendation . . . . . . . . . . . . . . . . 3 3.1 First Rekeying Recommendation . . . . . . . . . . . . . . . . 3
3.2 Second Rekeying Recommendation . . . . . . . . . . . . . . . . 3 3.2 Second Rekeying Recommendation . . . . . . . . . . . . . . . . 3
4. Encryption Modes . . . . . . . . . . . . . . . . . . . . . . . 4 4. Encryption Modes . . . . . . . . . . . . . . . . . . . . . . . 4
5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
5.1 Rekeying Considerations . . . . . . . . . . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6
5.2 Encryption Method Considerations . . . . . . . . . . . . . . . 8 6.1 Rekeying Considerations . . . . . . . . . . . . . . . . . . . 7
6.2 Encryption Method Considerations . . . . . . . . . . . . . . . 8
Normative References . . . . . . . . . . . . . . . . . . . . . 9 Normative References . . . . . . . . . . . . . . . . . . . . . 9
Non-Normative References . . . . . . . . . . . . . . . . . . . 9 Non-Normative References . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 10
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 10 Intellectual Property Statement . . . . . . . . . . . . . . . 12
Disclaimer of Validity . . . . . . . . . . . . . . . . . . . . 12
Copyright Statement . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction 1. Introduction
The symmetric portion of the SSH Transport Protocol was designed to The symmetric portion of the SSH Transport Protocol was designed to
provide both privacy and integrity of encapsulated data. Researchers provide both privacy and integrity of encapsulated data. Researchers
([DAI,BKN]) have, however, recently identified several security ([DAI,BKN1,BKN2]) have, however, recently identified several security
problems with the symmetric portion of the SSH Transport Protocol as problems with the symmetric portion of the SSH Transport Protocol as
described in [SSH-TRANS]. For example, the encryption mode specified described in [SSH-TRANS]. For example, the encryption mode specified
in [SSH-TRANS] is vulnerable to a chosen-plaintext privacy attack. in [SSH-TRANS] is vulnerable to a chosen-plaintext privacy attack.
Additionally, if not rekeyed frequently enough, the SSH Transport Additionally, if not rekeyed frequently enough, the SSH Transport
Protocol may leak information about payload data. This latter Protocol may leak information about payload data. This latter
property is true regardless of what encryption mode is used. property is true regardless of what encryption mode is used.
In [BKN] Bellare, Kohno, and Namprempre show how to modify the In [BKN1,BKN2] Bellare, Kohno, and Namprempre show how to modify the
symmetric portion of the SSH Transport Protocol so that it provably symmetric portion of the SSH Transport Protocol so that it provably
preserves privacy and integrity against chosen-plaintext, chosen- preserves privacy and integrity against chosen-plaintext, chosen-
ciphertext, and reaction attacks. This document instantiates the ciphertext, and reaction attacks. This document instantiates the
recommendations described in [BKN]. recommendations described in [BKN1,BKN2].
2. Conventions Used in This Document 2. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
The used data types and terminology are specified in the architecture The used data types and terminology are specified in the architecture
document [SSH-ARCH]. document [SSH-ARCH].
skipping to change at page 6, line 28 skipping to change at page 6, line 33
The "serpent192-ctr" method uses Serpent with 192-bit keys. The "serpent192-ctr" method uses Serpent with 192-bit keys.
The "serpent256-ctr" method uses Serpent with 256-bit keys. The "serpent256-ctr" method uses Serpent with 256-bit keys.
The "idea-ctr" method uses the IDEA cipher [SCHNEIER]. IDEA is The "idea-ctr" method uses the IDEA cipher [SCHNEIER]. IDEA is
patented by Ascom AG. The block size is 8 bytes. patented by Ascom AG. The block size is 8 bytes.
The "cast128-ctr" method uses the CAST-128 cipher [RFC2144]. The The "cast128-ctr" method uses the CAST-128 cipher [RFC2144]. The
block size is 8 bytes. block size is 8 bytes.
5. Security Considerations 5. IANA Considerations
The twelve encryption algorithm names defined in Section 4 are to be
added to the Secure Shell Encryption Algorithm Name registry
established by Section 4.11.1 of [SSH-IANA].
6. Security Considerations
This document describes additional encryption methods and This document describes additional encryption methods and
recommendations for the SSH Transport Protocol [SSH-TRANS]. [BKN] recommendations for the SSH Transport Protocol [SSH-TRANS].
prove that if an SSH application incorporates the methods and [BKN1,BKN2] prove that if an SSH application incorporates the methods
recommendations described in this document, then the symmetric and recommendations described in this document, then the symmetric
cryptographic portion of that application will resist a large class cryptographic portion of that application will resist a large class
of privacy and integrity attacks. of privacy and integrity attacks.
This section is designed to help implementors understand the This section is designed to help implementors understand the
security-related motivations for, as well as possible consequences of security-related motivations for, as well as possible consequences of
deviating from, the methods and recommendations described in this deviating from, the methods and recommendations described in this
document. Additional motivation and discussion, as well as proofs of document. Additional motivation and discussion, as well as proofs of
security, appear in the research paper [BKN]. security, appear in the research paper [BKN1,BKN2].
Please note that the notion of "prove" in the context of [BKN] is Please note that the notion of "prove" in the context of [BKN1,BKN2]
that of practice-oriented reductionist security: if an attacker is is that of practice-oriented reductionist security: if an attacker is
able to break the symmetric portion of the SSH Transport Protocol able to break the symmetric portion of the SSH Transport Protocol
using a certain type of attack (e.g., a chosen-ciphertext attack), 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 then the attacker will also be able to break one of the transport
protocol's underlying components (e.g., the underlying block cipher protocol's underlying components (e.g., the underlying block cipher
or MAC). If we make the reasonable assumption that the underlying or MAC). If we make the reasonable assumption that the underlying
components (such as AES and HMAC-SHA1) are secure, then the attacker components (such as AES and HMAC-SHA1) are secure, then the attacker
against the symmetric portion of the SSH protocol cannot be very against the symmetric portion of the SSH protocol cannot be very
successful (since otherwise there would be a contradiction). Please successful (since otherwise there would be a contradiction). Please
see [BKN] for details. In particular, attacks are not impossible; see [BKN1,BKN2] for details. In particular, attacks are not
just extremely improbable (unless the building blocks, like AES, are impossible; just extremely improbable (unless the building blocks,
insecure). like AES, are insecure).
Note also that cryptography often plays only a small (but critical) Note also that cryptography often plays only a small (but critical)
role in an application's overall security. In the case of the SSH role in an application's overall security. In the case of the SSH
Transport Protocol, even though an application might implement the Transport Protocol, even though an application might implement the
symmetric portion of the SSH protocol exactly as described in this symmetric portion of the SSH protocol exactly as described in this
document, the application may still be vulnerable to non-protocol- document, the application may still be vulnerable to non-protocol-
based attacks (as an egregious example, an application might save based attacks (as an egregious example, an application might save
cryptographic keys in cleartext to an unprotected file). cryptographic keys in cleartext to an unprotected file).
Consequently, even though the methods described herein come with Consequently, even though the methods described herein come with
proofs of security, developers must still execute caution when proofs of security, developers must still execute caution when
developing applications that implement these methods. developing applications that implement these methods.
5.1 Rekeying Considerations 6.1 Rekeying Considerations
Section 3 of this document makes two rekeying recommendations: (1) Section 3 of this document makes two rekeying recommendations: (1)
rekey at least once every 2**32 packets and (2) rekey after a certain 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 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 cipher's block length L is at least 128 bits). The motivations for
recommendations (1) and (2) are different, and we consider each recommendations (1) and (2) are different, and we consider each
recommendation in turn. Briefly, (1) is designed to protect against recommendation in turn. Briefly, (1) is designed to protect against
information leakage through the SSH protocol's underlying MAC and (2) information leakage through the SSH protocol's underlying MAC and (2)
is designed to protect against information leakage through the SSH is designed to protect against information leakage through the SSH
protocol's underlying encryption scheme. Please note that, depending protocol's underlying encryption scheme. Please note that, depending
skipping to change at page 8, line 5 skipping to change at page 8, line 17
associated to two packets that were MACed with the same 32-bit associated to two packets that were MACed with the same 32-bit
sequence number (see Section 4.4 of [SSH-TRANS]); if a collision is sequence number (see Section 4.4 of [SSH-TRANS]); if a collision is
found, then the payload data associated with those two ciphertexts is found, then the payload data associated with those two ciphertexts is
probably identical. Note that this problem occurs regardless of how probably identical. Note that this problem occurs regardless of how
secure the underlying encryption method is. Also note that although secure the underlying encryption method is. Also note that although
compressing payload data before encrypting and MACing and the use of compressing payload data before encrypting and MACing and the use of
random padding may reduce the risk of information leakage through the random padding may reduce the risk of information leakage through the
underlying MAC, compression and the use of random padding will not underlying MAC, compression and the use of random padding will not
prevent information leakage. Implementors who decide not to rekey at prevent information leakage. Implementors who decide not to rekey at
least once every 2**32 packets should understand these issues. These least once every 2**32 packets should understand these issues. These
issues are discussed further in [BKN]. issues are discussed further in [BKN1,BKN2].
One alternative to recommendation (1) would be to make the SSH One alternative to recommendation (1) would be to make the SSH
Transport Protocol's sequence number more than 32 bits long. This Transport Protocol's sequence number more than 32 bits long. This
document does not suggest increasing the length of the sequence document does not suggest increasing the length of the sequence
number because doing so could hinder interoperability with older number because doing so could hinder interoperability with older
version of the SSH protocol. Another alternative to recommendation version of the SSH protocol. Another alternative to recommendation
(1) would be to switch from basic HMAC to a another MAC, such as a (1) would be to switch from basic HMAC to a another MAC, such as a
MAC that has its own internal counter (because of the 32-bit counter 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 already present in the protocol, such a counter would only need to be
incremented once every 2**32 packets). incremented once every 2**32 packets).
skipping to change at page 8, line 27 skipping to change at page 8, line 39
Recommendation (2) states that SSH implementations should rekey Recommendation (2) states that SSH implementations should rekey
before encrypting more than 2**(L/4) blocks with the same key before encrypting more than 2**(L/4) blocks with the same key
(assuming L is at least 128). This recommendation is designed to (assuming L is at least 128). This recommendation is designed to
minimize the risk of birthday attacks against the encryption method's minimize the risk of birthday attacks against the encryption method's
underlying block cipher. For example, there is a theoretical privacy underlying block cipher. For example, there is a theoretical privacy
attack against stateful-decryption counter mode if an adversary is attack against stateful-decryption counter mode if an adversary is
allowed to encrypt approximately 2**(L/2) messages with the same key. allowed to encrypt approximately 2**(L/2) messages with the same key.
It is because of these birthday attacks that implementors are highly It is because of these birthday attacks that implementors are highly
encouraged to use secure block ciphers with large block lengths. encouraged to use secure block ciphers with large block lengths.
5.2 Encryption Method Considerations 6.2 Encryption Method Considerations
Researchers have recently shown that the original CBC-based Researchers have recently shown that the original CBC-based
encryption methods in [SSH-TRANS] are vulnerable to chosen-plaintext encryption methods in [SSH-TRANS] are vulnerable to chosen-plaintext
privacy attacks [DAI,BKN]. The new stateful-decryption counter mode privacy attacks [DAI,BKN1,BKN2]. The new stateful-decryption counter
encryption methods described in Section 4 of this document were mode encryption methods described in Section 4 of this document were
designed to be secure replacements to the original encryption methods designed to be secure replacements to the original encryption methods
described in [SSH-TRANS]. described in [SSH-TRANS].
Many people shy away from counter mode-based encryption schemes Many people shy away from counter mode-based encryption schemes
because, when used incorrectly (such as when the keystream is allowed because, when used incorrectly (such as when the keystream is allowed
to repeat), counter mode can be very insecure. Fortunately, the to repeat), counter mode can be very insecure. Fortunately, the
common concerns with counter mode do not apply to SSH because of the common concerns with counter mode do not apply to SSH because of the
rekeying recommendations and because of the additional protection rekeying recommendations and because of the additional protection
provided by the transport protocol's MAC. This discussion is provided by the transport protocol's MAC. This discussion is
formalized with proofs of security in [BKN]. formalized with proofs of security in [BKN1,BKN2].
As an additional note, when one of the stateful-decryption counter As an additional note, when one of the stateful-decryption counter
mode encryption methods (Section 4) is used, then the padding mode encryption methods (Section 4) is used, then the padding
included in an SSH packet (Section 4 of [SSH-TRANS]) need not be (but included in an SSH packet (Section 4 of [SSH-TRANS]) need not be (but
can still be) random. This eliminates the need to generate can still be) random. This eliminates the need to generate
cryptographically-secure pseudorandom bytes for each packet. cryptographically-secure pseudorandom bytes for each packet.
One property of counter mode encryption is that it does not require One property of counter mode encryption is that it does not require
messages to be padded to a multiple of the block cipher's block messages to be padded to a multiple of the block cipher's block
length. Although not padding messages can reduce the protocol's length. Although not padding messages can reduce the protocol's
network consumption, this document requires padding to be a multiple network consumption, this document requires padding to be a multiple
of the block cipher's block length in order to (1) not alter the of the block cipher's block length in order to (1) not alter the
packet description in [SSH-TRANS] and (2) not leak precise packet description in [SSH-TRANS] and (2) not leak precise
information about the length of the packet's payload data. (Although information about the length of the packet's payload data. (Although
there may be some networks savings for padding to only 8-bytes even there may be some networks savings for padding to only 8-bytes even
if the block cipher uses 16-byte blocks, because of (1) we do not if the block cipher uses 16-byte blocks, because of (1) we do not
make that recommendation here.) make that recommendation here.)
In addition to stateful-decryption counter mode, [BKN] describe other In addition to stateful-decryption counter mode, [BKN1,BKN2] describe
provably-secure encryption methods for use with the SSH Transport other provably-secure encryption methods for use with the SSH
Protocol. The stateful-decryption counter mode methods in Section 4 Transport Protocol. The stateful-decryption counter mode methods in
are, however, the preferred alternatives to the insecure methods in Section 4 are, however, the preferred alternatives to the insecure
[SSH-TRANS] because stateful-decryption counter mode is the most methods in [SSH-TRANS] because stateful-decryption counter mode is
efficient (both in terms of network consumption and in terms of the the most efficient (both in terms of network consumption and in terms
number of required cryptographic operations per packet). of the number of required cryptographic operations per packet).
Normative References Normative References
[AES] Daemon, J. and Rijmen, V., "AES Proposal: Rijndael", [AES] Daemon, J. and Rijmen, V., "AES Proposal: Rijndael",
NIST AES Proposal, 1998. NIST AES Proposal, 1998.
[RFC2144] Adams, C., "The CAST-128 Encryption Algorithm", RFC [RFC2144] Adams, C., "The CAST-128 Encryption Algorithm", RFC
2144, May 1997. 2144, May 1997.
[SCHNEIER] Schneier, B., "Applied Cryptography Second Edition: [SCHNEIER] Schneier, B., "Applied Cryptography Second Edition:
Protocols algorithms and source in code in C", Wiley, Protocols algorithms and source in code in C", Wiley,
1996. 1996.
[SERPENT] Anderson, R., Biham, E., and Knudsen, L. "Serpent: A [SERPENT] Anderson, R., Biham, E., and Knudsen, L., "Serpent: A
proposal for the Advanced Encryption Standard", NIST proposal for the Advanced Encryption Standard", NIST
AES Proposal, 1998. AES Proposal, 1998.
[SSH-ARCH] Ylonen, T., et. al., "SSH Protocol Architecture", [SSH-ARCH] Ylonen, T. and Lonvick, C., "SSH Protocol
I-D draft-ietf-architecture-15.txt, October 2003. Architecture", I-D
draft-ietf-secsh-architecture-22.txt, March 2005.
[SSH-TRANS] Ylonen, T., et. al., "SSH Transport Layer Protocol", [SSH-IANA] Lehtinen, S. and Lonvick, C., "SSH Protocol Assigned
I-D draft-ietf-transport-17.txt, October 2003. Numbers", I-D
draft-ietf-secsh-assignednumbers-12.txt, March 2005.
[SSH-TRANS] Ylonen, T. and Lonvick, C., "SSH Transport Layer
Protocol", I-D draft-ietf-secsh-transport-24.txt,
March 2005.
[TWOFISH] Schneier, B., et. al., "The Twofish Encryptions [TWOFISH] Schneier, B., et. al., "The Twofish Encryptions
Algorithm: A 128-bit block cipher, 1st Edition", Algorithm: A 128-bit block cipher, 1st Edition",
Wiley, 1999. Wiley, 1999.
Non-Normative References Non-Normative References
[BKN] Bellare, M., Kohno, T., and Namprempre, C., [BKN1] Bellare, M., Kohno, T., and Namprempre, C.,
"Authenticated Encryption in SSH: Provably Fixing the "Authenticated Encryption in SSH: Provably Fixing the
SSH Binary Packet Protocol", Ninth ACM Conference on SSH Binary Packet Protocol", Ninth ACM Conference on
Computer and Communications Security, 2002. 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.
[BN] Bellare, M. and Namprempre, C., "Authenticated [BN] Bellare, M. and Namprempre, C., "Authenticated
Encryption: Relations among notions and analysis of Encryption: Relations among notions and analysis of
the generic composition paradigm", Asiacrypt 2000. the generic composition paradigm", Asiacrypt 2000.
[DAI] Dai, W., "An Attack Against SSH2 Protocol", Email to [DAI] Dai, W., "An Attack Against SSH2 Protocol", Email to
the ietf-ssh@netbsd.org email list, 2002. the ietf-ssh@netbsd.org email list, 2002.
[KRAWCZYK] Krawczyk, H., "The Order of Encryption and [KRAWCZYK] Krawczyk, H., "The Order of Encryption and
Authentication for Protecting Communications (Or: How Authentication for Protecting Communications (Or: How
secure is SSL?)", Crypto 2001. secure is SSL?)", Crypto 2001.
skipping to change at page 10, line 46 skipping to change at page 12, line 5
Chanathip Namprempre Chanathip Namprempre
Thammasat University Thammasat University
Faculty of Engineering Faculty of Engineering
Electrical Engineering Department Electrical Engineering Department
Rangsit Campus, Klong Luang Rangsit Campus, Klong Luang
Pathumthani, Thailand 12121 Pathumthani, Thailand 12121
EMail: meaw@alum.mit.edu EMail: meaw@alum.mit.edu
Full Copyright Statement Intellectual Property Statement
Copyright (C) The Internet Society (2004). All Rights Reserved. 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.
This document and translations of it may be copied and furnished to Copies of IPR disclosures made to the IETF Secretariat and any
others, and derivative works that comment on or otherwise explain it assurances of licenses to be made available, or the result of an
or assist in its implementation may be prepared, copied, published attempt made to obtain a general license or permission for the use of
and distributed, in whole or in part, without restriction of any such proprietary rights by implementers or users of this
kind, provided that the above copyright notice and this paragraph are specification can be obtained from the IETF on-line IPR repository at
included on all such copies and derivative works. However, this http://www.ietf.org/ipr.
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be The IETF invites any interested party to bring to its attention any
revoked by the Internet Society or its successors or assigns. 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.
This document and the information contained herein is provided on an Disclaimer of Validity
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING This document and the information contained herein are provided on an
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 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.
Acknowledgments Acknowledgments
Mihir Bellare and Chanathip Namprempre were supported by NSF Grant Mihir Bellare and Chanathip Namprempre were supported by NSF Grant
CCR-0098123, NSF Grant ANR-0129617 and an IBM Faculty Partnership CCR-0098123, NSF Grant ANR-0129617 and an IBM Faculty Partnership
Development Award. Tadayoshi Kohno was supported by a National Development Award. Tadayoshi Kohno was supported by a National
Defense Science and Engineering Fellowship. Defense Science and Engineering Graduate Fellowship and an IBM Ph.D.
Fellowship.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/