doc/specifications/rfc2942.txt

   1
   2
   3
   4
   5
   6
   7 Network Working Group                                            T. Ts'o
   8 Request for Comments: 2942                              VA Linux Systems
   9 Category: Standards Track                                 September 2000
  10
  11
  12                Telnet Authentication: Kerberos Version 5
  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 describes how Kerberos Version 5 [1] is used with the
  29    telnet protocol.   It describes an telnet authentication suboption to
  30    be used with the telnet authentication option [2].   This mechanism
  31    can also used to provide keying material to provide data
  32    confidentiality services in conjunction with the telnet encryption
  33    option [3].
  34
  35 1. Command Names and Codes
  36
  37       Authentication Types
  38
  39          KERBEROS_V5    2
  40
  41       Sub-option Commands
  42
  43          AUTH               0
  44          REJECT             1
  45          ACCEPT             2
  46          RESPONSE           3
  47          FORWARD            4
  48          FORWARD_ACCEPT     5
  49          FORWARD_REJECT     6
  50
  51
  52
  53
  54
  55
  56
  57
  58 Ts'o                        Standards Track                     [Page 1]
  59 \f
  60 RFC 2942       Telnet Authentication: Kerberos Version 5  September 2000
  61
  62
  63 2.  Command Meanings
  64
  65    IAC SB AUTHENTICATION IS <authentication-type-pair> AUTH <Kerberos V5
  66    KRB_AP_REQ message> IAC SE
  67
  68       This is used to pass the Kerberos V5 [1] KRB_AP_REQ message to the
  69       remote side of the connection.  The first octet of the
  70       <authentication-type-pair> value is KERBEROS_V5, to indicate that
  71       Version 5 of Kerberos is being used.  The Kerberos V5
  72       authenticator in the KRB_AP_REQ message must contain a Kerberos V5
  73       checksum of the two-byte authentication type pair.  This checksum
  74       must be verified by the server to assure that the authentication
  75       type pair was correctly negotiated.  The Kerberos V5 authenticator
  76       must also include the optional subkey field, which shall be filled
  77       in with a randomly chosen key.  This key shall be used for
  78       encryption purposes if encryption is negotiated, and shall be used
  79       as the negotiated session key (i.e., used as keyid 0) for the
  80       purposes of the telnet encryption option; if the subkey is not
  81       filled in, then the ticket session key will be used instead.
  82
  83       If data confidentiality services is desired the ENCRYPT_US-
  84       ING_TELOPT flag must be set in the authentication-type-pair as
  85       specified in [2].
  86
  87    IAC SB AUTHENTICATION REPLY <authentication-type-pair> ACCEPT IAC SE
  88
  89       This command indicates that the authentication was successful.
  90
  91       If the AUTH_HOW_MUTUAL bit is set in the second octet of the
  92       authentication-type-pair, the RESPONSE command must be sent before
  93       the ACCEPT command is sent.
  94
  95    IAC SB AUTHENTICATION REPLY <authentication-type-pair> REJECT
  96       <optional reason for rejection> IAC SE
  97
  98       This command indicates that the authentication was not successful,
  99       and if there is any more data in the sub-option, it is an ASCII
 100       text message of the reason for the rejection.
 101
 102    IAC SB AUTHENTICATION REPLY <authentication-type-pair> RESPONSE
 103    <KRB_AP_REP message> IAC SE
 104
 105       This command is used to perform mutual authentication.  It is only
 106       used when the AUTH_HOW_MUTUAL bit is set in the second octet of
 107       the authentication-type-pair.  After an AUTH command is verified,
 108       a RESPONSE command is sent which contains a Kerberos V5 KRB_AP_REP
 109       message to perform the mutual authentication.
 110
 111
 112
 113
 114 Ts'o                        Standards Track                     [Page 2]
 115 \f
 116 RFC 2942       Telnet Authentication: Kerberos Version 5  September 2000
 117
 118
 119    IAC SB AUTHENTICATION <authentication-type-pair> FORWARD <KRB_CRED
 120    message> IAC SE
 121
 122       This command is used to forward kerberos credentials for use by
 123       the remote session.  The credentials are passed as a Kerberos V5
 124       KRB_CRED message which includes, among other things, the forwarded
 125       Kerberos ticket and a session key associated with the ticket.
 126       Part of the KRB_CRED message is encrypted in the key previously
 127       exchanged for the telnet session by the AUTH suboption.
 128
 129    IAC SB AUTHENTICATION <authentication-type-pair> FORWARD_ACCEPT IAC
 130    SE
 131
 132       This command indicates that the credential forwarding was
 133       successful.
 134
 135    IAC SB AUTHENTICATION <authentication-type-pair> FORWARD_REJECT
 136       <optional reason for rejection> IAC SE
 137
 138       This command indicates that the credential forwarding was not
 139       successful, and if there is any more data in the suboption, it is
 140       an ASCII text message of the reason for the rejection.
 141
 142 3.  Implementation Rules
 143
 144    If the second octet of the authentication-type-pair has the AUTH_WHO
 145    bit set to AUTH_CLIENT_TO_SERVER, then the client sends the initial
 146    AUTH command, and the server responds with either ACCEPT or REJECT.
 147    In addition, if the AUTH_HOW bit is set to AUTH_HOW_MUTUAL, the
 148    server will send a RESPONSE before it sends the ACCEPT.
 149
 150    If the second octet of the authentication-type-pair has the AUTH_WHO
 151    bit set to AUTH_SERVER_TO_CLIENT, then the server sends the initial
 152    AUTH command, and the client responds with either ACCEPT or REJECT.
 153    In addition, if the AUTH_HOW bit is set to AUTH_HOW_MUTUAL, the
 154    client will send a RESPONSE before it sends the ACCEPT.
 155
 156    The Kerberos principal used by the server will generally be of the
 157    form "host/<hostname>@realm".  That is, the first component of the
 158    Kerberos principal is "host"; the second component is the fully
 159    qualified lower-case hostname of the server; and the realm is the
 160    Kerberos realm to which the server belongs.
 161
 162    Any Telnet IAC characters that occur in the KRB_AP_REQ or KRB_AP_REP
 163    messages, the KRB_CRED structure, or the optional rejection text
 164    string must be doubled as specified in [4].  Otherwise the following
 165    byte might be mis-interpreted as a Telnet command.
 166
 167
 168
 169
 170 Ts'o                        Standards Track                     [Page 3]
 171 \f
 172 RFC 2942       Telnet Authentication: Kerberos Version 5  September 2000
 173
 174
 175 4.  Examples
 176
 177    User "joe" may wish to log in as user "pete" on machine "foo".  If
 178    "pete" has set things up on "foo" to allow "joe" access to his
 179    account, then the client would send IAC SB AUTHENTICATION NAME "pete"
 180    IAC SE IAC SB AUTHENTICATION IS KERBEROS_V5 AUTH <KRB_AP_REQ_MESSAGE>
 181    IAC SE
 182
 183    The server would then authenticate the user as "joe" from the
 184    KRB_AP_REQ_MESSAGE, and if the KRB_AP_REQ_MESSAGE was accepted by
 185    Kerberos, and if "pete" has allowed "joe" to use his account, the
 186    server would then continue the authentication sequence by sending a
 187    RESPONSE (to do mutual authentication, if it was requested) followed
 188    by the ACCEPT.
 189
 190    If forwarding has been requested, the client then sends IAC SB
 191    AUTHENTICATION IS KERBEROS_V5 CLIENT|MUTUAL FORWARD <KRB_CRED
 192    structure with credentials to be forwarded> IAC SE.  If the server
 193    succeeds in reading the forwarded credentials, the server sends
 194    FORWARD_ACCEPT else, a FORWARD_REJECT is sent back.
 195
 196        Client                           Server
 197                                         IAC DO AUTHENTICATION
 198        IAC WILL AUTHENTICATION
 199
 200        [ The server is now free to request authentication information.
 201          ]
 202
 203                                         IAC SB AUTHENTICATION SEND
 204                                         KERBEROS_V5 CLIENT|MUTUAL
 205                                         KERBEROS_V5 CLIENT|ONE_WAY IAC
 206                                         SE
 207
 208        [ The server has requested mutual Version 5 Kerberos
 209          authentication.  If mutual authentication is not supported,
 210          then the server is willing to do one-way authentication.
 211
 212          The client will now respond with the name of the user that it
 213          wants to log in as, and the Kerberos ticket.  ]
 214
 215        IAC SB AUTHENTICATION NAME
 216        "pete" IAC SE
 217        IAC SB AUTHENTICATION IS
 218        KERBEROS_V5 CLIENT|MUTUAL AUTH
 219        <KRB_AP_REQ message> IAC SE
 220
 221        [ Since mutual authentication is desired, the server sends across
 222          a RESPONSE to prove that it really is the right server.  ]
 223
 224
 225
 226 Ts'o                        Standards Track                     [Page 4]
 227 \f
 228 RFC 2942       Telnet Authentication: Kerberos Version 5  September 2000
 229
 230
 231                                         IAC SB AUTHENTICATION REPLY
 232                                         KERBEROS_V5 CLIENT|MUTUAL
 233                                         RESPONSE <KRB_AP_REP message>
 234                                         IAC SE
 235
 236        [ The server responds with an ACCEPT command to state that the
 237          authentication was successful.  ]
 238
 239                                         IAC SB AUTHENTICATION REPLY
 240                                         KERBEROS_V5 CLIENT|MUTUAL ACCEPT
 241                                         IAC SE
 242
 243        [ If so requested, the client now sends the FORWARD command to
 244          forward credentials to the remote site.  ]
 245
 246        IAC SB AUTHENTICATION IS KER-
 247        BEROS_V5 CLIENT|MUTUAL
 248        FORWARD <KRB_CRED message> IAC
 249        SE
 250
 251        [ The server responds with a FORWARD_ACCEPT command to state that
 252          the credential forwarding was successful.  ]
 253
 254                                         IAC SB AUTHENTICATION REPLY
 255                                         KERBEROS_V5 CLIENT|MUTUAL
 256                                         FORWARD_ACCEPT IAC SE
 257
 258 5. Security Considerations
 259
 260    The selection of the random session key in the Kerberos V5
 261    authenticator is critical, since this key will be used for encrypting
 262    the telnet data stream if encryption is enabled.  It is strongly
 263    advised that the random key selection be done using cryptographic
 264    techniques that involve the Kerberos ticket's session key.  For
 265    example, using the current time, encrypting it with the ticket
 266    session key, and then correcting for key parity is a strong way to
 267    generate a subsession key, since the ticket session key is assumed to
 268    be never disclosed to an attacker.
 269
 270    Care should be taken before forwarding a user's Kerberos credentials
 271    to the remote server.  If the remote server is not trustworthy, this
 272    could result in the user's credentials being compromised.  Hence, the
 273    user interface should not forward credentials by default; it would be
 274    far safer to either require the user to explicitly request
 275    credentials forwarding for each connection, or to have a trusted list
 276    of hosts for which credentials forwarding is enabled, but to not
 277    enable credentials forwarding by default for all machines.
 278
 279
 280
 281
 282 Ts'o                        Standards Track                     [Page 5]
 283 \f
 284 RFC 2942       Telnet Authentication: Kerberos Version 5  September 2000
 285
 286
 287    The IAC SB AUTHENTICATION NAME name IAC SE message is unprotected in
 288    this protocol.  Its contents should be verified by a secure method
 289    after authentication completes before it is used.
 290
 291 6. IANA Considerations
 292
 293    The authentication type KERBEROS_V5 and its associated suboption
 294    values are registered with IANA.  Any suboption values used to extend
 295    the protocol as described in this document must be registered with
 296    IANA before use.  IANA is instructed not to issue new suboption
 297    values without submission of documentation of their use.
 298
 299 7. Acknowledgments
 300
 301    This document was originally written by Dave Borman of Cray Research,
 302    Inc.  Theodore Ts'o of MIT revised it to reflect the latest
 303    implementation experience.  Cliff Neuman and Prasad Upasani of USC's
 304    Information Sciences Institute developed the credential forwarding
 305    support.
 306
 307    In addition, the contributions of the Telnet Working Group are also
 308    gratefully acknowledged.
 309
 310 8. References
 311
 312    [1] Kohl, J. and B. Neuman, "The Kerberos Network Authentication
 313        System (V5)", RFC 1510, September 1993.
 314
 315    [2] Ts'o, T. and J. Altman, "Telnet Authentication Option", RFC 2941,
 316        September 2000.
 317
 318    [3] Ts'o, T., "Telnet Data Encryption Option", RFC 2946, September
 319        2000.
 320
 321    [4] Postel, J. and J. Reynolds, "Telnet Option Specifications", STD
 322        8, RFC 855, May 1983.
 323
 324 9. Editor's Address
 325
 326    Theodore Ts'o
 327    VA Linux Systems
 328    43 Pleasant St.
 329    Medford, MA 02155
 330
 331    Phone: (781) 391-3464
 332    EMail: tytso@mit.edu
 333
 334
 335
 336
 337
 338 Ts'o                        Standards Track                     [Page 6]
 339 \f
 340 RFC 2942       Telnet Authentication: Kerberos Version 5  September 2000
 341
 342
 343 10. Full Copyright Statement
 344
 345    Copyright (C) The Internet Society (2000).  All Rights Reserved.
 346
 347    This document and translations of it may be copied and furnished to
 348    others, and derivative works that comment on or otherwise explain it
 349    or assist in its implementation may be prepared, copied, published
 350    and distributed, in whole or in part, without restriction of any
 351    kind, provided that the above copyright notice and this paragraph are
 352    included on all such copies and derivative works.  However, this
 353    document itself may not be modified in any way, such as by removing
 354    the copyright notice or references to the Internet Society or other
 355    Internet organizations, except as needed for the purpose of
 356    developing Internet standards in which case the procedures for
 357    copyrights defined in the Internet Standards process must be
 358    followed, or as required to translate it into languages other than
 359    English.
 360
 361    The limited permissions granted above are perpetual and will not be
 362    revoked by the Internet Society or its successors or assigns.
 363
 364    This document and the information contained herein is provided on an
 365    "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
 366    TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
 367    BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
 368    HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
 369    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 370
 371 Acknowledgement
 372
 373    Funding for the RFC Editor function is currently provided by the
 374    Internet Society.
 375
 376
 377
 378
 379
 380
 381
 382
 383
 384
 385
 386
 387
 388
 389
 390
 391
 392
 393
 394 Ts'o                        Standards Track                     [Page 7]
 395 \f