idnits 2.17.1 draft-ietf-aft-socks-gssapi-revisions-01.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. 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. == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 7 pages 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. == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 249: '...en conf_req_flag MUST always be FALSE;...' RFC 2119 keyword, line 250: '...hen conf_req_flag MUST always be TRUE....' == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. -- The draft header indicates that this document updates RFC1961, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- (Using the creation date from RFC1961, updated by this document, for RFC5378 checks: 1995-03-27) -- 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 (24 December 1999) is 8887 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) == Missing Reference: 'RFC 2479' is mentioned on line 164, but not defined == Unused Reference: 'RFC 1961' is defined on line 283, but no explicit reference was found in the text == Unused Reference: 'SOCKS V5' is defined on line 286, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2078 (Obsoleted by RFC 2743) ** Obsolete normative reference: RFC 2478 (Obsoleted by RFC 4178) Summary: 8 errors (**), 0 flaws (~~), 7 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet-Draft D. Miller 2 Updates: RFC 1961 CyberSafe, Inc. 3 24 June 1999 4 Expires 24 December 1999 6 GSS-API Authentication Method for SOCKS Version 5 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC 2026. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that other 15 groups may also distribute working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six 18 months and may be updated, replaced, or obsoleted by other documents 19 at any time. It is inappropriate to use Internet-Drafts as reference 20 material or to cite them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 Comments on this document should be sent to "aft@socks.nec.com", 29 the IETF Authenticated Firewall Traversal WG discussion list. 30 Distribution of this document is unlimited. 32 1. Abstract 34 The protocol specification for SOCKS Version 5 specifies a 35 generalized framework for the use of arbitrary authentication 36 protocols in the initial SOCKS connection setup. This document 37 provides the specification for the SOCKS V5 GSS-API authentication 38 protocol, and in particular, the use of the Simple and Protected GSS 39 API Negotiation (SPNEGO) mechanism. Use of the SPNEGO pseudo- 40 mechanism is intended to maximize the chance of agreement of a 41 security mechanism, and hence maximize interoperability. A message 42 protection subnegotiation protocol is also specified, allowing peers 43 to agree on which message protection services GSS-API encapsulated 44 messages will be protected with: integrity, or integrity and 45 confidentiality. Other GSS-API security services, normally optional 46 with GSS-API, are specified for use with SOCKS 5. 48 2. Introduction 50 Version 2 of the GSS-API, defined in [RFC 2078] and [draft-ietf- 51 cat-gssv2-cbind-09.txt] provides an abstract interface which provides 52 security services for use in distributed applications, but isolates 53 callers from specific security mechanisms and implementations. 55 The approach for use of GSS-API and SPNEGO in SOCKS V5 is to 56 authenticate the client and server by successfully negotiating a 57 common GSS-API mechanism and establishing a GSS-API security context - 58 such that the GSS-API encapsulates any negotiation protocol for 59 mechanism selection, and the agreement of security service options. 61 The SPNEGO mechanism defined in [RFC 2478] is a pseudo-security 62 mechanism which enables GSS-API peers to determine in-band whether 63 their credentials share common GSS-API security mechanism(s), and if 64 so, to invoke normal security context establishment for a common 65 security mechanism. The SPNEGO mechanism also allows the client to 66 select a preferred mechanism, in a process referred to as optimistic 67 negotiation, which eliminates extra negotiation round-trips in cases 68 where the initiator and acceptor have the same preferred mechanism. 69 This specification requires implementations to support the SPNEGO 70 mechanism. 72 The GSS-API enables the context initiator to know what security 73 services the target supports for the chosen mechanism. GSS-API 74 mechanisms support message integrity. In addition to this, other 75 optional services may be offered. These include message 76 confidentiality, credential delegation, mutual authentication, replay 77 detection, out-of-sequence detection, anonymous authentication, 78 context transfer, and the use of incomplete contexts. As outlined 79 later in this document, for successful context establishment, the 80 following optional services are to be requested, with receipt of each 81 service confirmed: credential delegation, mutual authentication, 82 replay detection, and out-of-sequence detection. Those services are 83 established as part of the security context establishment process 84 proper. After context establishment, messages may either be protected 85 for confidentiality or not, depending upon the input to the gss_wrap 86 call. Message protection subnegotiation is the process whereby it is 87 determined if message confidentiality is to be provided for the SOCKS 88 session. 90 The GSS-API per-message protection calls gss_wrap and gss_unwrap 91 are subsequently used to encapsulate any further TCP and UDP traffic 92 between client and server. 94 3. Framing 96 The caller-opaque context establishment and per-message tokens 97 produced by calls to the GSS-API are exchanged between client and 98 server in the following format: 100 +---------+---------+---------+.......................+ 101 + ver | mtyp | len | token | 102 +---------+---------+---------+.......................+ 104 Where: 106 - "ver" is a single octet field representing the protocol version 107 number, here 2 to represent the second version of the SOCKS/GSS-API 108 Protocol. 110 - "mtyp" is a single octet field representing the message type, 111 which may contain the following values: 112 0x01 - authentication message 113 0x02 - message protection subnegotiation message 114 0x03 - encapsulated user data 116 - "len" is a two octet field representing the length of the "token" 117 field in octets. 119 - "token" is the opaque context establishment or per-message token 120 emitted by the GSS-API, up to 2^16-1 octets in length. 122 4. SPNEGO Security Mechanism Negotiation 124 In order to effect SPNEGO, the client must specify SPNEGO as the 125 mech_type parameter in its call to gss_init_sec_context. The OID for 126 SPNEGO is iso.org.dod.internet.security.mechanism.snego 127 (1.3.6.1.5.5.2). 129 The SPNEGO mechanism allows the client to optionally include a 130 context establishment token for the preferred mechanism within the 131 negotiation token, a process referred to as optimistic negotiation. 132 If the client and server both support the same preferred mechanism, 133 the negotiation and context establishment exchanges can occur 134 simultaneously as described in [RFC 2479]. The SOCKS client side 135 should use optimistic negotiation in order to maximize the efficiency 136 of the connection to the SOCKS server. 138 Assuming optimistic negotiation is attempted, the client must 139 specify use of the following security context options via the 140 req_flags parameter in gss_init_sec_context: mutual authentication, 141 credential delegation, replay detection, and out-of-sequence 142 detection. The flags to include in the req_flags parameter that will 143 request these service options are GSS_C_MUTUAL_FLAG, GSS_C_DELEG_FLAG, 144 GSS_C_REPLAY_FLAG, and GSS_C_SEQUENCE_FLAG. GSS_C_SEQUENCE_FLAG should 145 only be passed in for TCP-based clients, not for UDP-based clients. 146 The client may optionally include GSS_C_CONF_FLAG or GSS_C_INTEG_FLAG 147 into req_flags to request confidentiality and integrity services. 149 The negotiation tokens emitted by the GSS-API are exchanged between 150 the client and server framed as described in section 3 with mtyp equal 151 to 0x01. 153 Following the exchange of negotiation tokens and encapsulated 154 mechanism tokens, and the successful establishment of a security 155 context for the preferred mechanism as described in [RFC 2479], the 156 client and server may proceed to the message protection subnegotation 157 stage provided that confidentiality and integrity services are 158 available for the context (i.e. that GSS_C_CONF_FLAG and 159 GSS_C_INTEG_FLAG were returned in the ret_flags parameter of 160 gss_init_sec_context and gss_accept_sec_context) 161 If the client implementation does not have a preferred mechanism, 162 or if the client and server do not support the same preferred 163 mechanism, then the negotiation of a common security mechanism 164 proceeds as defined in [RFC 2479]. 166 If the client and server fail to agree on a common security 167 mechanism, then the client must close the connection. 169 5. GSS-API Security Context Establishment 171 Clients which do not support a preferred mechanism, or clients whose 172 preferred mechanisms were different than that of their peers, and 173 which therefore were unable to perform optimistic negotiation 174 (simultaneous negotiation and context establishment) must proceed to 175 establish a security context with the negotiated mechanism. The 176 client should proceed with security context establishment as defined 177 in [RFC 2078]. In this case the negotiated mechanisms OID is used as 178 the mech_type parameter in gss_init_sec_context. The same security 179 context options used in section 4 should continue to be used. 181 6. GSS-API Protection-level Options 183 6.1 Message protection 185 Establishment of a GSS-API security context enables communicating 186 peers to determine which per-message protection services are available 187 to them. This is accomplished by inspecting the 188 gss_init_sec_context and gss_accept_sec_context ret_flags 189 parameters for the presence of the GSS_C_INTEG_FLAG and 190 GSS_C_CONF_FLAG, which respectively indicate message integrity and 191 confidentiality services are available. Note that while the indicated 192 services are available, confidentiality, which is an optional service, 193 is only applied if the appropriate flag is passed in to gss_wrap. 195 It is necessary to ensure that the message protection applied to 196 the traffic is appropriate to the sensitivity of the data, and the 197 severity of the threats. Not all message traffic needs to be 198 protected for confidentiality, and avoiding this will make 199 communications more efficient. 201 6.2 Message Protection Subnegotiation 203 For TCP and UDP clients and servers, different levels of protection 204 are possible in the SOCKS V5 protocol, so an additional subnegotiation 205 stage is needed to agree the message protection level. While this 206 negotiation is part of neither SPNEGO nor GSS-API, its presence serves 207 to increase interoperability between clients and servers that have 208 differing but flexible message protection policies. 210 After successful completion of this subnegotiation, TCP and UDP 211 clients and servers use GSS-API encapsulation as defined in section 7. 213 After successful establishment of a GSS-API security context, the 214 client's GSS-API implementation sends its required security context 215 protection level to the server. The server then returns the security 216 context protection level which it agrees to - which may or may not 217 take the client's request into account. The security context 218 protection level sent by client and server must be one of the 219 following single-octet values: 221 0x01 - integrity-protected user data 222 0x02 - integrity-confidentiality-protected user data 224 The security context protection level is sent from client to server 225 and vice versa framed as described in section 3 with an mtyp of 0x02. 227 6.3 Message Protection Subnegotiation Message Generation 229 The message protection subnegotiation message is a standard GSS-API 230 message, and hence its processing results in a GSS-API token. The 231 token is produced by encapsulating an octet containing the required 232 protection level using gss_wrap with conf_req set to FALSE. The token 233 is verified using gss_unwrap. If the server's choice of protection 234 level is unacceptable to the client, then the client must close its 235 connection to the server. 237 7. GSS-API Per-message Protection 239 For TCP and UDP clients and servers, the GSS-API functions for 240 encapsulation and de-encapsulation shall be used by implementations, 241 which are gss_wrap and gss_unwrap. (Note that the other GSS-API 242 message protection functions, gss_get_mic and gss_verify_mic, do not 243 encapsulate their messages, nor can they provide message 244 confidentiality.) 246 When invoking gss_wrap and gss_unwrap, the default value of quality 247 of protection shall be specified, and the use of conf_req_flag shall 248 be as determined by the previous subnegotiation step. If protection 249 level 1 is agreed then conf_req_flag MUST always be FALSE; if 250 protection level 2 is agreed then conf_req_flag MUST always be TRUE. 252 All encapsulated messages are prefixed by the framing defined in 253 section 3 with mtyp equal to 0x03. 255 8. GSS-API Security Context Termination 257 The GSS-API context termination message (emitted by 258 gss_delete_sec_context) is not used by this protocol. When the 259 connection is closed, each peer invokes gss_delete_sec_context passing 260 GSS_C_NO_BUFFER as the value of the output_token argument. This 261 suppresses production of the context termination message. 263 9. Open Issues 265 The viability of GSS-API authentication for the SOCKS protocol 267 needs to be reconciled with the current SOCKS mechanism negotiation 268 scheme. That negotiation mechanism is unprotected. 270 The framing of socks protocol messages within the framing format 271 described in this specification should be defined further. 273 Message protection subnegotiation might be unnecessary. Messages 274 could be wrapped with the sender's choice of QOP and conf_req_flag 275 values, as they are with other applications using GSS-API. Any such 276 messages unacceptable to the recipient may be rejected, or the session 277 may be terminated. The protection level evident by inspecting the 278 context structures after security context establishment may 279 effectively provide the subnegotiation discussed in this draft. 281 10. References 283 [RFC 1961] McMahon, P., "GSS-API Authentication Method for SOCKS 284 Version 5", June 1996. 286 [SOCKS V5] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D., 287 and L. Jones, "SOCKS Protocol V5", RFC 1928, April 1996. 289 [RFC 2078] Linn, J., "Generic Security Service API, Version 2", 290 January 1997. 292 [RFC 2478] Baize, E., Pinkas, D., "The Simple and Protected GSS-API 293 Negotiation Mechanism," December, 1998 295 [draft-ietf-cat-gssv2-cbind-09.txt] Wray, J., "Generic Security 296 Service API Version 2 : C-bindings", November 10, 1998. 298 11. Acknowledgment 300 The original document from which this document is derived is RFC 301 1961, written by P. McMahon, ICL. The first revisions document was 302 written by David Margrave, CyberSafe Corporation. The revisions 303 documents reflect input from the AFT WG. 305 12. Security Considerations 307 The protection features of SPNEGO require that all mechanisms 308 proposed during the negotiation exchange support integrity services. 309 If a single mechanism in the list does not support integrity, then the 310 negotiation is subject to a downgrade attack. 312 The security services provided through the GSS-API are entirely 313 dependent on the effectiveness of the underlying security mechanisms, 314 and the correctness of the implementation of the underlying algorithms 315 and protocols. 317 The user of a GSS-API service must ensure that the quality of 318 protection provided by the mechanism implementation is consistent with 319 their security policy. 321 In addition, where negotiation is supported under the GSS-API, 322 constraints on acceptable mechanisms may be imposed to ensure 323 suitability for application to authenticated firewall traversal. 325 13. Author's Address 327 David Miller 328 CyberSafe Corporation 329 1605 NW Sammamish Road, Suite 310 330 Issaquah, Washington 98027 USA 332 Email: david.miller@cybersafe.com 333 Phone: (425) 391-6000 334 Fax: (425) 391-0508 336 Document expires 24 December 1999