doc: Add RFC documents

1 files changed, 395 insertions, 0 deletions

diff --git a/doc/rfc/rfc2942.txt b/doc/rfc/rfc2942.txt
new file mode 100644
index 0000000..3b50448
--- /dev/null
+++ b/doc/rfc/rfc2942.txt
@@ -0,0 +1,395 @@
+
+
+
+
+
+
+Network Working Group                                            T. Ts'o
+Request for Comments: 2942                              VA Linux Systems
+Category: Standards Track                                 September 2000
+
+
+               Telnet Authentication: Kerberos Version 5
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2000).  All Rights Reserved.
+
+Abstract
+
+   This document describes how Kerberos Version 5 [1] is used with the
+   telnet protocol.   It describes an telnet authentication suboption to
+   be used with the telnet authentication option [2].   This mechanism
+   can also used to provide keying material to provide data
+   confidentiality services in conjunction with the telnet encryption
+   option [3].
+
+1. Command Names and Codes
+
+      Authentication Types
+
+         KERBEROS_V5    2
+
+      Sub-option Commands
+
+         AUTH               0
+         REJECT             1
+         ACCEPT             2
+         RESPONSE           3
+         FORWARD            4
+         FORWARD_ACCEPT     5
+         FORWARD_REJECT     6
+
+
+
+
+
+
+
+
+Ts'o                        Standards Track                     [Page 1]
+
+RFC 2942       Telnet Authentication: Kerberos Version 5  September 2000
+
+
+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
+      <authentication-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 correctly negotiated.  The Kerberos V5 authenticator
+      must also include the optional subkey field, which shall be filled
+      in with a randomly chosen key.  This key shall be used for
+      encryption purposes if encryption is negotiated, and shall be used
+      as the negotiated 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
+      authentication-type-pair, the RESPONSE command must be sent before
+      the ACCEPT command is sent.
+
+   IAC SB AUTHENTICATION REPLY <authentication-type-pair> REJECT
+      <optional 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
+
+      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.
+
+
+
+
+Ts'o                        Standards Track                     [Page 2]
+
+RFC 2942       Telnet Authentication: Kerberos Version 5  September 2000
+
+
+   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
+      exchanged 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
+      successful.
+
+   IAC SB AUTHENTICATION <authentication-type-pair> FORWARD_REJECT
+      <optional reason for rejection> IAC SE
+
+      This command indicates that the credential forwarding was not
+      successful, and if there is any more data in the suboption, 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
+   server 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
+   qualified lower-case hostname of the server; and the realm is the
+   Kerberos realm to which the server belongs.
+
+   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.
+
+
+
+
+Ts'o                        Standards Track                     [Page 3]
+
+RFC 2942       Telnet Authentication: Kerberos Version 5  September 2000
+
+
+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
+   account, 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
+   AUTHENTICATION 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
+
+       [ Since mutual authentication is desired, the server sends across
+         a RESPONSE to prove that it really is the right server.  ]
+
+
+
+Ts'o                        Standards Track                     [Page 4]
+
+RFC 2942       Telnet Authentication: Kerberos Version 5  September 2000
+
+
+                                        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
+                                        KERBEROS_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.  ]
+
+                                        IAC SB AUTHENTICATION REPLY
+                                        KERBEROS_V5 CLIENT|MUTUAL
+                                        FORWARD_ACCEPT IAC SE
+
+5. Security Considerations
+
+   The selection of the random session key in the Kerberos V5
+   authenticator 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
+   credentials 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.
+
+
+
+
+Ts'o                        Standards Track                     [Page 5]
+
+RFC 2942       Telnet Authentication: Kerberos Version 5  September 2000
+
+
+   The IAC SB AUTHENTICATION NAME name IAC SE message is unprotected in
+   this protocol.  Its contents should be verified by a secure method
+   after authentication completes before it is used.
+
+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
+   implementation experience.  Cliff Neuman and Prasad Upasani of USC's
+   Information 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
+       System (V5)", RFC 1510, September 1993.
+
+   [2] Ts'o, T. and J. Altman, "Telnet Authentication Option", RFC 2941,
+       September 2000.
+
+   [3] Ts'o, T., "Telnet Data Encryption Option", RFC 2946, September
+       2000.
+
+   [4] Postel, J. and J. Reynolds, "Telnet Option Specifications", STD
+       8, RFC 855, May 1983.
+
+9. Editor's Address
+
+   Theodore Ts'o
+   VA Linux Systems
+   43 Pleasant St.
+   Medford, MA 02155
+
+   Phone: (781) 391-3464
+   EMail: tytso@mit.edu
+
+
+
+
+
+Ts'o                        Standards Track                     [Page 6]
+
+RFC 2942       Telnet Authentication: Kerberos Version 5  September 2000
+
+
+10. Full Copyright Statement
+
+   Copyright (C) The Internet Society (2000).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ts'o                        Standards Track                     [Page 7]
+