diff options
Diffstat (limited to 'third_party/heimdal/doc/standardisation/draft-tso-telnet-krb5-04.txt')
| -rw-r--r-- | third_party/heimdal/doc/standardisation/draft-tso-telnet-krb5-04.txt | 327 |
1 files changed, 327 insertions, 0 deletions
diff --git a/third_party/heimdal/doc/standardisation/draft-tso-telnet-krb5-04.txt b/third_party/heimdal/doc/standardisation/draft-tso-telnet-krb5-04.txt new file mode 100644 index 00000000000..e9611e395bf --- /dev/null +++ b/third_party/heimdal/doc/standardisation/draft-tso-telnet-krb5-04.txt @@ -0,0 +1,327 @@ +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 + + |