doc/specifications/draft-tso-telnet-krb5-01.txt

   1
   2
   3
   4
   5 Network Working Group                                    T. Ts'o, Editor
   6 Internet-Draft                     Massachusetts Institute of Technology
   7 draft-tso-telnet-krb5-01.txt                               November 1998
   8
   9
  10                Telnet Authentication: Kerberos Version 5
  11
  12 Status of this Memo
  13
  14    This document is an Internet-Draft.  Internet-Drafts are working
  15    documents of the Internet Engineering Task Force (IETF), its areas,
  16    and its working groups.  Note that other groups may also distribute
  17    working documents as Internet-Drafts.
  18
  19    Internet-Drafts are draft documents valid for a maximum of six months
  20    and may be updated, replaced, or obsoleted by other documents at any
  21    time.  It is inappropriate to use Internet- Drafts as reference
  22    material or to cite them other than as "work in progress."
  23
  24    To view the entire list of current Internet-Drafts, please check the
  25    "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
  26    Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe),
  27    munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or
  28    ftp.isi.edu (US West Coast).
  29
  30 1. Command Names and Codes
  31
  32    Authentication Types
  33
  34       KERBEROS_V5     2
  35
  36    Sub-option Commands
  37
  38       AUTH               0
  39       REJECT             1
  40       ACCEPT             2
  41       RESPONSE           3
  42       FORWARD            4
  43       FORWARD_ACCEPT     5
  44       FORWARD_REJECT     6
  45
  46 2.  Command Meanings
  47
  48    IAC SB AUTHENTICATION IS <authentication-type-pair> AUTH <Kerberos V5
  49    KRB_AP_REQ message> IAC SE
  50
  51       This is used to pass the Kerberos V5 [1] KRB_AP_REQ message to the
  52
  53
  54
  55                             Expires May 1999                    [Page 1]
  56 \f
  57 Internet-Draft       Kerberos Version 5 for Telnet         November 1998
  58
  59
  60       remote side of the connection.  The first octet of the
  61       <authentication-type-pair> value is KERBEROS_V5, to indicate that
  62       Version 5 of Kerberos is being used.  The Kerberos V5
  63       authenticator in the KRB_AP_REQ message must contain a Kerberos V5
  64       checksum of the two-byte authentication type pair.  This checksum
  65       must be verified by the server to assure that the authentication
  66       type pair was correctly negotiated.  The Kerberos V5 authenticator
  67       must also include the optional subkey field, which shall be filled
  68       in with a randomly chosen key.  This key shall be used for
  69       encryption purposes if encryption is negotiated, and shall be
  70       assigned keyid 0 for the purposes of the telnet encryption option;
  71       if the subkey is not filled in, then the ticket session key will
  72       be used instead.
  73
  74    IAC SB AUTHENTICATION REPLY <authentication-type-pair> ACCEPT IAC SE
  75
  76       This command indicates that the authentication was successful.
  77
  78       If the AUTH_HOW_MUTUAL bit is set in the second octet of the
  79       authentication-type-pair, the RESPONSE command must be sent before
  80       the ACCEPT command is sent.
  81
  82    IAC SB AUTHENTICATION REPLY <authentication-type-pair> REJECT
  83    <optional reason for rejection> IAC SE
  84
  85       This command indicates that the authentication was not successful,
  86       and if there is any more data in the sub-option, it is an ASCII
  87       text message of the reason for the rejection.
  88
  89    IAC SB AUTHENTICATION REPLY <authentication-type-pair> RESPONSE
  90    <KRB_AP_REP message> IAC SE
  91
  92       This command is used to perform mutual authentication.  It is only
  93       used when the AUTH_HOW_MUTUAL bit is set in the second octet of
  94       the authentication-type-pair.  After an AUTH command is verified,
  95       a RESPONSE command is sent which contains a Kerberos V5 KRB_AP_REP
  96       message to perform the mutual authentication.
  97
  98    IAC SB AUTHENTICATION <authentication-type-pair> FORWARD <KRB_CRED
  99    message> IAC SE
 100
 101       This command is used to forward kerberos credentials for use by
 102       the remote session.  The credentials are passed as a Kerberos V5
 103       KRB_CRED message which includes, among other things, the forwarded
 104       Kerberos ticket and a session key associated with the ticket. Part
 105       of the KRB_CRED message is encrypted in the key previously
 106       exchanged for the telnet session by the AUTH suboption.
 107
 108    IAC SB AUTHENTICATION <authentication-type-pair> FORWARD_ACCEPT IAC
 109    SE
 110
 111
 112
 113                             Expires May 1999                    [Page 2]
 114 \f
 115 Internet-Draft       Kerberos Version 5 for Telnet         November 1998
 116
 117
 118       This command indicates that the credential forwarding was
 119       successful.
 120
 121    IAC SB AUTHENTICATION <authentication-type-pair> FORWARD_REJECT
 122    <optional reason for rejection> IAC SE
 123
 124       This command indicates that the credential forwarding was not
 125       successful, and if there is any more data in the sub-option, it is
 126       an ASCII text message of the reason for the rejection.
 127
 128
 129 3.  Implementation Rules
 130
 131    If the second octet of the authentication-type-pair has the AUTH_WHO
 132    bit set to AUTH_CLIENT_TO_SERVER, then the client sends the initial
 133    AUTH command, and the server responds with either ACCEPT or REJECT.
 134    In addition, if the AUTH_HOW bit is set to AUTH_HOW_MUTUAL, the
 135    server will send a RESPONSE before it sends the ACCEPT.
 136
 137    If the second octet of the authentication-type-pair has the AUTH_WHO
 138    bit set to AUTH_SERVER_TO_CLIENT, then the server sends the initial
 139    AUTH command, and the client responds with either ACCEPT or REJECT.
 140    In addition, if the AUTH_HOW bit is set to AUTH_HOW_MUTUAL, the
 141    client will send a RESPONSE before it sends the ACCEPT.
 142
 143    The Kerberos principal used by the server will generally be of the
 144    form "host/<hostname>@realm".  That is, the first component of the
 145    Kerberos principal is "host"; the second component is the fully
 146    qualified lower-case hostname of the server; and the realm is the
 147    Kerberos realm to which the server belongs.
 148
 149    Any Telnet IAC characters that occur in the KRB_AP_REQ or KRB_AP_REP
 150    messages, the KRB_CRED structure, or the optional rejection text
 151    string must be doubled as specified in [2].  Otherwise the following
 152    byte might be mis-interpreted as a Telnet command.
 153
 154 4.  Examples
 155
 156    User "joe" may wish to log in as user "pete" on machine "foo".  If
 157    "pete" has set things up on "foo" to allow "joe" access to his
 158    account, then the client would send IAC SB AUTHENTICATION NAME "pete"
 159    IAC SE IAC SB AUTHENTICATION IS KERBEROS_V5 AUTH <KRB_AP_REQ_MESSAGE>
 160    IAC SE
 161
 162    The server would then authenticate the user as "joe" from the
 163    KRB_AP_REQ_MESSAGE, and if the KRB_AP_REQ_MESSAGE was accepted by
 164    Kerberos, and if "pete" has allowed "joe" to use his account, the
 165    server would then continue the authentication sequence by sending a
 166    RESPONSE (to do mutual authentication, if it was requested) followed
 167    by the ACCEPT.
 168
 169
 170
 171                             Expires May 1999                    [Page 3]
 172 \f
 173 Internet-Draft       Kerberos Version 5 for Telnet         November 1998
 174
 175
 176    If forwarding has been requested, the client then sends IAC SB
 177    AUTHENTICATION IS KERBEROS_V5 CLIENT|MUTUAL FORWARD <KRB_CRED
 178    structure with credentials to be forwarded> IAC SE.  If the server
 179    succeeds in reading the forwarded credentials, the server sends
 180    FORWARD_ACCEPT else, a FORWARD_REJECT is sent back.
 181
 182        Client                           Server
 183                                         IAC DO AUTHENTICATION
 184        IAC WILL AUTHENTICATION
 185
 186        [ The server is now free to request authentication information.
 187          ]
 188
 189                                         IAC SB AUTHENTICATION SEND
 190                                         KERBEROS_V5 CLIENT|MUTUAL
 191                                         KERBEROS_V5 CLIENT|ONE_WAY IAC
 192                                         SE
 193
 194        [ The server has requested mutual Version 5 Kerberos
 195          authentication.  If mutual authentication is not supported,
 196          then the server is willing to do one-way authentication.
 197
 198          The client will now respond with the name of the user that it
 199          wants to log in as, and the Kerberos ticket.  ]
 200
 201        IAC SB AUTHENTICATION NAME
 202        "pete" IAC SE
 203        IAC SB AUTHENTICATION IS
 204        KERBEROS_V5 CLIENT|MUTUAL AUTH
 205        <KRB_AP_REQ message> IAC SE
 206
 207        [ Since mutual authentication is desired, the server sends across
 208          a RESPONSE to prove that it really is the right server.  ]
 209
 210                                         IAC SB AUTHENTICATION REPLY
 211                                         KERBEROS_V5 CLIENT|MUTUAL
 212                                         RESPONSE <KRB_AP_REP message>
 213                                         IAC SE
 214
 215        [ The server responds with an ACCEPT command to state that the
 216          authentication was successful.  ]
 217
 218                                         IAC SB AUTHENTICATION REPLY
 219                                         KERBEROS_V5 CLIENT|MUTUAL ACCEPT
 220                                         IAC SE
 221
 222        [ If so requested, the client now sends the FORWARD command to
 223          forward credentials to the remote site.  ]
 224
 225        IAC SB AUTHENTICATION IS
 226
 227
 228
 229                             Expires May 1999                    [Page 4]
 230 \f
 231 Internet-Draft       Kerberos Version 5 for Telnet         November 1998
 232
 233
 234        KERBEROS_V5 CLIENT|MUTUAL
 235        FORWARD <KRB_CRED message> IAC
 236        SE
 237
 238        [ The server responds with a FORWARD_ACCEPT command to state that
 239          the credential forwarding was successful.  ]
 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                             Expires May 1999                    [Page 5]
 288 \f
 289 Internet-Draft       Kerberos Version 5 for Telnet         November 1998
 290
 291
 292                                         IAC SB AUTHENTICATION REPLY
 293                                         KERBEROS_V5 CLIENT|MUTUAL
 294                                         FORWARD_ACCEPT IAC SE
 295
 296 5. Security Considerations
 297
 298    The selection of the random session key in the Kerberos V5 authenti-
 299    cator is critical, since this key will be used for encrypting the
 300    telnet data stream if encryption is enabled.  It is strongly advised
 301    that the random key selection be done using cryptographic techniques
 302    that involve the Kerberos ticket's session key.  For example, using
 303    the current time, encrypting it with the ticket session key, and then
 304    correcting for key parity is a strong way to generate a subsession
 305    key, since the ticket session key is assumed to be never disclosed to
 306    an attacker.
 307
 308    Care should be taken before forwarding a user's Kerberos credentials
 309    to the remote server.  If the remote server is not trustworthy, this
 310    could result in the user's credentials being compromised.  Hence, the
 311    user interface should not forward credentials by default; it would be
 312    far safer to either require the user to explicitly request creden-
 313    tials forwarding for each connection, or to have a trusted list of
 314    hosts for which credentials forwarding is enabled, but to not enable
 315    credentials forwarding by default for all machines.
 316
 317 6. Acknowledgments
 318
 319    This document was originally written by Dave Borman of Cray Research,
 320    Inc.  Theodore Ts'o of MIT revised it to reflect the latest implemen-
 321    tation experience.  Cliff Neuman and Prasad Upasani of USC's Informa-
 322    tion Sciences Institute developed the credential forwarding support.
 323
 324    In addition, the contributions of the Telnet Working Group are also
 325    gratefully acknowledged.
 326
 327 7. References
 328
 329    [1] Kohl, J. and B. Neuman, "The Kerberos Network Authentication Sys-
 330        tem (V5)", RFC 1510, USC/Information Sciences Institute, Sep-
 331        tember 1993.
 332
 333    [2] Postel, J.B. and J. Reynolds, "Telnet Option Specifications", RFC
 334        855, STD 8, USC/Information Sciences Institute, May 1983.
 335
 336
 337 Editor's Address
 338
 339    Theodore Ts'o
 340    Massachusetts Institute of Technology
 341    MIT Room E40-343
 342
 343
 344
 345                             Expires May 1999                    [Page 6]
 346 \f
 347 Internet-Draft       Kerberos Version 5 for Telnet         November 1998
 348
 349
 350    77 Massachusetts Avenue
 351    Cambridge, MA 02139
 352
 353    Phone: (617) 253-8091
 354    EMail: tytso@mit.edu
 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                             Expires May 1999                    [Page 7]
 404 \f