draft-ietf-secsh-newmodes-03.txt   draft-ietf-secsh-newmodes-04.txt 
Network Working Group M. Bellare Network Working Group M. Bellare
Internet-Draft T. Kohno Internet-Draft T. Kohno
Expires: September 22, 2005 UC San Diego Expires: October 8, 2005 UC San Diego
C. Namprempre C. Namprempre
Thammasat University Thammasat University
March 22, 2005 April 8, 2005
SSH Transport Layer Encryption Modes SSH Transport Layer Encryption Modes
draft-ietf-secsh-newmodes-03.txt draft-ietf-secsh-newmodes-04.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions This document is an Internet-Draft and is subject to all provisions
of Section 3 of RFC 3667. By submitting this Internet-Draft, each of Section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of 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 is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with which he or she become aware will be disclosed, in accordance with
RFC 3668. RFC 3668.
skipping to change at page 1, line 39 skipping to change at page 1, line 39
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 September 22, 2005. This Internet-Draft will expire on October 8, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2005). All Rights Reserved.
Abstract Abstract
Researchers have recently discovered that the authenticated Researchers have discovered that the authenticated encryption portion
encryption portion of the current SSH Transport Protocol is of the current SSH Transport Protocol is vulnerable to several
vulnerable to several attacks. 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.
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.
skipping to change at page 2, line 39 skipping to change at page 2, line 39
Non-Normative References . . . . . . . . . . . . . . . . . . . 10 Non-Normative References . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 10
Intellectual Property Statement . . . . . . . . . . . . . . . 12 Intellectual Property Statement . . . . . . . . . . . . . . . 12
Disclaimer of Validity . . . . . . . . . . . . . . . . . . . . 12 Disclaimer of Validity . . . . . . . . . . . . . . . . . . . . 12
Copyright Statement . . . . . . . . . . . . . . . . . . . . . 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,BKN1,BKN2]) have, however, recently identified several security ([DAI,BKN1,BKN2]) have, however, identified several security problems
problems with the symmetric portion of the SSH Transport Protocol as with the symmetric portion of the SSH Transport Protocol as described
described in [SSH-TRANS]. For example, the encryption mode specified in [SSH-TRANS]. For example, the encryption mode specified in [SSH-
in [SSH-TRANS] is vulnerable to a chosen-plaintext privacy attack. 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 [BKN1,BKN2] 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 [BKN1,BKN2]. recommendations described in [BKN1,BKN2].
skipping to change at page 3, line 19 skipping to change at page 3, line 19
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].
The SSH Transport Protocol is specified in the transport document The SSH Transport Protocol is specified in the transport document
[SSH-TRANS]. [SSH-TRANS].
3. Rekeying 3. Rekeying
Section 7 of [SSH-TRANS] suggests that SSH implementations rekey Section 9 of [SSH-TRANS] suggests that SSH implementations rekey
after every gigabyte of transmitted data. [SSH-TRANS] does not, after every gigabyte of transmitted data. [SSH-TRANS] does not,
however, discuss all the problems that could arise if an SSH however, discuss all the problems that could arise if an SSH
implementation does not rekey frequently enough. This section serves implementation does not rekey frequently enough. This section serves
to strengthen the suggestion in [SSH-TRANS] by giving firm upper to strengthen the suggestion in [SSH-TRANS] by giving firm upper
bounds on the tolerable number of encryptions between rekeying bounds on the tolerable number of encryptions between rekeying
operations. In Section 5 we discuss the motivation for these operations. In Section 6 we discuss the motivation for these
rekeying recommendations in more detail. rekeying recommendations in more detail.
This section makes two recommendations. Informally, the first This section makes two recommendations. Informally, the first
recommendation is intended to protects against possible information recommendation is intended to protects against possible information
leakage through the MAC tag and the second recommendation is intended leakage through the MAC tag and the second recommendation is intended
to protect against possible information leakage through the block to protect against possible information leakage through the block
cipher. Note that, depending on the block length of the underlying cipher. Note that, depending on the block length of the underlying
block cipher and the length of the encrypted packets, the first block cipher and the length of the encrypted packets, the first
recommendation may supersede the second recommendation, or visa- recommendation may supersede the second recommendation, or vice
versa. versa.
3.1 First Rekeying Recommendation 3.1 First Rekeying Recommendation
Because of possible information leakage through the MAC tag, SSH Because of possible information leakage through the MAC tag, SSH
implementations SHOULD rekey at least once every 2**32 outgoing implementations SHOULD rekey at least once every 2**32 outgoing
packets. More explicitly, after a key exchange an SSH implementation packets. More explicitly, after a key exchange an SSH implementation
SHOULD NOT send more than 2**32 packets before rekeying again. SHOULD NOT send more than 2**32 packets before rekeying again.
SSH implementations SHOULD also attempt to rekey before receiving SSH implementations SHOULD also attempt to rekey before receiving
skipping to change at page 4, line 29 skipping to change at page 4, line 29
in this subsection supersedes the recommendation in Section 3.1. If in this subsection supersedes the recommendation in Section 3.1. If
an SSH implementation uses a block cipher with a larger block size an SSH implementation uses a block cipher with a larger block size
(e.g., Rijndael with 256-bit blocks), then the recommendations in the (e.g., Rijndael with 256-bit blocks), then the recommendations in the
above paragraph may supersede the recommendations in this paragraph above paragraph may supersede the recommendations in this paragraph
(depending on the lengths of the packets). (depending on the lengths of the packets).
4. Encryption Modes 4. Encryption Modes
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 6.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).
skipping to change at page 5, line 17 skipping to change at page 5, line 17
serpent192-ctr OPTIONAL Serpent with 192-bit key serpent192-ctr OPTIONAL Serpent with 192-bit key
serpent256-ctr OPTIONAL Serpent with 256-bit key serpent256-ctr OPTIONAL Serpent with 256-bit key
idea-ctr OPTIONAL IDEA in SDCTR mode idea-ctr OPTIONAL IDEA in SDCTR mode
cast128-ctr OPTIONAL CAST-128 in SDCTR mode cast128-ctr OPTIONAL CAST-128 in SDCTR mode
The label <cipher>-ctr means that the block cipher <cipher> is to be The label <cipher>-ctr means that the block cipher <cipher> is to be
used in "stateful-decryption counter" (SDCTR) mode. Let L be the used in "stateful-decryption counter" (SDCTR) mode. Let L be the
block length of <cipher> in bits. In stateful-decryption counter block length of <cipher> in bits. In stateful-decryption counter
mode both the sender and the receiver maintain an internal L-bit 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 counter X. The initial value of X should be the initial IV (as
computed in Section 5.2 of [SSH-TRANS]) interpreted as an L-bit computed in Section 7.2 of [SSH-TRANS]) interpreted as an L-bit
unsigned integer in network-byte-order. If X=(2**L)-1, then 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 "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- the notation <X> to mean "convert X to an L-bit string in network-
byte-order." Naturally, implementations may differ in how the byte-order." Naturally, implementations may differ in how the
internal value X is stored. For example, implementations may store X internal value X is stored. For example, implementations may store X
as multiple unsigned 32-bit counters. as multiple unsigned 32-bit counters.
To encrypt a packet P=P1||P2||...||Pn (where P1, P2, ..., Pn are each 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> 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 to obtain a block B1. The block B1 is then XORed with P1 to generate
skipping to change at page 6, line 8 skipping to change at page 6, line 8
The "aes192-ctr" method uses AES with 192-bit keys. The "aes192-ctr" method uses AES with 192-bit keys.
The "aes256-ctr" method uses AES with 256-bit keys. The "aes256-ctr" method uses AES with 256-bit keys.
The "3des-ctr" method uses three-key triple-DES (encrypt-decrypt- 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 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 encryption, the next 8 bytes for the decryption, and the following 8
bytes for the final encryption. This requires 24 bytes of key data 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. (of which 168 bits are actually used). The block size is 8 bytes.
This algorithm is defined in [SCHNEIER]. This algorithm is defined in [DES].
The "blowfish-ctr" method uses Blowfish with 256 bit keys [SCHNEIER]. The "blowfish-ctr" method uses Blowfish with 256-bit keys [SCHNEIER].
The block size is 8 bytes. The block size is 8 bytes. (Note that "blowfish-cbc" from [SSH-
TRANS] uses 128-bit keys.)
The "twofish128-ctr" method uses Twofish with 128-bit keys [TWOFISH]. The "twofish128-ctr" method uses Twofish with 128-bit keys [TWOFISH].
The block size is 16 bytes. The block size is 16 bytes.
The "twofish192-ctr" method uses Twofish with 192-bit keys. The "twofish192-ctr" method uses Twofish with 192-bit keys.
The "twofish256-ctr" method uses Twofish with 256-bit keys. The "twofish256-ctr" method uses Twofish with 256-bit keys.
The "serpent128-ctr" method uses the Serpent block cipher [SERPENT] The "serpent128-ctr" method uses the Serpent block cipher [SERPENT]
with 128-bit keys. The block size is 16 bytes. with 128-bit keys. The block size is 16 bytes.
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].
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. IANA Considerations 5. IANA Considerations
The twelve encryption algorithm names defined in Section 4 are to be The twelve encryption algorithm names defined in Section 4 are to be
added to the Secure Shell Encryption Algorithm Name registry added to the Secure Shell Encryption Algorithm Name registry
established by Section 4.11.1 of [SSH-IANA]. established by Section 4.11.1 of [SSH-IANA].
skipping to change at page 7, line 44 skipping to change at page 7, line 44
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 vice 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. If more than 2**32 packets are least once every 2**32 packets. If more than 2**32 packets are
encrypted and MACed by the SSH Transport Protocol between rekeyings, encrypted and MACed by the SSH Transport Protocol between rekeyings,
then the SSH Transport Protocol may become vulnerable to replay and then the SSH Transport Protocol may become vulnerable to replay and
re-ordering attacks, meaning that an adversary may be able to re-ordering attacks, meaning that an adversary may be able to
convince the receiver to accept the same message more than once or to convince the receiver to accept the same message more than once or to
accept messages out of order. Additionally, the underlying MAC may accept messages out of order. Additionally, the underlying MAC may
begin to leak information about the protocol's payload data. In more 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
skipping to change at page 8, line 41 skipping to change at page 8, line 41
(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.
6.2 Encryption Method Considerations 6.2 Encryption Method Considerations
Researchers have recently shown that the original CBC-based Researchers have shown that the original CBC-based encryption methods
encryption methods in [SSH-TRANS] are vulnerable to chosen-plaintext in [SSH-TRANS] are vulnerable to chosen-plaintext privacy attacks
privacy attacks [DAI,BKN1,BKN2]. The new stateful-decryption counter [DAI,BKN1,BKN2]. The new stateful-decryption counter mode encryption
mode encryption methods described in Section 4 of this document were methods described in Section 4 of this document were designed to be
designed to be secure replacements to the original encryption methods secure replacements to the original encryption methods described in
described in [SSH-TRANS]. [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 [BKN1,BKN2]. 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
skipping to change at page 9, line 21 skipping to change at page 9, line 21
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 from 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, [BKN1,BKN2] describe In addition to stateful-decryption counter mode, [BKN1,BKN2] describe
other provably-secure encryption methods for use with the SSH other provably-secure encryption methods for use with the SSH
Transport Protocol. The stateful-decryption counter mode methods in Transport Protocol. The stateful-decryption counter mode methods in
Section 4 are, however, the preferred alternatives to the insecure Section 4 are, however, the preferred alternatives to the insecure
methods in [SSH-TRANS] because stateful-decryption counter mode is methods in [SSH-TRANS] because stateful-decryption counter mode is
the most efficient (both in terms of network consumption and in terms the most efficient (both in terms of network consumption and in terms
of the 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] National Institute of Standards and Technology,
NIST AES Proposal, 1998. "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.
[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
skipping to change at page 10, line 31 skipping to change at page 10, line 37
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., [BKN2] Bellare, M., Kohno, T., and Namprempre, C.,
"Breaking and Provably Repairing the SSH "Breaking and Provably Repairing the SSH
Authenticated Encryption Scheme: A Case Study of the Authenticated Encryption Scheme: A Case Study of the
Encode-then-Encrypt-and-MAC Paradigm", Encode-then-Encrypt-and-MAC Paradigm",
ACM Transactions on Information and System Security, ACM Transactions on Information and System Security,
7(2), May 2004. 7(2), May 2004.
[BN] Bellare, M. and Namprempre, C., "Authenticated
Encryption: Relations among notions and analysis of
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
Authentication for Protecting Communications (Or: How
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
 End of changes. 

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