doc/specifications/rfc2948.txt

   1
   2
   3
   4
   5
   6
   7 Network Working Group                                          J. Altman
   8 Request for Comments: 2948                           Columbia University
   9 Category: Standards Track                                 September 2000
  10
  11
  12              Telnet Encryption: DES3 64 bit Output Feedback
  13
  14 Status of this Memo
  15
  16    This document specifies an Internet standards track protocol for the
  17    Internet community, and requests discussion and suggestions for
  18    improvements.  Please refer to the current edition of the "Internet
  19    Official Protocol Standards" (STD 1) for the standardization state
  20    and status of this protocol.  Distribution of this memo is unlimited.
  21
  22 Copyright Notice
  23
  24    Copyright (C) The Internet Society (2000).  All Rights Reserved.
  25
  26 Abstract
  27
  28    This document specifies how to use the Triple-DES (data encryption
  29    standard) encryption algorithm in output feedback mode with the
  30    telnet encryption option.
  31
  32 1.  Command Names and Codes
  33
  34    Encryption Type
  35
  36       DES3_OFB64       4
  37
  38    Suboption Commands
  39
  40       OFB64_IV         1
  41       OFB64_IV_OK      2
  42       OFB64_IV_BAD     3
  43
  44 2.  Command Meanings
  45
  46    IAC SB ENCRYPT IS DES3_OFB64 OFB64_IV <initial vector> IAC SE
  47
  48      The sender of this command generates a random 8 byte initial
  49      vector, and sends it to the other side of the connection using the
  50      OFB64_IV command.  The initial vector is sent in clear text.  Only
  51      the side of the connection that is WILL ENCRYPT may send the
  52      OFB64_IV command.
  53
  54
  55
  56
  57
  58 Altman                      Standards Track                     [Page 1]
  59 \f
  60 RFC 2948              DES3 64 bit Output Feedback         September 2000
  61
  62
  63    IAC SB ENCRYPT REPLY DES3_OFB64 OFB64_IV_OK IAC SE
  64    IAC SB ENCRYPT REPLY DES3_OFB64 OFB64_IV_BAD IAC SE
  65
  66      The sender of these commands either accepts or rejects the initial
  67      vector received in a OFB64_IV command.  Only the side of the
  68      connection that is DO ENCRYPT may send the OFB64_IV_OK and
  69      OFB64_IV_BAD commands.  The OFB64_IV_OK command MUST be sent for
  70      backwards compatibility with existing implementations; there
  71      really isn't any reason why a sender would need to send the
  72      OFB64_IV_BAD command except in the case of a protocol violation
  73      where the IV sent was not of the correct length (i.e., 8 bytes).
  74
  75 3.  Implementation Rules
  76
  77    Once a OFB64_IV_OK command has been received, the WILL ENCRYPT side
  78    of the connection should do keyid negotiation using the ENC_KEYID
  79    command.  Once the keyid negotiation has successfully identified a
  80    common keyid, then START and END commands may be sent by the side of
  81    the connection that is WILL ENCRYPT.  Data will be encrypted using
  82    the DES3 64 bit Output Feedback algorithm.
  83
  84    If encryption (decryption) is turned off and back on again, and the
  85    same keyid is used when re-starting the encryption (decryption), the
  86    intervening clear text must not change the state of the encryption
  87    (decryption) machine.
  88
  89    If a START command is sent (received) with a different keyid, the
  90    encryption (decryption) machine must be re-initialized immediately
  91    following the end of the START command with the new key and the
  92    initial vector sent (received) in the last OFB64_IV command.
  93
  94    If a new OFB64_IV command is sent (received), and encryption
  95    (decryption) is enabled, the encryption (decryption) machine must be
  96    re-initialized immediately following the end of the OFB64_IV command
  97    with the new initial vector, and the keyid sent (received) in the
  98    last START command.
  99
 100    If encryption (decryption) is not enabled when a OFB64_IV command is
 101    sent (received), the encryption (decryption) machine must be re-
 102    initialized after the next START command, with the keyid sent
 103    (received) in that START command, and the initial vector sent
 104    (received) in this OFB64_IV command.
 105
 106
 107
 108
 109
 110
 111
 112
 113
 114 Altman                      Standards Track                     [Page 2]
 115 \f
 116 RFC 2948              DES3 64 bit Output Feedback         September 2000
 117
 118
 119 4.  Algorithm
 120
 121    DES3 64 bit Output Feedback
 122
 123
 124                   key1       key2       key3
 125                    |          |          |
 126                    v          v          v
 127                +-------+  +-------+  +-------+
 128             +->| DES-e |->| DES-d |->| DES-e |-- +
 129             |  +-------+  +-------+  +-------+   |
 130             +------------------------------------+
 131                                                 v
 132     INPUT ------------------------------------->(+) ----> DATA
 133
 134    Given:
 135      iV: Initial vector, 64 bits (8 bytes) long.
 136      Dn: the nth chunk of 64 bits (8 bytes) of data to
 137          encrypt (decrypt).
 138      On: the nth chunk of 64 bits (8 bytes) of encrypted
 139          (decrypted) output.
 140
 141        V0 = DES-e(DES-d(DES-e(iV, key1),key2),key3)
 142        V(n+1) = DES-e(DES-d(DES-e(Vn, key1),key2),key3)
 143        On = Dn ^ Vn
 144
 145 5.  Integration with the AUTHENTICATION telnet option
 146
 147    As noted in the telnet ENCRYPTION option specifications, a keyid
 148    value of zero indicates the default encryption key, as might be
 149    derived from the telnet AUTHENTICATION option.  If the default
 150    encryption key negotiated as a result of the telnet AUTHENTICATION
 151    option contains less than 16 bytes, then the DES3_OFB64 option must
 152    not be offered or used as a valid telnet encryption option.
 153
 154    The following rules are to be followed for creating three DES
 155    encryption keys based upon the available encrypt key data:
 156
 157      keys_to_use = bytes of key data / DES block size (8 bytes)
 158
 159    where the keys are labeled "key1" through "key6" with "key1" being
 160    the first 8 bytes; "key2" the second 8 bytes; ... and "key6" being
 161    sixth 8 bytes (if available).
 162
 163    When two keys are available:
 164
 165     . data sent from the server is encrypted with key1, decrypted with
 166       key2, and encrypted with key1;
 167
 168
 169
 170 Altman                      Standards Track                     [Page 3]
 171 \f
 172 RFC 2948              DES3 64 bit Output Feedback         September 2000
 173
 174
 175     . data sent from the client is encrypted with key2, decrypted with
 176       key1, and encrypted with key2
 177
 178    When three keys are available:
 179
 180     . data sent from the server is encrypted with key1, decrypted with
 181       key2, and encrypted with key3;
 182
 183     . data sent from the client is encrypted with key2, decrypted with
 184       key3, and encrypted with key1
 185
 186    When four keys are available:
 187
 188     . data sent from the server is encrypted with key1, decrypted with
 189       key2, and encrypted with key3;
 190
 191     . data sent from the client is encrypted with key2, decrypted with
 192       key4, and encrypted with key1
 193
 194    When five keys are available:
 195
 196     . data sent from the server is encrypted with key1, decrypted with
 197       key2, and encrypted with key3;
 198
 199     . data sent from the client is encrypted with key2, decrypted with
 200       key4, and encrypted with key5
 201
 202    When six keys are available:
 203
 204     . data sent from the server is encrypted with key1, decrypted with
 205       key2, and encrypted with key3;
 206
 207     . data sent from the client is encrypted with key4, decrypted with
 208       key5, and encrypted with key6
 209
 210    In all cases, the keys used by DES3_OFB64 must have their parity
 211    corrected after they are determined using the above algorithm.
 212
 213    Note that the above algorithm assumes that it is safe to use a non-
 214    DES key (or part of a non-DES key) as a DES key.  This is not
 215    necessarily true of all cipher systems, but we specify this behaviour
 216    as the default since it is true for most authentication systems in
 217    popular use today, and for compatibility with existing
 218    implementations.  New telnet AUTHENTICATION mechanisms may specify
 219    alternative methods for determining the keys to be used for this
 220    cipher suite in their specification, if the session key negotiated by
 221    that authentication mechanism is not a DES key and and where this
 222    algorithm may not be safely used.
 223
 224
 225
 226 Altman                      Standards Track                     [Page 4]
 227 \f
 228 RFC 2948              DES3 64 bit Output Feedback         September 2000
 229
 230
 231 6.  Security Considerations
 232
 233    Encryption using Output Feedback does not ensure data integrity; an
 234    active attacker may be able to substitute text, if he can predict the
 235    clear-text that was being transmitted.
 236
 237    The tradeoff here is that adding a message authentication code (MAC)
 238    will significantly increase the number of bytes needed to send a
 239    single character in the telnet protocol, which will impact
 240    performance on slow (i.e. dialup) links.
 241
 242    This option was originally drafted back when CPU speeds where not
 243    necessarily fast enough to do allow use of CFB.  Since then, CPU's
 244    have gotten much faster.  Given the inherent weaknesses in Output
 245    Feedback mode, perhaps it should be deprecated in favor of CFB modes?
 246
 247 7.  Acknowledgments
 248
 249    This document was based on the "Telnet Encryption: DES 64 bit Output
 250    Feedback" document originally written by Dave Borman of Cray Research
 251    with the assistance of the IETF Telnet Working Group.
 252
 253 Author's Address
 254
 255    Jeffrey Altman, Editor
 256    Columbia University
 257    612 West 115th Street Room 716
 258    New York NY 10025 USA
 259
 260    Phone: +1 (212) 854-1344
 261    EMail: jaltman@columbia.edu
 262
 263
 264
 265
 266
 267
 268
 269
 270
 271
 272
 273
 274
 275
 276
 277
 278
 279
 280
 281
 282 Altman                      Standards Track                     [Page 5]
 283 \f
 284 RFC 2948              DES3 64 bit Output Feedback         September 2000
 285
 286
 287 Full Copyright Statement
 288
 289    Copyright (C) The Internet Society (2000).  All Rights Reserved.
 290
 291    This document and translations of it may be copied and furnished to
 292    others, and derivative works that comment on or otherwise explain it
 293    or assist in its implementation may be prepared, copied, published
 294    and distributed, in whole or in part, without restriction of any
 295    kind, provided that the above copyright notice and this paragraph are
 296    included on all such copies and derivative works.  However, this
 297    document itself may not be modified in any way, such as by removing
 298    the copyright notice or references to the Internet Society or other
 299    Internet organizations, except as needed for the purpose of
 300    developing Internet standards in which case the procedures for
 301    copyrights defined in the Internet Standards process must be
 302    followed, or as required to translate it into languages other than
 303    English.
 304
 305    The limited permissions granted above are perpetual and will not be
 306    revoked by the Internet Society or its successors or assigns.
 307
 308    This document and the information contained herein is provided on an
 309    "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
 310    TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
 311    BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
 312    HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
 313    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 314
 315 Acknowledgement
 316
 317    Funding for the RFC Editor function is currently provided by the
 318    Internet Society.
 319
 320
 321
 322
 323
 324
 325
 326
 327
 328
 329
 330
 331
 332
 333
 334
 335
 336
 337
 338 Altman                      Standards Track                     [Page 6]
 339 \f