aboutsummaryrefslogtreecommitdiff
path: root/doc/draft-ietf-secsh-newmodes-00.txt
blob: 1554ac3592ccec73f63e4c0c0119fa17d7d14916 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
Network Working Group                                         M. Bellare
Internet-Draft                                                  T. Kohno
Expires: September 20, 2003                                 UC San Diego
                                                           C. Namprempre
                                                    Thammasat University
                                                          March 20, 2003


                  SSH Transport Layer Encryption Modes

                    draft-ietf-secsh-newmodes-00.txt


Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on September 20, 2003.

Copyright Notice

   Copyright (C) The Internet Society (2003).  All Rights Reserved.

Abstract

   Researchers have recently 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 SSH
   Transport Protocol and gives specific recommendations on how



Bellare, Kohno, and Namprempre                                  [Page 1]

Internet Draft                                               Month, Year


   frequently SSH implementations should rekey.

   Bellare, Kohno, and Namprempre [ACM CCS 2002] prove that if an SSH
   application implements the modifications described in this document,
   then the symmetric cryptographic portion of that application will
   provably resist chosen-plaintext, chosen-ciphertext, reaction-based
   privacy and integrity/authenticity attacks.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
   2.  Conventions Used in This Document  . . . . . . . . . . . . . .  2
   3.  Rekeying . . . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.1 First Rekeying Recommendation  . . . . . . . . . . . . . . . .  3
   3.2 Second Rekeying Recommendation . . . . . . . . . . . . . . . .  3
   4.  Encryption Modes . . . . . . . . . . . . . . . . . . . . . . .  4
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . .  6
   5.1 Rekeying Considerations  . . . . . . . . . . . . . . . . . . .  7
   5.2 Encryption Method Considerations . . . . . . . . . . . . . . .  8
       References . . . . . . . . . . . . . . . . . . . . . . . . . .  9
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 10
       Full Copyright Statement . . . . . . . . . . . . . . . . . . . 10

1. Introduction

   The symmetric portion of the SSH Transport Protocol was designed to
   provide both privacy and integrity of encapsulated data.  Researchers
   ([DAI,BKN]) have, however, recently identified several security
   problems with the symmetric portion of the SSH Transport Protocol as
   described in [SSH-TRANS].  For example, the encryption mode specified
   in [SSH-TRANS] 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 [BKN] 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 [BKN].

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



Bellare, Kohno, and Namprempre                                  [Page 2]

Internet Draft                                               Month, Year


   document [SSH-ARCH].

   The SSH Transport Protocol is specified in the transport document
   [SSH-TRANS].

3. Rekeying

   Section 7 of [SSH-TRANS] suggests that SSH implementations rekey
   after every gigabyte of transmitted data.  [SSH-TRANS] 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 [SSH-TRANS] by giving firm upper
   bounds on the tolerable number of encryptions between rekeying
   operations.  In Section 5 we discuss the motivation for these
   rekeying recommendations in more detail.

   This section makes two recommendations.  Informally, the first
   recommendation is intended to protects 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 underlying
   block cipher and the length of the encrypted packets, the first
   recommendation may supersede the second recommendation, or visa-
   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 (eg, 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



Bellare, Kohno, and Namprempre                                  [Page 3]

Internet Draft                                               Month, Year


   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 [SSH-TRANS]: rekey at least once 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
   (eg, Rijndael with 256-bit blocks), then the recommendations in the
   above paragraph may supersede the recommendations in this paragraph
   (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 4.3 of [SSH-TRANS].

   Recall from [SSH-TRANS] 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     RECOMMENDED       Blowfish in SDCTR mode
     twofish128-ctr   RECOMMENDED       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   RECOMMENDED       Serpent in SDCTR mode, with
                                        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



Bellare, Kohno, and Namprempre                                  [Page 4]

Internet Draft                                               Month, Year


   The label <cipher>-ctr means 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 5.2 of [SSH-TRANS]) 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
   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.

   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 [SCHNEIER].

   The "blowfish-ctr" method uses Blowfish with 256 bit keys [SCHNEIER].
   The block size is 8 bytes.



Bellare, Kohno, and Namprempre                                  [Page 5]

Internet Draft                                               Month, Year


   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.

   The "serpent256-ctr" method uses Serpent with 256-bit keys.

   The "idea-ctr" method uses the IDEA cipher [SCHNEIER].  IDEA is
   patented by Ascom AG.  The block size is 8 bytes.

   The "cast128-ctr" method uses the CAST-128 cipher [RFC2144].  The
   block size is 8 bytes.

5. Security Considerations

   This document describes additional encryption methods and
   recommendations for the SSH Transport Protocol [SSH-TRANS].  [BKN]
   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 paper [BKN].

   Please note that the notion of "prove" in the context of [BKN] 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 (eg, a chosen-ciphertext attack), then
   the attacker will also be able to break one of the transport
   protocol's underlying components (eg, 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 [BKN] for details.  In particular, attacks are not impossible;
   just extremely improbable (unless the building blocks, like AES, are
   insecure).



Bellare, Kohno, and Namprempre                                  [Page 6]

Internet Draft                                               Month, Year


   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-
   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.

5.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 (eg, 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 visa-versa.

   Recommendation (1) states that SSH implementations should rekey at
   least once every 2**32 packets.  As [BKN] show, if more than 2**32
   packets are encrypted and MACed by the SSH Transport Protocol between
   rekeyings, then the SSH Transport Protocol's 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 [SSH-TRANS]); 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.  Implementors who decide
   not to rekey at least once every 2**32 packets should understand this
   issue.

   Note that compressing payload data before encrypting and MACing will
   not significantly reduce the risk of information leakage through the
   underlying MAC.  Similarly, the use of random (and unpredictable to
   an adversary) padding will not prevent information leakage through
   the underlying MAC [BKN].

   One alternative to recommendation (1) would be to make the SSH
   Transport Protocol's sequence number more than 32 bits long.  This



Bellare, Kohno, and Namprempre                                  [Page 7]

Internet Draft                                               Month, Year


   document does not suggest increasing the length of the sequence
   number because doing so could hinder interoperability with older
   version of the SSH protocol.  Another alternative to recommendation
   (1) would be to switch from HMAC to a privacy-preserving randomized
   MAC.

   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.

5.2 Encryption Method Considerations

   Researchers have recently shown that the original CBC-based
   encryption methods in [SSH-TRANS] are vulnerable to chosen-plaintext
   privacy attacks [DAI,BKN].  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 [SSH-TRANS].

   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 [BKN].

   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 [SSH-TRANS]) 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
   messages to 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 padding to be a multiple
   of the block cipher's block length in order to (1) not alter the
   packet description in [SSH-TRANS] and (2) not leak precise
   information about the length of the packet's payload data.  (Although
   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



Bellare, Kohno, and Namprempre                                  [Page 8]

Internet Draft                                               Month, Year


   make that recommendation here.)

   In addition to stateful-decryption counter mode, [BKN] 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
   [SSH-TRANS] because stateful-decryption counter mode is the most
   efficient (both in terms of network consumption and in terms of the
   number of required cryptographic operations per packet).

References

   [AES]           Daemon, J. and Rijmen, V., "AES Proposal: Rijndael",
                   NIST AES Proposal, 1998.

   [BKN]           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.

   [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
                   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.

   [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.

   [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.

   [SSH-ARCH]      Ylonen, T., et. al., "SSH Protocol Architecture",
                   I-D draft-ietf-architecture-12.txt, January 2002.




Bellare, Kohno, and Namprempre                                  [Page 9]

Internet Draft                                               Month, Year


   [SSH-TRANS]     Ylonen, T., et. al., "SSH Transport Layer Protocol",
                   I-D draft-ietf-transport-14.txt, March 2002.

   [TWOFISH]       Schneier, B., et. al., "The Twofish Encryptions
                   Algorithm: A 128-bit block cipher, 1st Edition",
                   Wiley, 1999.

Authors' Addresses:

   Mihir Bellare
   Department of Computer Science and Engineering
   University of California at San Diego
   9500 Gilman Drive, MC 0114
   La Jolla, CA 92093-0114

   Phone: +1 858-822-2977
   EMail: mihir@cs.ucsd.edu

   Tadayoshi Kohno
   Department of Computer Science and Engineering
   University of California at San Diego
   9500 Gilman Drive, MC 0114
   La Jolla, CA 92093-0114

   Phone: +1 858-822-2977
   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

Full Copyright Statement

   Copyright (C) The Internet Society (2003).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other



Bellare, Kohno, and Namprempre                                 [Page 10]

Internet Draft                                               Month, Year


   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
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS 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.

Acknowledgments

   Mihir Bellare and Chanathip Namprempre were supported by NSF Grant
   CCR-0098123, NSF Grant ANR-0129617 and an IBM Faculty Partnership
   Development Award.  Tadayoshi Kohno was supported by a National
   Defense Science and Engineering Fellowship.





























Bellare, Kohno, and Namprempre                                 [Page 11]