diff options
Diffstat (limited to 'crypto/heimdal/doc/standardisation/draft-tso-telnet-krb5-04.txt')
| -rw-r--r-- | crypto/heimdal/doc/standardisation/draft-tso-telnet-krb5-04.txt | 327 |
1 files changed, 0 insertions, 327 deletions
diff --git a/crypto/heimdal/doc/standardisation/draft-tso-telnet-krb5-04.txt b/crypto/heimdal/doc/standardisation/draft-tso-telnet-krb5-04.txt deleted file mode 100644 index e9611e395bfd..000000000000 --- a/crypto/heimdal/doc/standardisation/draft-tso-telnet-krb5-04.txt +++ /dev/null @@ -1,327 +0,0 @@ -Network Working Group T. Ts'o, Editor -Internet-Draft Massachusetts Institute of Technology -draft-tso-telnet-krb5-04.txt April 2000 - - Telnet Authentication: Kerberos Version 5 - -Status of this Memo - - This document is an Internet-Draft and is in full conformance with - all provisions of Section 10 of RFC2026. Internet-Drafts are working - documents of the Internet Engineering Task Force (IETF), its areas, - and its working groups. Note that other groups may also distribute - working documents as Internet-Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference mate- - rial or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in RFC 2119. - -0. Abstract - - This document describes how Kerberos Version 5 [1] is used with the - telnet protocol. It describes an telnet authentication sub-option - to be used with the telnet authentication option [2]. This mecha- - nism can also used to provide keying material to provide data confi- - dentiality services in conjuction with the telnet encryption option - [3]. - -1. Command Names and Codes - - Authentication Types - - KERBEROS_V5 2 - - Sub-option Commands - - Expires Sept 2000 [Page 1] - -Internet-Draft Kerberos Version 5 for Telnet April 2000 - - AUTH 0 - REJECT 1 - ACCEPT 2 - RESPONSE 3 - FORWARD 4 - FORWARD_ACCEPT 5 - FORWARD_REJECT 6 - -2. Command Meanings - - IAC SB AUTHENTICATION IS <authentication-type-pair> AUTH <Kerberos V5 - KRB_AP_REQ message> IAC SE - - This is used to pass the Kerberos V5 [1] KRB_AP_REQ message to the - remote side of the connection. The first octet of the <authenti- - cation-type-pair> value is KERBEROS_V5, to indicate that Version 5 - of Kerberos is being used. The Kerberos V5 authenticator in the - KRB_AP_REQ message must contain a Kerberos V5 checksum of the - two-byte authentication type pair. This checksum must be verified - by the server to assure that the authentication type pair was cor- - rectly negotiated. The Kerberos V5 authenticator must also in- - clude the optional subkey field, which shall be filled in with a - randomly chosen key. This key shall be used for encryption pur- - poses if encryption is negotiated, and shall be used as the nego- - tiated session key (i.e., used as keyid 0) for the purposes of the - telnet encryption option; if the subkey is not filled in, then the - ticket session key will be used instead. - - If data confidentiality services is desired the ENCRYPT_US- - ING_TELOPT flag must be set in the authentication-type-pair as - specified in [2]. - - IAC SB AUTHENTICATION REPLY <authentication-type-pair> ACCEPT IAC SE - - This command indicates that the authentication was successful. - - If the AUTH_HOW_MUTUAL bit is set in the second octet of the au- - thentication-type-pair, the RESPONSE command must be sent before - the ACCEPT command is sent. - - IAC SB AUTHENTICATION REPLY <authentication-type-pair> REJECT <op- - tional reason for rejection> IAC SE - - This command indicates that the authentication was not successful, - and if there is any more data in the sub-option, it is an ASCII - text message of the reason for the rejection. - - IAC SB AUTHENTICATION REPLY <authentication-type-pair> RESPONSE - <KRB_AP_REP message> IAC SE - - Expires Sept 2000 [Page 2] - -Internet-Draft Kerberos Version 5 for Telnet April 2000 - - This command is used to perform mutual authentication. It is only - used when the AUTH_HOW_MUTUAL bit is set in the second octet of - the authentication-type-pair. After an AUTH command is verified, - a RESPONSE command is sent which contains a Kerberos V5 KRB_AP_REP - message to perform the mutual authentication. - - IAC SB AUTHENTICATION <authentication-type-pair> FORWARD <KRB_CRED - message> IAC SE - - This command is used to forward kerberos credentials for use by - the remote session. The credentials are passed as a Kerberos V5 - KRB_CRED message which includes, among other things, the forwarded - Kerberos ticket and a session key associated with the ticket. Part - of the KRB_CRED message is encrypted in the key previously ex- - changed for the telnet session by the AUTH suboption. - - IAC SB AUTHENTICATION <authentication-type-pair> FORWARD_ACCEPT IAC - SE - - This command indicates that the credential forwarding was success- - ful. - - IAC SB AUTHENTICATION <authentication-type-pair> FORWARD_REJECT <op- - tional reason for rejection> IAC SE - - This command indicates that the credential forwarding was not suc- - cessful, and if there is any more data in the sub-option, it is an - ASCII text message of the reason for the rejection. - -3. Implementation Rules - - If the second octet of the authentication-type-pair has the AUTH_WHO - bit set to AUTH_CLIENT_TO_SERVER, then the client sends the initial - AUTH command, and the server responds with either ACCEPT or REJECT. - In addition, if the AUTH_HOW bit is set to AUTH_HOW_MUTUAL, the serv- - er will send a RESPONSE before it sends the ACCEPT. - - If the second octet of the authentication-type-pair has the AUTH_WHO - bit set to AUTH_SERVER_TO_CLIENT, then the server sends the initial - AUTH command, and the client responds with either ACCEPT or REJECT. - In addition, if the AUTH_HOW bit is set to AUTH_HOW_MUTUAL, the - client will send a RESPONSE before it sends the ACCEPT. - - The Kerberos principal used by the server will generally be of the - form "host/<hostname>@realm". That is, the first component of the - Kerberos principal is "host"; the second component is the fully qual- - ified lower-case hostname of the server; and the realm is the Ker- - beros realm to which the server belongs. - - Expires Sept 2000 [Page 3] - -Internet-Draft Kerberos Version 5 for Telnet April 2000 - - Any Telnet IAC characters that occur in the KRB_AP_REQ or KRB_AP_REP - messages, the KRB_CRED structure, or the optional rejection text - string must be doubled as specified in [4]. Otherwise the following - byte might be mis-interpreted as a Telnet command. - -4. Examples - - User "joe" may wish to log in as user "pete" on machine "foo". If - "pete" has set things up on "foo" to allow "joe" access to his ac- - count, then the client would send IAC SB AUTHENTICATION NAME "pete" - IAC SE IAC SB AUTHENTICATION IS KERBEROS_V5 AUTH <KRB_AP_REQ_MESSAGE> - IAC SE - - The server would then authenticate the user as "joe" from the - KRB_AP_REQ_MESSAGE, and if the KRB_AP_REQ_MESSAGE was accepted by - Kerberos, and if "pete" has allowed "joe" to use his account, the - server would then continue the authentication sequence by sending a - RESPONSE (to do mutual authentication, if it was requested) followed - by the ACCEPT. - - If forwarding has been requested, the client then sends IAC SB AU- - THENTICATION IS KERBEROS_V5 CLIENT|MUTUAL FORWARD <KRB_CRED structure - with credentials to be forwarded> IAC SE. If the server succeeds in - reading the forwarded credentials, the server sends FORWARD_ACCEPT - else, a FORWARD_REJECT is sent back. - - Client Server - IAC DO AUTHENTICATION - IAC WILL AUTHENTICATION - - [ The server is now free to request authentication information. - ] - - IAC SB AUTHENTICATION SEND - KERBEROS_V5 CLIENT|MUTUAL - KERBEROS_V5 CLIENT|ONE_WAY IAC - SE - - [ The server has requested mutual Version 5 Kerberos - authentication. If mutual authentication is not supported, - then the server is willing to do one-way authentication. - - The client will now respond with the name of the user that it - wants to log in as, and the Kerberos ticket. ] - - IAC SB AUTHENTICATION NAME - "pete" IAC SE - IAC SB AUTHENTICATION IS - KERBEROS_V5 CLIENT|MUTUAL AUTH - <KRB_AP_REQ message> IAC SE - - Expires Sept 2000 [Page 4] - -Internet-Draft Kerberos Version 5 for Telnet April 2000 - - [ Since mutual authentication is desired, the server sends across - a RESPONSE to prove that it really is the right server. ] - - IAC SB AUTHENTICATION REPLY - KERBEROS_V5 CLIENT|MUTUAL - RESPONSE <KRB_AP_REP message> - IAC SE - - [ The server responds with an ACCEPT command to state that the - authentication was successful. ] - - IAC SB AUTHENTICATION REPLY KER- - BEROS_V5 CLIENT|MUTUAL ACCEPT - IAC SE - - [ If so requested, the client now sends the FORWARD command to - forward credentials to the remote site. ] - - IAC SB AUTHENTICATION IS KER- - BEROS_V5 CLIENT|MUTUAL - FORWARD <KRB_CRED message> IAC - SE - - [ The server responds with a FORWARD_ACCEPT command to state that - the credential forwarding was successful. ] - - Expires Sept 2000 [Page 5] - -Internet-Draft Kerberos Version 5 for Telnet April 2000 - - IAC SB AUTHENTICATION REPLY KER- - BEROS_V5 CLIENT|MUTUAL FOR- - WARD_ACCEPT IAC SE - -5. Security Considerations - - The selection of the random session key in the Kerberos V5 authenti- - cator is critical, since this key will be used for encrypting the - telnet data stream if encryption is enabled. It is strongly advised - that the random key selection be done using cryptographic techniques - that involve the Kerberos ticket's session key. For example, using - the current time, encrypting it with the ticket session key, and then - correcting for key parity is a strong way to generate a subsession - key, since the ticket session key is assumed to be never disclosed to - an attacker. - - Care should be taken before forwarding a user's Kerberos credentials - to the remote server. If the remote server is not trustworthy, this - could result in the user's credentials being compromised. Hence, the - user interface should not forward credentials by default; it would be - far safer to either require the user to explicitly request creden- - tials forwarding for each connection, or to have a trusted list of - hosts for which credentials forwarding is enabled, but to not enable - credentials forwarding by default for all machines. - -6. IANA Considerations - - The authentication type KERBEROS_V5 and its associated suboption values - are registered with IANA. Any suboption values used to extend - the protocol as described in this document must be registered - with IANA before use. IANA is instructed not to issue new suboption - values without submission of documentation of their use. - -7. Acknowledgments - - This document was originally written by Dave Borman of Cray Research, - Inc. Theodore Ts'o of MIT revised it to reflect the latest implemen- - tation experience. Cliff Neuman and Prasad Upasani of USC's Informa- - tion Sciences Institute developed the credential forwarding support. - - In addition, the contributions of the Telnet Working Group are also - gratefully acknowledged. - -8. References - - [1] Kohl, J. and B. Neuman, "The Kerberos Network Authentication Sys- - tem (V5)", RFC 1510, USC/Information Sciences Institute, Septem- - ber 1993. - - [2] Internet Engineering Task Force, "Telnet Authentication", draft- - tso-telnet-auth-enc-04.txt, T. Ts'o, Editor, VA Linux Systems, - April 2000. - - [3] Internet Engineering Task Force, "Telnet Data Encryption Option", - draft-tso-telnet-encryption-04.txt, T. Ts'o, Editor, VA Linux - Systems, April 2000. - - [4] Postel, J.B. and J. Reynolds, "Telnet Option Specifications", RFC - - Expires Sept 2000 [Page 6] - -Internet-Draft Kerberos Version 5 for Telnet April 2000 - - 855, STD 8, USC/Information Sciences Institute, May 1983. - -Editor's Address - - Theodore Ts'o - Massachusetts Institute of Technology - MIT Room E40-343 - 77 Massachusetts Avenue - Cambridge, MA 02139 - - Phone: (617) 253-8091 - EMail: tytso@mit.edu - - Expires Sept 2000 [Page 7] - - - Jeffrey Altman * Sr.Software Designer * Kermit-95 for Win32 and OS/2 - The Kermit Project * Columbia University - 612 West 115th St #716 * New York, NY * 10025 - http://www.kermit-project.org/k95.html * kermit-support@kermit-project.org - - |