doc/specification/draft-newman-telnet-sasl-01.txt

   1
   2
   3
   4
   5
   6
   7 Network Working Group                                          C. Newman
   8 Internet Draft: Telnet SASL Option                              Innosoft
   9 Document: draft-newman-telnet-sasl-01.txt                  November 1998
  10
  11
  12                            Telnet SASL Option
  13
  14
  15 Status of this memo
  16
  17      This document is an Internet-Draft.  Internet-Drafts are working
  18      documents of the Internet Engineering Task Force (IETF), its areas,
  19      and its working groups.  Note that other groups may also distribute
  20      working documents as Internet-Drafts.
  21
  22      Internet-Drafts are draft documents valid for a maximum of six
  23      months and may be updated, replaced, or obsoleted by other
  24      documents at any time.  It is inappropriate to use Internet-Drafts
  25      as reference material or to cite them other than as "work in
  26      progress."
  27
  28      To view the entire list of current Internet-Drafts, please check
  29      the "1id-abstracts.txt" listing contained in the Internet-Drafts
  30      Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net
  31      (Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East
  32      Coast), or ftp.isi.edu (US West Coast).
  33
  34 Abstract
  35
  36      It is common today for Internet client software to implement
  37      multiple Internet protocols.  SASL [SASL] provides an
  38      authentication framework which permits multi-protocol clients and
  39      servers to reuse security-sensitive authentication code.  This memo
  40      defines a SASL profile for the Telnet [TELNET] protocol.
  41
  42      This proposal will be discussed on the telnet-ietf mailing list.
  43      To subscribe, send the word "subscribe" to
  44      <telnet-ietf-request@bsdi.com>.
  45
  46 1. Conventions Used in this Document
  47
  48      The key words "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD
  49      NOT", and "MAY" in this document are to be interpreted as described
  50      in "Key words for use in RFCs to Indicate Requirement Levels"
  51      [KEYWORDS].
  52
  53      In examples, "C:" and "S:" indicate data sent by the client (end
  54      which does a TCP active option) and server (end which does a TCP
  55
  56
  57
  58 Newman                                                          [Page 1]
  59 \f
  60 Internet Draft             Telnet SASL Option              November 1998
  61
  62
  63      passive open) respectively.
  64
  65 2. Background for this Proposal
  66
  67      Telnet has its own single-protocol authentication framework defined
  68      in "Telnet Authentication Option" [TELNET-AUTH] which predates SASL
  69      [SASL].  This old Telnet authentication option and the associated
  70      encryption option [TELNET-ENC] do not provide integrity protection
  71      facilities, machine parsible error codes (e.g. to alert the client
  72      of an expired passphrase), or a way to integrate GSSAPI [GSSAPI]
  73      into Telnet.
  74
  75      Adding SASL and using it for new authentication mechanisms will
  76      improve reuse of security-sensitive code in multi-protocol clients
  77      in addition to addressing the other issues.  While it would be
  78      possible to layer SASL support on top of the existing
  79      authentication option, it could result in an extra round-trip and
  80      would have potentially confusing interactions with the modifiers
  81      field in the Telnet authentication option.
  82
  83 3. Kerberos Compatibility
  84
  85      Both SASL and the old Telnet authentication option offer Kerberos
  86      V4 mechanisms.  It is usually not desirable to deploy two
  87      incompatible mechanisms for the same function, however, the
  88      KERBEROS_V4 SASL mechanism is more resistant to reply attacks and
  89      provides integrity services.  Currently deployed Kerberos V4 Telnet
  90      implementations have no integrity protection and the encryption
  91      service is subject to an active down negotiation attack.
  92
  93      Implementations which offer support for the KERBEROS_V4 SASL
  94      mechanism SHOULD also implement the old Telnet authentication
  95      option Kerberos v4 mechanism.  This will provide better
  96      interoperability with deployed implementations.  When both options
  97      are available, the KERBEROS_V4 SASL mechanism SHOULD be used in
  98      preference to the old Telnet authentication mechanism, unless
  99      encryption without integrity protection is desired.
 100
 101      Both the SASL GSSAPI mechanism and the old Telnet authentication
 102      option offer Kerberos V5 mechanisms.  The only difference is that
 103      the SASL GSSAPI Kerberos 5 mechanism includes integrity protection
 104      not available via the old authentication and encryption options.  A
 105      server supporting Kerberos V5 SHOULD implement the old Kerberos V5
 106      authentication option for backwards compatibility.
 107
 108 4. SASL Telnet Option
 109
 110      The GSSAPI/SASL service name for this profile of SASL is "rcmd".
 111
 112
 113
 114 Newman                                                          [Page 2]
 115 \f
 116 Internet Draft             Telnet SASL Option              November 1998
 117
 118
 119      The SASL Telnet option is Telnet option number XXX.  It has the
 120      following subnegotiation options:
 121
 122           LIST       0
 123           START      1
 124           STEP       2
 125           CANCEL     3
 126           DONE       4
 127
 128      The DONE subnegotiation option has the following codes:
 129
 130           SUCCESS    0
 131           CANCELLED  1
 132           BADAUTH    2
 133           BADPROT    3
 134           NOTAUTHZ   4
 135           EXPIRED    5
 136           ENCRYPT    6
 137           TOOWEAK    7
 138           TRANS      8
 139           DISABLED   9
 140
 141      The SASL Telnet option is negotiated only one way.  The server asks
 142      the client to use SASL with "DO SASL" and the client announces
 143      support with a "WILL SASL" message.  Once the option is
 144      successfully negotiated, the server sends the LIST subnegotiation
 145      containing an ASCII string with a space separated list of available
 146      SASL mechanisms:
 147
 148      S: IAC DO SASL
 149      C: IAC WILL SASL
 150      S: IAC SB SASL LIST "KERBEROS_V4 GSSAPI CRAM-MD5 OTP" IAC SB
 151
 152      The client sends the START subnegotiation to begin a SASL exchange
 153      with the server.  The START subnegotiation contains the desired
 154      mechanism name optionally followed by an ASCII NUL character and an
 155      initial client response.  The client is not required to wait for
 156      the LIST message from the server prior to sending a START message.
 157
 158      C: IAC SB SASL START "CRAM-MD5" IAC SE
 159
 160      This is followed by a series of STEP messages containing SASL
 161      messages for the client and server respectively:
 162
 163      S: IAC SB SASL STEP
 164          "<1896.697170952@postoffice.reston.mci.net>" IAC SE
 165      C: IAC SB SASL STEP "tim b913a602c7eda7a495b4e6e7334d3890" IAC SE
 166
 167
 168
 169
 170 Newman                                                          [Page 3]
 171 \f
 172 Internet Draft             Telnet SASL Option              November 1998
 173
 174
 175      Note that it is important to perform IAC doubling if the octet
 176      value 255 occurs in any SASL data.  This applies to data in the
 177      START, STEP and DONE suboptions.
 178
 179      When a client receives a STEP message from the server, it MAY
 180      cancel the authentication with the CANCEL message.  The server will
 181      respond with a DONE CANCELLED message.  If the client wishes to
 182      begin a new authentication, it MAY send a START message without
 183      waiting for the server DONE CANCELLED message.
 184
 185      C: IAC SB SASL CANCEL IAC SE
 186      S: IAC SB SASL DONE CANCELLED IAC SE
 187
 188      The server indicates successful completion of the exchange by
 189      sending the DONE subnegotiation with SUCCESS status, which MAY
 190      contain final server authentication data (usually for mutual
 191      authentication purposes).
 192
 193      S: IAC SB SASL DONE SUCCESS IAC SE
 194
 195      If a SASL security layer is negotiated, it begins on the server end
 196      immediately after the DONE SUCCESS subnegotiation, and begins on
 197      the client end immediately after the last client START or STEP
 198      subnegotiation once the SUCCESS subnegotiation is received.
 199
 200      For those cases where a security layer including integrity
 201      protection is negotiated, the server SHOULD send another LIST
 202      suboption message matching the one initially sent.  If the client
 203      supports any stronger authentication mechanism, it SHOULD verify
 204      that the new LIST suboption matches the one sent prior to
 205      authentication.
 206
 207      The server indicates failure by sending the DONE message with a
 208      code other than SUCCESS, followed by a human readable string in the
 209      character set currently active on the Telnet channel.  If no
 210      character set has been negotiated through prior agreement or the
 211      Telnet CHARSET option [TELNET-CHARSET], then UTF-8 [UTF-8] is
 212      assumed.
 213
 214      S: IAC SB SASL DONE BADAUTH "Authentication Failed" IAC SE
 215
 216      The following error codes are defined by this specification.  When
 217      in doubt of the appropriate error code, the BADAUTH error code
 218      should be used.  Additional error codes MAY be defined by future
 219      standards track or IESG approved experimental RFCs.
 220
 221      CANCELLED
 222           The authentication was cancelled by the client.
 223
 224
 225
 226 Newman                                                          [Page 4]
 227 \f
 228 Internet Draft             Telnet SASL Option              November 1998
 229
 230
 231      BADAUTH
 232           This indicates that the user does not exist or the
 233           authentication failed for a reason other than those listed
 234           below.
 235
 236      BADPROT
 237           This indicates the client attempted to use a mechanism not
 238           supported by the server, or the protocol for the SASL
 239           mechanism was not followed.
 240
 241      NOTAUTHZ
 242           This indicates the client successfully authenticated, but is
 243           not authorized to login to the service with the requested SASL
 244           authorization identity.
 245
 246      EXPIRED
 247           This indicates that the client passphrase, public key
 248           certificate or other credential has expired and can be updated
 249           with an appropriate passphrase/credential change protocol.
 250
 251      ENCRYPT
 252           This indicates that the requested client mechanism is not
 253           permitted without an encryption layer, such as that provided
 254           by TLS.  The client may activate such encryption, or try a
 255           stronger mechanism.
 256
 257      TOOWEAK
 258           This indicates that security policy does not permit the
 259           requested user to use the requested mechanism.  For example,
 260           an administrative user might be required to use a stronger
 261           mechanism.
 262
 263      TRANS
 264           This indicates the user has a valid verifier in a server
 265           authentication database but the requested mechanism can not be
 266           used with that verifier.  This also indicates that if the
 267           client changes the passphrase or does a one-time
 268           authentication with a clear-text passphrase mechanism
 269           (preferably encrypted), then the appropriate authentication
 270           database for the requested mechanism will be initialized.
 271
 272      DISABLED
 273           This indicates that the user's account has been disabled.  The
 274           user must contact a system administrator to get their account
 275           re-enabled.
 276
 277
 278
 279
 280
 281
 282 Newman                                                          [Page 5]
 283 \f
 284 Internet Draft             Telnet SASL Option              November 1998
 285
 286
 287 5. Formal Syntax
 288
 289      The following formal syntax uses ABNF [ABNF]:
 290
 291        IAC          = %d255    ; standard Telnet symbols
 292        DO           = %d253
 293        WILL         = %d251
 294        SB           = %d250
 295        SE           = %d240
 296        SASL         = %dXXX    ; Telnet SASL option
 297        LIST         = %d0      ; Telnet SASL sub-options
 298        START        = %d1
 299        STEP         = %d2
 300        CANCEL       = %d3
 301        DONE         = %d4
 302
 303        ; Miscellaneous single-character symbols
 304        DIGIT        = %d30-39  ; US-ASCII digit character
 305        UPALPHA      = %d65-90  ; Uppercase alphabetic characters
 306        MECH-CHAR    = %d65-90 / DIGIT / "-" / "_"
 307        SAFE-DATA    = %d0-254  ; octets which don't need quoting
 308        TEXT         = %d1-254  ; human readable text
 309        SP           = %d32     ; US-ASCII space
 310        NUL          = %d0      ; US-ASCII NUL
 311
 312        ; Miscellaneous multi-character symbols
 313        quoted-255   = %d255 %d255
 314        sasl-mech    = 1*20mech-char
 315        subopt-data  = SAFE-DATA / quoted-255
 316        text         = *subopt-data  ; human readable text
 317        sasl-data    = *subopt-data
 318        success      = %d0 sasl-data
 319        error        = %d1-254 text
 320
 321        ; Telnet SASL messages
 322        sasl-do      = IAC DO SASL
 323        sasl-will    = IAC WILL SASL
 324        sasl-list    = IAC SB SASL LIST *(sasl-mech SP) sasl-mech IAC SE
 325        sasl-start   = IAC SB SASL START sasl-mech [NUL sasl-data] IAC SE
 326        sasl-step    = IAC SB SASL STEP sasl-data IAC SE
 327        sasl-cancel  = IAC SB SASL CANCEL IAC SE
 328        sasl-done    = IAC SB SASL DONE (success / error) IAC SE
 329
 330 6. Security Considerations
 331
 332      This inherits the security considerations of SASL [SASL] and any
 333      underlying mechanism used.
 334
 335
 336
 337
 338 Newman                                                          [Page 6]
 339 \f
 340 Internet Draft             Telnet SASL Option              November 1998
 341
 342
 343      The SASL LIST subnegotiation is not integrity protected and is thus
 344      susceptible to tampering by an active attacker.  There are two ways
 345      to mitigate this attack: (1) have the client explicitly configured
 346      to use a specific mechanism and never fall back to a weaker one.
 347      (2) have the client configurable to require integrity protection,
 348      and verify that the LIST suboption value is the same both before
 349      and after the integrity protection is applied.
 350
 351      With some SASL mechanisms, the ENCRYPT or TOOWEAK error codes will
 352      be generated after sensitive information has been exposed.  For
 353      this reason, clients SHOULD be configurable to disable weaker
 354      mechanisms which might reveal sensitive information and SHOULD do
 355      so for user, mechanism and server combinations which result in
 356      these error codes.
 357
 358      The TRANS error code could be spuriously generated by an active
 359      attacker.  For this reason, the client SHOULD NOT use a weaker
 360      mechanism in response to a TRANS error code without explicit user
 361      permission.  The TRANS error code can also be used to probe for
 362      untransitioned users at a site.  For this reason, sites must
 363      consider the tradeoffs between a user-friendly transition to a
 364      stronger mechanism and the risks entailed by permitting such
 365      transitions.
 366
 367      Telnet server and client implementations MUST check for buffer
 368      overrun on Telnet subnegotiations and deal with more data than will
 369      fit in an internal buffer gracefully.
 370
 371 7. References
 372
 373      [ABNF] Crocker, Overell, "Augmented BNF for Syntax Specifications:
 374      ABNF", RFC 2234, Internet Mail Consortium, Demon Internet Ltd,
 375      November 1997.
 376
 377      [CRAM-MD5] Klensin, Catoe, Krumviede, "IMAP/POP AUTHorize Extension
 378      for Simple Challenge/Response", RFC 2195, MCI, September 1997.
 379
 380      [GSSAPI] Linn, "Generic Security Service Application Program
 381      Interface, Version 2", RFC 2078, OpenVision Technologies, January
 382      1997.
 383
 384      [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
 385      Requirement Levels", RFC 2119, Harvard University, March 1997.
 386
 387      [OTP-SASL] Newman, C., "The One-Time-Password SASL mechanism", RFC
 388      2444, Innosoft, October 1998.
 389
 390
 391
 392
 393
 394 Newman                                                          [Page 7]
 395 \f
 396 Internet Draft             Telnet SASL Option              November 1998
 397
 398
 399      [SASL] Myers, "Simple Authentication and Security Layer (SASL)",
 400      RFC 2222, Netscape Communications, October 1997.
 401
 402      [TELNET] Postel, J., Reynolds, J., "TELNET PROTOCOL SPECIFICATION",
 403      RFC 854, ISI, May 1983.
 404
 405      [TELNET-AUTH] Borman, "Telnet Authentication Option", RFC 1416,
 406      Cray Research, Inc., February 1993.
 407
 408      [TELNET-CHARSET] Gellens, R., "TELNET CHARSET Option", RFC 2066,
 409      Unisys, January 1997.
 410
 411      [TELNET-ENC] Ts'o, T., "Telnet Data Encryption Option", work in
 412      progress.
 413
 414      [TELNET-KRB] Borman, "Telnet Authentication: Kerberos Version 4",
 415      RFC 1411, Cray Research, Inc., January 1993.
 416
 417      [UTF-8] Yergeau, F. "UTF-8, a transformation format of ISO 10646",
 418      RFC 2279, Alis Technologies, January 1998.
 419
 420 8. Author's Address
 421
 422      Chris Newman
 423      Innosoft International, Inc.
 424      1050 Lakes Drive
 425      West Covina, CA 91790 USA
 426
 427      Email: chris.newman@innosoft.com
 428
 429
 430
 431
 432
 433
 434
 435
 436
 437
 438
 439
 440
 441
 442
 443
 444
 445
 446
 447
 448
 449
 450 Newman                                                          [Page 8]