idnits 2.17.1 draft-galvin-telnet-gssapi-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-27) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 1995) is 10514 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. '1' Summary: 8 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Galvin 3 INTERNET-DRAFT S. Murphy 4 draft-galvin-telnet-gssapi-00.txt D. Balenson 5 TIS 6 July 1995 8 Telnet Authentication and Encryption: GSSAPI Option 10 Status of this Memo 12 This document is an Internet Draft. Internet Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its Areas, 14 and its Working Groups. Note that other groups may also distribute 15 working documents as Internet Drafts. 17 Internet Drafts are valid for a maximum of six months and may be 18 updated, replaced, or obsoleted by other documents at any time. It 19 is inappropriate to use Internet Drafts as reference material or to 20 cite them other than as ``work in progress''. 22 To learn the current status of any Internet Draft, please check the 23 1id-abstracts.txt listing contained in one of the Internet Drafts 24 Shadow Directories on ds.internic.net (US East Coast), venera.isi.edu 25 (US West Coast), munnari.oz.au (Pacific Rim), or nic.nordu.net 26 (Europe). 28 Abstract 30 The Telnet Authentication and Encryption Option provides a framework 31 for the passing of authentication information through the TELNET 32 session. This document specifies how the Generic Security Service 33 Application Program Interface (GSSAPI) uses the framework to 34 establish the security services of authentication and integrity for a 35 Telnet session. 37 1. Introduction 39 The Telnet Authentication and Encryption Option provides a framework 40 for the passing of authentication information through the TELNET 41 session and provides a mechanism to enable encryption of the data 42 stream as a side effect of successful authentication. This document 43 specifies how the Generic Security Service Application Program 44 Interface (GSSAPI) [1] uses the framework to establish the security 45 services of authentication and integrity for a Telnet session. No 46 specification is included for the enabling of encryption. Quoting 47 from the GSSAPI specification: 49 The GSS-API per-message protection service primitives, as the 50 category name implies, are oriented to operation at the 51 granularity of protocol data units. They perform cryptographic 52 operations on the data units, transfer cryptographic control 53 information in tokens, and, in the case of GSS_Wrap(), encapsulate 54 the protected data unit. As such, these primitives are not 55 oriented to efficient data protection for stream-paradigm 56 protocols (e.g., Telnet) if cryptography must be applied on an 57 octet-by-octet basis. 59 However, work is proceeding in this area and this document will be 60 revised when it is complete. 62 This version of this specification restricts the negotiation to 63 client to server (as would be indicated by the use of the 64 AUTH_CLIENT_TO_SERVER modifier) and does not allow the use of any 65 modifiers. This latter restriction is not a deficiency since the 66 GSSAPI provides for all of the functionality supported by the 67 modifiers. 69 2. Specification 71 This specification makes reference to a "server" and a "client". For 72 the purposes of this document, the "server" is the side of the 73 connection that did the passive TCP open (TCP LISTEN state), and the 74 "client" is the side of the connection that did the active open. 76 To use the GSSAPI authentication type, there are two steps to be 77 completed by the client and server: negotiate the use of GSSAPI and 78 exchange tokens until the authentication is complete. The client 79 begins the authentication exchange by calling GSS_Init_Sec_Context. 80 If an output_token is returned, the token is sent to the server. 82 The server continues the authentication exchange by calling 83 GSS_Accept_Sec_Context using the received token as input_token. If 84 an output_token is returned, the token is sent to the client. 86 Both the client and server continue exchanging tokens as long as they 87 are returned by GS_Init_Sec_Context and GSS_Accept_Sec_Context, 88 respectively. Each of these calls will return either 89 GSS_S_CONTINUE_NEEDED or GSS_S_COMPLETE to their respective callers 90 indicating if they should expect another token or not, respectively. 91 If an unexpected token is received or an expected token is not 92 received, either the client or server may terminate the connection. 94 The following example illustrates the use of this authentication 95 type. 97 Client Server 99 IAC DO AUTH_ENCRYPT 100 IAC WILL AUTH_ENCRYPT 102 [ The server is now free to request authentication information. 103 ] 105 IAC SB AUTH_ENCRYPT SEND GSSAPI 106 IAC SE 108 [ The server has requested GSSAPI authentication. The client 109 should begin the authentication exchange by calling 110 GSS_Init_Sec_Context at this time. The output_token must then 111 be sent to the server. ] 113 IAC SB AUTH_ENCRYPT IS GSSAPI 114 IAC SE 116 [ The authentication-data is sent as a binary sequence of octets. 117 The server continues the authentication exchange by calling 118 GSS_Accept_Sec_Context with the received authentication-data as 119 the input_token. If an output_token is returned, it is sent to 120 the client. ] 122 IAC SB AUTH_ENCRYPT REPLY GSSAPI 123 IAC SE 125 [ The client calls GSS_Init_Sec_Context using the recieved 126 authentication-data as the input_token. If an output_token is 127 returned, the exchange is continued with the client sending 128 another "IAC SB AUTH_ENCRYPT IS ... IAC SE" command. When both 129 the client and the server receive GSS_S_COMPLETE return codes 130 and the last one of them to receive authentication-data from 131 the other is not returned an output_token, the authentication 132 exchange is complete. ] 134 3. Security Considerations 136 This document is about a negotiation to establish the use of an au- 137 thentication service. 139 4. References 141 [1] J. Linn. Generic Security Service Application Program Interface, 142 Version 2. Work in progress. 144 5. Authors' Address 146 Jim Galvin 147 Sandy Murphy 148 Dave Balenson 150 Trusted Information Systems 151 3060 Washington Road 152 Glenwood, MD 21738 154 Phone: 301.854.6889