draft-ietf-secsh-newmodes-01.txt   draft-ietf-secsh-newmodes-02.txt 
Network Working Group M. Bellare Network Working Group M. Bellare
Internet-Draft T. Kohno Internet-Draft T. Kohno
Expires: April 10, 2004 UC San Diego Expires: November 27, 2004 UC San Diego
C. Namprempre C. Namprempre
Thammasat University Thammasat University
October 10, 2003 May 27, 2004
SSH Transport Layer Encryption Modes SSH Transport Layer Encryption Modes
draft-ietf-secsh-newmodes-01.txt draft-ietf-secsh-newmodes-02.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 in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
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.
skipping to change at page 1, line 35 skipping to change at page 1, line 35
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 April 10, 2004. This Internet-Draft will expire on November 27, 2004.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2003). 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.
This document describes new symmetric encryption methods for the SSH This document describes new symmetric encryption methods for the SSH
Transport Protocol and gives specific recommendations on how Transport Protocol and gives specific recommendations on how
frequently SSH implementations should rekey. frequently SSH implementations should rekey.
skipping to change at page 2, line 25 skipping to change at page 2, line 25
2. Conventions Used in This Document . . . . . . . . . . . . . . 2 2. Conventions Used in This Document . . . . . . . . . . . . . . 2
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. Security Considerations . . . . . . . . . . . . . . . . . . . 6
5.1 Rekeying Considerations . . . . . . . . . . . . . . . . . . . 7 5.1 Rekeying Considerations . . . . . . . . . . . . . . . . . . . 7
5.2 Encryption Method Considerations . . . . . . . . . . . . . . . 8 5.2 Encryption Method Considerations . . . . . . . . . . . . . . . 8
Normative References . . . . . . . . . . . . . . . . . . . . . 9 Normative References . . . . . . . . . . . . . . . . . . . . . 9
Non-Normative References . . . . . . . . . . . . . . . . . . . 9 Non-Normative References . . . . . . . . . . . . . . . . . . . 9
Authorsどヨ Addresses . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 10
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 10 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 10
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,BKN]) 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.
skipping to change at page 3, line 49 skipping to change at page 3, line 49
more than 2**32 packets since the last rekey operation. The 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 preferred way to do this is to rekey after receiving more than 2**31
packets since the last rekey operation. packets since the last rekey operation.
3.2 Second Rekeying Recommendation 3.2 Second Rekeying Recommendation
Because of a birthday property of block ciphers and some modes of Because of a birthday property of block ciphers and some modes of
operation, implementations must be careful not to encrypt too many operation, implementations must be careful not to encrypt too many
blocks with the same encryption key. blocks with the same encryption key.
Let L be the block length (in bits) of an SSH encryption methodどヨs 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 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) rekeying, an SSH implementation SHOULD NOT encrypt more than 2**(L/4)
blocks before rekeying again. If L is at least 128, then SSH blocks before rekeying again. If L is at least 128, then SSH
implementations should also attempt to force a rekey before receiving 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 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, 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 although it may be too expensive to rekey every 2**(L/4) blocks, it
is still advisable for SSH implementations to follow the original is still advisable for SSH implementations to follow the original
recommendation in [SSH-TRANS]: rekey at least once every gigabyte of recommendation in [SSH-TRANS]: rekey at least once every gigabyte of
transmitted data. transmitted data.
skipping to change at page 4, line 31 skipping to change at page 4, line 31
This document describes new encryption methods for use with the SSH This document describes new encryption methods for use with the SSH
Transport Protocol. These encryption methods are in addition to the Transport Protocol. These encryption methods are in addition to the
encryption methods described in Section 4.3 of [SSH-TRANS]. encryption methods described in Section 4.3 of [SSH-TRANS].
Recall from [SSH-TRANS] that the encryption methods in each direction Recall from [SSH-TRANS] that the encryption methods in each direction
of an SSH connection MUST run independently of each other and that, of an SSH connection MUST run independently of each other and that,
when encryption is in effect, the packet length, padding length, when encryption is in effect, the packet length, padding length,
payload, and padding fields of each packet MUST be encrypted with the payload, and padding fields of each packet MUST be encrypted with the
chosen method. Further recall that the total length of the chosen method. Further recall that the total length of the
concatenation of the packet length, padding length, payload, and concatenation of the packet length, padding length, payload, and
padding MUST be a multiple of the cipherどヨs block size when the 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 cipher's block size is greater than or equal to 8 bytes (which is the
case for all of the following methods). case for all of the following methods).
This document describes the following new methods: This document describes the following new methods:
aes128-ctr RECOMMENDED AES (Rijndael) in SDCTR mode, aes128-ctr RECOMMENDED AES (Rijndael) in SDCTR mode,
with 128-bit key with 128-bit key
aes192-ctr RECOMMENDED AES with 192-bit key aes192-ctr RECOMMENDED AES with 192-bit key
aes256-ctr RECOMMENDED AES with 256-bit key aes256-ctr RECOMMENDED AES with 256-bit key
3des-ctr RECOMMENDED Three-key 3DES in SDCTR mode 3des-ctr RECOMMENDED Three-key 3DES in SDCTR mode
blowfish-ctr OPTIONAL Blowfish in SDCTR mode blowfish-ctr OPTIONAL Blowfish in SDCTR mode
skipping to change at page 6, line 48 skipping to change at page 6, line 48
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 [BKN].
Please note that the notion of "prove" in the context of [BKN] is Please note that the notion of "prove" in the context of [BKN] is
that of practice-oriented reductionist security: if an attacker 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 [BKN] for details. In particular, attacks are not impossible;
just extremely improbable (unless the building blocks, like AES, are just extremely improbable (unless the building blocks, like AES, are
insecure). 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 5.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
on the encryption methodどヨs block length L and the number of blocks on the encryption method's block length L and the number of blocks
encrypted per packet, recommendation (1) may supersede recommendation encrypted per packet, recommendation (1) may supersede recommendation
(2) or visa-versa. (2) or visa-versa.
Recommendation (1) states that SSH implementations should rekey at Recommendation (1) states that SSH implementations should rekey at
least once every 2**32 packets. As [BKN] show, if more than 2**32 least once every 2**32 packets. If more than 2**32 packets are
packets are encrypted and MACed by the SSH Transport Protocol between encrypted and MACed by the SSH Transport Protocol between rekeyings,
rekeyings, then the SSH Transport Protocolどヨs underlying MAC may begin then the SSH Transport Protocol may become vulnerable to replay and
to leak information about the protocolどヨs payload data. In more re-ordering attacks, meaning 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 detail, an adversary looks for a collision between the MACs
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. Implementors who decide secure the underlying encryption method is. Also note that although
not to rekey at least once every 2**32 packets should understand this compressing payload data before encrypting and MACing and the use of
issue. random padding may reduce the risk of information leakage through the
underlying MAC, compression and the use of random padding will not
Note that compressing payload data before encrypting and MACing will prevent information leakage. Implementors who decide not to rekey at
not significantly reduce the risk of information leakage through the least once every 2**32 packets should understand these issues. These
underlying MAC. Similarly, the use of random (and unpredictable to issues are discussed further in [BKN].
an adversary) padding will not prevent information leakage through
the underlying MAC [BKN].
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 privacy-preserving (1) would be to switch from basic HMAC to a another MAC, such as a
randomized MAC, such as a MAC that has its own internal counter MAC that has its own internal counter (because of the 32-bit counter
(because of the 32-bit counter already present in the protocol, such already present in the protocol, such a counter would only need to be
a counter would only need to be incremented once every 2**32 incremented once every 2**32 packets).
packets).
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 5.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,BKN]. The new stateful-decryption counter mode
encryption methods described in Section 4 of this document were 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 [BKN].
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, [BKN] describe other
provably-secure encryption methods for use with the SSH Transport provably-secure encryption methods for use with the SSH Transport
Protocol. The stateful-decryption counter mode methods in Section 4 Protocol. The stateful-decryption counter mode methods in Section 4
are, however, the preferred alternatives to the insecure methods in are, however, the preferred alternatives to the insecure methods in
[SSH-TRANS] because stateful-decryption counter mode is the most [SSH-TRANS] because stateful-decryption counter mode is the most
efficient (both in terms of network consumption and in terms of the efficient (both in terms of network consumption and in terms of the
skipping to change at page 9, line 38 skipping to change at page 9, line 38
[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., et. al., "SSH Protocol Architecture",
I-D draft-ietf-architecture-12.txt, January 2002. I-D draft-ietf-architecture-15.txt, October 2003.
[SSH-TRANS] Ylonen, T., et. al., "SSH Transport Layer Protocol", [SSH-TRANS] Ylonen, T., et. al., "SSH Transport Layer Protocol",
I-D draft-ietf-transport-14.txt, March 2002. I-D draft-ietf-transport-17.txt, October 2003.
[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., [BKN] 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
skipping to change at page 10, line 17 skipping to change at page 10, line 17
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.
Authorsどヨ Addresses: Authors' Addresses:
Mihir Bellare Mihir Bellare
Department of Computer Science and Engineering Department of Computer Science and Engineering
University of California at San Diego University of California at San Diego
9500 Gilman Drive, MC 0114 9500 Gilman Drive, MC 0114
La Jolla, CA 92093-0114 La Jolla, CA 92093-0114
Phone: +1 858-822-2977 Phone: +1 858-822-2977
EMail: mihir@cs.ucsd.edu EMail: mihir@cs.ucsd.edu
skipping to change at page 10, line 48 skipping to change at page 10, line 48
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 Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2004). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
 End of changes. 

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