Internet-Draft David Margrave Updates: RFC 1961 CyberSafe Corporation <draft-ietf-aft-socks-gssapi-revisions-00> 18 November 1998 Expires 18 May 1998 GSS-API Authentication Method for SOCKS Version 5 Status of this Memo This document is an Internet-Draft. 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 material or to cite them other than as `work in progress.' To learn the current status of any Internet-Draft, please check the `1id-abstracts.txt' listing contained in the Internet- Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). Comments on this document should be sent to "aft@socks.nec.com", the IETF Authenticated Firewall Traversal WG discussion list. Distribution of this document is unlimited. 1. Purpose The protocol specification for SOCKS Version 5 specifies a generalized framework for the use of arbitrary authentication protocols in the initial SOCKS connection setup. This document provides the specification for the SOCKS V5 GSS-API authentication protocol, the use of the Simple and Protected GSS-API Negotiation (SPNEGO) mechanism, and defines a GSS-API-based encapsulation for provision of integrity and optional confidentiality. 2. Introduction Version 2 of the GSS-API, defined in [RFC 2078] and [draft-ietf-cat- gssv2-cbind-08.txt] provides an abstract interface which provides security services for use in distributed applications, but isolates callers from specific security mechanisms and implementations. The approach for use of GSS-API and SPNEGO in SOCKS V5 is to Margrave Document Expiration: 18 May 1998 [Page 1]
draft-ietf-aft-socks-gssapi-revisions-00 18 November 1998 authenticate the client and server by successfully negotiating a common GSS-API mechanism and establishing a GSS-API security context - such that the GSS-API encapsulates any negotiation protocol for mechanism selection, and the agreement of security service options. The SPNEGO mechanism defined in [draft-ietf-cat-snego-09.txt] is a pseudo-security mechanism which enables GSS-API peers to determine in-band whether their credentials share common GSS-API security mechanism(s), and if so, to invoke normal security context establishment for a common security mechanism. The SPNEGO mechanism also allows the client to optionally implement a preferred mechanism, referred to as optimistic negotiation, which enables the elimination of extra negotiation round-trips in cases where the initiator and acceptor have the same preferred mechanism. This specification requires implementations to support the SPNEGO mechanism. The GSS-API enables the context initiator to know what security services the target supports for the chosen mechanism. The required level of protection is then agreed by message protection subnegotiation. The GSS-API per-message protection calls are subsequently used to encapsulate any further TCP and UDP traffic between client and server. 3 Framing The caller-opaque context establishment and per-message tokens produced by calls to the GSS-API are exchanged between client and server in the following format: +---------+---------+---------+.......................+ + ver | mtyp | len | token | +---------+---------+---------+.......................+ Where: - "ver" is a single octet field representing the protocol version number, here 2 to represent the second version of the SOCKS/GSS-API protocol - "mtyp" is a single octet field representing the message type, which may contain the following values: 0x01 - authentication message 0x02 - protection-level negotiation message 0x03 - encapulated user data - "len" is a two octet field representing the length of the "token" Margrave Document Expiration: 18 May 1998 [Page 2]
draft-ietf-aft-socks-gssapi-revisions-00 18 November 1998 field in octets. - "token" is the opaque context establishment or per-message token emitted by the GSS-API, up to 2^16-1 octets in length. 4.0 SPNEGO Security Mechanism Negotiation The SPNEGO mechanism allows the client to optionally include a context establishment token for the preferred mechanism within the negotiation token, referred to as optimistic negotiation. If the client and server both support the same preferred mechanism, the negotiation and context establishment exchanges can occur simultaneously as described in [draft-ietf-cat-snego-09]. The client must specify SPNEGO as the mech_type parameter, and must specify its requirements for replay protection, delegation, and sequence protection via the gss_init_sec_context req_flags parameter. It is required by this specification that the client always requests these service options (i.e. passes GSS_C_MUTUAL_FLAG | GSS_C_REPLAY_FLAG | GSS_C_DELEG_FLAG | GSS_C_SEQUENCE_FLAG into req_flags). However, GSS_C_SEQUENCE_FLAG should only be passed in for TCP-based clients, not for UDP-based clients. The client may optionally pass GSS_C_CONF_FLAG | GSS_C_INTEG_FLAG into req_flags to request confidentiality and integrity services. The negotiation tokens emitted by the GSS-API are exchanged between the client and server framed as described in section 3 with mtyp equal to 0x01. Following the exchange of negotiation tokens and encapsulated mechanism tokens, and the successful establishment of a security context for the preferred mechanism as described in [draft-ietf-cat- snego-09], the client and server may proceed to the message protection subnegotation stage provided that confidentiality and integrity services are available for the context (i.e. that GSS_C_CONF_FLAG and GSS_C_INTEG_FLAG were returned in the ret_flags parameter of gss_init_sec_context and gss_accept_sec_context) If the client implementation does not have a preferred mechanism, or if the client and server do not support the same preferred mechanism, then the negotiation of a common security mechanism proceeds as defined in [draft-ietf-cat-snego-09]. If the client and server fail to agree on a common security mechanism, then the client must close the connection. 5. GSS-API Security Context Establishment Margrave Document Expiration: 18 May 1998 [Page 3]
draft-ietf-aft-socks-gssapi-revisions-00 18 November 1998 Clients which do not support a preferred mechanism and which therefore were unable to perform optimistic negotiation (simultaneous negotiation and context establishment) must proceed to establish a security context with the negotiated mechanism. The client should proceed with security context establishment as defined in [RFC 2078]. The client must specify the negotiated mechanism as the mech_type parameter, and must specify its requirements for replay protection, delegation, and sequence protection via the gss_init_sec_context req_flags parameter. It is required by this specification that the client always requests these service options (i.e. passes GSS_C_MUTUAL_FLAG | GSS_C_REPLAY_FLAG | GSS_C_DELEG_FLAG | GSS_C_SEQUENCE_FLAG into req_flags). However, GSS_C_SEQUENCE_FLAG should only be passed in for TCP-based clients, not for UDP-based clients. The client may optionally pass GSS_C_CONF_FLAG | GSS_C_INTEG_FLAG into req_flags to request confidentiality and integrity services. The context establishment tokens emitted by the GSS-API are exchanged between the client and server framed as described in section 3 with mtyp equal to 0x01. 6. GSS-API Protection-level Options 6.1 Message protection Establishment of a GSS-API security context enables comunicating peers to determine which per-message protection services are available to them through the gss_init_sec_context() and gss_accept_sec_context() ret_flags GSS_C_INTEG_FLAG and GSS_C_CONF_FLAG which respectively indicate message integrity and confidentiality services. It is necessary to ensure that the message protection applied to the traffic is appropriate to the sensitivity of the data, and the severity of the threats. 6.2 Message Protection Subnegotiation For TCP and UDP clients and servers, different levels of protection are possible in the SOCKS V5 protocol, so an additional subnegotiation stage is needed to agree the message protection level. After successful completion of this subnegotiation, TCP and UDP clients and servers use GSS-API encapsulation as defined in section 7. Margrave Document Expiration: 18 May 1998 [Page 4]
draft-ietf-aft-socks-gssapi-revisions-00 18 November 1998 After successful establishment of a GSS-API security context, the client's GSS-API implementation sends its required security context protection level to the server. The server then returns the security context protection level which it agrees to - which may or may not take the the client's request into account. The security context protection level sent by client and server must be one of the following single-octet values: 0x01 required per-message integrity 0x02 required per-message integrity and confidentiality 0x03 selective per-message integrity or confidentiality based on local client and server configurations It is anticipated that most implementations will agree on level 1 or 2 due to the practical difficulties in applying selective controls to messages passed through a socks library. The security context protection level is sent from client to server and vice versa framed as described in section 3 with an mtyp of 0x02 6.3 Message Protection Subnegotiation Message Generation The token is produced by encapsulating an octet containing the required protection level using gss_wrap() with conf_req set to FALSE. The token is verified using gss_unwrap(). If the server's choice of protection level is unacceptable to the client, then the client must close its connection to the server 7. GSS-API Per-message Protection For TCP and UDP clients and servers, the GSS-API functions for encapsulation and de-encapsulation shall be used by implementations - i.e. gss_wrap() and gss_unwrap(). The default value of quality of protection shall be specified, and the use of conf_req_flag shall be as determined by the previous subnegotiation step. If protection level 1 is agreed then conf_req_flag MUST always be FALSE; if protection level 2 is agreed then conf_req_flag MUST always be TRUE; and if protection level 3 is agreed then conf_req is determined on a per-message basis by client and server using local configuration. All encapsulated messages are prefixed by the framing defined in section 3 with mtyp equal to 0x03. 8. GSS-API Security Context Termination Margrave Document Expiration: 18 May 1998 [Page 5]
draft-ietf-aft-socks-gssapi-revisions-00 18 November 1998 The GSS-API context termination message (emitted by gss_delete_sec_context) is not used by this protocol. When the connection is closed, each peer invokes gss_delete_sec_context() passing GSS_C_NO_BUFFER into the output_token argument. 9. Open Issues The status of GSS-API authentication for the socks protocol needs to be reconciled with respect to the current socks mechanism negotiation scheme. The framing of socks protocol messages within the framing format described in this specification should be defined further. 10. References [RFC 1961] McMahon, P., "GSS-API Authentication Method for SOCKS Version 5", June 1996. [SOCKS V5] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D., and L. Jones, "SOCKS Protocol V5", RFC 1928, April 1996. [RFC 2078] Linn, J., "Generic Security Service API, Version 2", January 1997. [draft-ietf-cat-gssv2-cbind-08.txt] Wray, J., "Generic Security Service API Version 2 : C-bindings", November 10, 1998. [draft-ietf-cat-snego-09.txt] Baize, E., Pinkas, D., "The Simple and Protected GSS-API Negotiation Mechanism," April, 1998 11. Acknowledgment This document is derived from RFC 1961 by P. McMahon, ICL and reflects input from the AFT WG. 12. Security Considerations The protection features of SPNEGO require that all mechanisms proposed during the negotiation exchange support integrity services. If a single mechanism in the list does not support integrity, then the negotiation is subject to a downgrade attack. The security services provided through the GSS-API are entirely dependent on the effectiveness of the underlying security mechanisms, Margrave Document Expiration: 18 May 1998 [Page 6]
draft-ietf-aft-socks-gssapi-revisions-00 18 November 1998 and the correctness of the implementation of the underlying algorithms and protocols. The user of a GSS-API service must ensure that the quality of protection provided by the mechanism implementation is consistent with their security policy. In addition, where negotiation is supported under the GSS-API, constraints on acceptable mechanisms may be imposed to ensure suitability for application to authenticated firewall traversal. 13. Author's Address David Margrave CyberSafe Corporation 1605 NW Sammamish Road, Suite 310 Issaquah, Washington 98027 USA Email: david.margrave@cybersafe.com Phone: (425) 391-6000 Fax: (425) 391-0508 Margrave Document Expiration: 18 May 1998 [Page 7]
