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

   1 Network Working Group                                    T. Ts'o, Editor
   2 Internet-Draft                     Massachusetts Institute of Technology
   3 draft-tso-telnet-krb5-03.txt                              September 1999
   4
   5                Telnet Authentication: Kerberos Version 5
   6
   7 Status of this Memo
   8
   9    This document is an Internet-Draft and is in full conformance with
  10    all provisions of Section 10 of RFC2026.  Internet-Drafts are working
  11    documents of the Internet Engineering Task Force (IETF), its areas,
  12    and its working groups.  Note that other groups may also distribute
  13    working documents as Internet-Drafts.
  14
  15    Internet-Drafts are draft documents valid for a maximum of six months
  16    and may be updated, replaced, or obsoleted by other documents at any
  17    time.  It is inappropriate to use Internet-Drafts as reference mate-
  18    rial or to cite them other than as "work in progress."
  19
  20    The list of current Internet-Drafts can be accessed at
  21    http://www.ietf.org/ietf/1id-abstracts.txt
  22
  23    The list of Internet-Draft Shadow Directories can be accessed at
  24    http://www.ietf.org/shadow.html.
  25
  26    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
  27    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
  28    document are to be interpreted as described in RFC 2119.
  29
  30 0. Abstract
  31
  32    This document describes how Kerberos Version 5 [1] is used with the
  33    telnet protocol.   It describes an telnet authentication sub-option
  34    to be used with the telnet authentication option [2].   This mecha-
  35    nism can also used to provide keying material to provide data confi-
  36    dentiality services in conjuction with the telnet encryption option
  37    [3].
  38
  39 1. Command Names and Codes
  40
  41    Authentication Types
  42
  43       KERBEROS_V5    2
  44
  45    Sub-option Commands
  46
  47                            Expires March 2000                   [Page 1]
  48
  49 Internet-Draft        Kerberos Version 5 for Telnet       September 1999
  50
  51       AUTH               0
  52       REJECT             1
  53       ACCEPT             2
  54       RESPONSE           3
  55       FORWARD            4
  56       FORWARD_ACCEPT     5
  57       FORWARD_REJECT     6
  58
  59 2.  Command Meanings
  60
  61    IAC SB AUTHENTICATION IS <authentication-type-pair> AUTH <Kerberos V5
  62    KRB_AP_REQ message> IAC SE
  63
  64       This is used to pass the Kerberos V5 [1] KRB_AP_REQ message to the
  65       remote side of the connection.  The first octet of the <authenti-
  66       cation-type-pair> value is KERBEROS_V5, to indicate that Version 5
  67       of Kerberos is being used.  The Kerberos V5 authenticator in the
  68       KRB_AP_REQ message     must contain a Kerberos V5 checksum of the
  69       two-byte authentication type pair.  This checksum must be verified
  70       by the server to assure that the authentication type pair was cor-
  71       rectly negotiated.  The Kerberos V5 authenticator must also in-
  72       clude the optional subkey field, which shall be filled in with a
  73       randomly chosen key.  This key shall be used for encryption pur-
  74       poses if encryption is negotiated, and shall be used as the nego-
  75       tiated session key (i.e., used as keyid 0) for the purposes of the
  76       telnet encryption option; if the subkey is not filled in, then the
  77       ticket session key will be used instead.
  78
  79       If data confidentiality services is desired the ENCRYPT_US-
  80       ING_TELOPT flag must be set in the authentication-type-pair as
  81       specified in [2].
  82
  83    IAC SB AUTHENTICATION REPLY <authentication-type-pair> ACCEPT IAC SE
  84
  85       This command indicates that the authentication was successful.
  86
  87       If the AUTH_HOW_MUTUAL bit is set in the second octet of the au-
  88       thentication-type-pair, the RESPONSE command must be sent before
  89       the ACCEPT command is sent.
  90
  91    IAC SB AUTHENTICATION REPLY <authentication-type-pair> REJECT <op-
  92    tional reason for rejection> IAC SE
  93
  94       This command indicates that the authentication was not successful,
  95       and if there is any more data in the sub-option, it is an ASCII
  96       text message of the reason for the rejection.
  97
  98    IAC SB AUTHENTICATION REPLY <authentication-type-pair> RESPONSE
  99    <KRB_AP_REP message> IAC SE
 100
 101                            Expires March 2000                   [Page 2]
 102
 103 Internet-Draft        Kerberos Version 5 for Telnet       September 1999
 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    IAC SB AUTHENTICATION <authentication-type-pair> FORWARD <KRB_CRED
 112    message> IAC SE
 113
 114       This command is used to forward kerberos credentials for use by
 115       the remote session.  The credentials are passed as a Kerberos V5
 116       KRB_CRED message which includes, among other things, the forwarded
 117       Kerberos ticket and a session key associated with the ticket. Part
 118       of the KRB_CRED message is encrypted in the key previously ex-
 119       changed for the telnet session by the AUTH suboption.
 120
 121    IAC SB AUTHENTICATION <authentication-type-pair> FORWARD_ACCEPT IAC
 122    SE
 123
 124       This command indicates that the credential forwarding was success-
 125       ful.
 126
 127    IAC SB AUTHENTICATION <authentication-type-pair> FORWARD_REJECT <op-
 128    tional reason for rejection> IAC SE
 129
 130       This command indicates that the credential forwarding was not suc-
 131       cessful, and if there is any more data in the sub-option, it is an
 132       ASCII text message of the reason for the rejection.
 133
 134 3.  Implementation Rules
 135
 136    If the second octet of the authentication-type-pair has the AUTH_WHO
 137    bit set to AUTH_CLIENT_TO_SERVER, then the client sends the initial
 138    AUTH command, and the server responds with either ACCEPT or REJECT.
 139    In addition, if the AUTH_HOW bit is set to AUTH_HOW_MUTUAL, the serv-
 140    er will send a RESPONSE before it sends the ACCEPT.
 141
 142    If the second octet of the authentication-type-pair has the AUTH_WHO
 143    bit set to AUTH_SERVER_TO_CLIENT, then the server sends the initial
 144    AUTH command, and the client responds with either ACCEPT or REJECT.
 145    In addition, if the AUTH_HOW bit is set to AUTH_HOW_MUTUAL, the
 146    client will send a RESPONSE before it sends the ACCEPT.
 147
 148    The Kerberos principal used by the server will generally be of the
 149    form "host/<hostname>@realm".  That is, the first component of the
 150    Kerberos principal is "host"; the second component is the fully qual-
 151    ified lower-case hostname of the server; and the realm is the Ker-
 152    beros realm to which the server belongs.
 153
 154                            Expires March 2000                   [Page 3]
 155
 156 Internet-Draft        Kerberos Version 5 for Telnet       September 1999
 157
 158    Any Telnet IAC characters that occur in the KRB_AP_REQ or KRB_AP_REP
 159    messages, the KRB_CRED structure, or the optional rejection text
 160    string must be doubled as specified in [4].  Otherwise the following
 161    byte might be mis-interpreted as a Telnet command.
 162
 163 4.  Examples
 164
 165    User "joe" may wish to log in as user "pete" on machine "foo".  If
 166    "pete" has set things up on "foo" to allow "joe" access to his ac-
 167    count, then the client would send IAC SB AUTHENTICATION NAME "pete"
 168    IAC SE IAC SB AUTHENTICATION IS KERBEROS_V5 AUTH <KRB_AP_REQ_MESSAGE>
 169    IAC SE
 170
 171    The server would then authenticate the user as "joe" from the
 172    KRB_AP_REQ_MESSAGE, and if the KRB_AP_REQ_MESSAGE was accepted by
 173    Kerberos, and if "pete" has allowed "joe" to use his account, the
 174    server would then continue the authentication sequence by sending a
 175    RESPONSE (to do mutual authentication, if it was requested) followed
 176    by the ACCEPT.
 177
 178    If forwarding has been requested, the client then sends IAC SB AU-
 179    THENTICATION IS KERBEROS_V5 CLIENT|MUTUAL FORWARD <KRB_CRED structure
 180    with credentials to be forwarded> IAC SE.  If the server succeeds in
 181    reading the forwarded credentials, the server sends FORWARD_ACCEPT
 182    else, a FORWARD_REJECT is sent back.
 183
 184        Client                           Server
 185                                         IAC DO AUTHENTICATION
 186        IAC WILL AUTHENTICATION
 187
 188        [ The server is now free to request authentication information.
 189          ]
 190
 191                                         IAC SB AUTHENTICATION SEND
 192                                         KERBEROS_V5 CLIENT|MUTUAL
 193                                         KERBEROS_V5 CLIENT|ONE_WAY IAC
 194                                         SE
 195
 196        [ The server has requested mutual Version 5 Kerberos
 197          authentication.  If mutual authentication is not supported,
 198          then the server is willing to do one-way authentication.
 199
 200          The client will now respond with the name of the user that it
 201          wants to log in as, and the Kerberos ticket.  ]
 202
 203        IAC SB AUTHENTICATION NAME
 204        "pete" IAC SE
 205        IAC SB AUTHENTICATION IS
 206        KERBEROS_V5 CLIENT|MUTUAL AUTH
 207        <KRB_AP_REQ message> IAC SE
 208
 209                            Expires March 2000                   [Page 4]
 210
 211 Internet-Draft        Kerberos Version 5 for Telnet       September 1999
 212
 213        [ Since mutual authentication is desired, the server sends across
 214          a RESPONSE to prove that it really is the right server.  ]
 215
 216                                         IAC SB AUTHENTICATION REPLY
 217                                         KERBEROS_V5 CLIENT|MUTUAL
 218                                         RESPONSE <KRB_AP_REP message>
 219                                         IAC SE
 220
 221        [ The server responds with an ACCEPT command to state that the
 222          authentication was successful.  ]
 223
 224                                         IAC SB AUTHENTICATION REPLY KER-
 225                                         BEROS_V5 CLIENT|MUTUAL ACCEPT
 226                                         IAC SE
 227
 228        [ If so requested, the client now sends the FORWARD command to
 229          forward credentials to the remote site.  ]
 230
 231        IAC SB AUTHENTICATION IS KER-
 232        BEROS_V5 CLIENT|MUTUAL
 233        FORWARD <KRB_CRED message> IAC
 234        SE
 235
 236        [ The server responds with a FORWARD_ACCEPT command to state that
 237          the credential forwarding was successful.  ]
 238
 239                            Expires March 2000                   [Page 5]
 240
 241 Internet-Draft        Kerberos Version 5 for Telnet       September 1999
 242
 243                                         IAC SB AUTHENTICATION REPLY KER-
 244                                         BEROS_V5 CLIENT|MUTUAL FOR-
 245                                         WARD_ACCEPT IAC SE
 246
 247 5. Security Considerations
 248
 249    The selection of the random session key in the Kerberos V5 authenti-
 250    cator is critical, since this key will be used for encrypting the
 251    telnet data stream if encryption is enabled.  It is strongly advised
 252    that the random key selection be done using cryptographic techniques
 253    that involve the Kerberos ticket's session key.  For example, using
 254    the current time, encrypting it with the ticket session key, and then
 255    correcting for key parity is a strong way to generate a subsession
 256    key, since the ticket session key is assumed to be never disclosed to
 257    an attacker.
 258
 259    Care should be taken before forwarding a user's Kerberos credentials
 260    to the remote server.  If the remote server is not trustworthy, this
 261    could result in the user's credentials being compromised.  Hence, the
 262    user interface should not forward credentials by default; it would be
 263    far safer to either require the user to explicitly request creden-
 264    tials forwarding for each connection, or to have a trusted list of
 265    hosts for which credentials forwarding is enabled, but to not enable
 266    credentials forwarding by default for all machines.
 267
 268 6. Acknowledgments
 269
 270    This document was originally written by Dave Borman of Cray Research,
 271    Inc.  Theodore Ts'o of MIT revised it to reflect the latest implemen-
 272    tation experience.  Cliff Neuman and Prasad Upasani of USC's Informa-
 273    tion Sciences Institute developed the credential forwarding support.
 274
 275    In addition, the contributions of the Telnet Working Group are also
 276    gratefully acknowledged.
 277
 278 7. References
 279
 280    [1] Kohl, J. and B. Neuman, "The Kerberos Network Authentication Sys-
 281        tem (V5)", RFC 1510, USC/Information Sciences Institute, Septem-
 282        ber 1993.
 283
 284    [2] Internet Engineering Task Force, "Telnet Authentication", draft-
 285        tso-telnet-auth-enc-04.txt, T. Ts'o, Editor, VA Linux Systems,
 286        September 1999.
 287
 288    [3] Internet Engineering Task Force, "Telnet Data Encryption Option",
 289        draft-tso-telnet-encryption-04.txt, T. Ts'o, Editor, VA Linux
 290        Systems, September 1999.
 291
 292    [4] Postel, J.B. and J. Reynolds, "Telnet Option Specifications", RFC
 293
 294                            Expires March 2000                   [Page 6]
 295
 296 Internet-Draft        Kerberos Version 5 for Telnet       September 1999
 297
 298        855, STD 8, USC/Information Sciences Institute, May 1983.
 299
 300 Editor's Address
 301
 302    Theodore Ts'o
 303    Massachusetts Institute of Technology
 304    MIT Room E40-343
 305    77 Massachusetts Avenue
 306    Cambridge, MA 02139
 307
 308    Phone: (617) 253-8091
 309    EMail: tytso@mit.edu
 310
 311                            Expires March 2000                   [Page 7]