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