rfc1961

Press here to go to the top of the rfc 'tree'.

Network Working Group                                         P. McMahon
Request for Comments: 1961                                           ICL
Category: Standards Track                                      June 1996

           GSS-API Authentication Method for SOCKS 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.

Table of Contents

         1. Purpose ............................................ 1
         2. Introduction ....................................... 1
         3. GSS-API Security Context Establishment ............. 2
         4. GSS-API Protection-level Options ................... 5
         5. GSS-API Per-message Protection ..................... 7
         6. GSS-API Security Context Termination ............... 8
         7. References ......................................... 8
         8. Acknowledgments .................................... 8
         9. Security Considerations ............................ 8
         10. Author's Address .................................. 9

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, and defines a GSS-API-based encapsulation for provision of
   integrity, authentication and optional confidentiality.

2. Introduction

   GSS-API provides an abstract interface which provides security
   services for use in distributed applications, but isolates callers
   from specific security mechanisms and implementations.

   GSS-API peers achieve interoperability by establishing a common
   security mechanism for security context establishment - either
   through administrative action, or through negotiation.  GSS-API is
   specified in [RFC 1508], and [RFC 1509].  This specification is
   intended for use with implementations of GSS-API, and the emerging



RFC 1961          GSS-API Authentication for SOCKS V5          June 1996

   GSS-API V2 specification.

   The approach for use of GSS-API in SOCKS V5 is to authenticate the
   client and server by successfully 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 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 negotiation.

   The GSS-API per-message protection calls are subsequently used to
   encapsulate any further TCP and UDP traffic between client and
   server.

3. GSS-API Security Context Establishment

3.1 Preparation

   Prior to use of GSS-API primitives, the client and server should be
   locally authenticated, and have established default GSS-API
   credentials.

   The client should call gss_import_name to obtain an internal
   representation of the server name.  For maximal portability the
   default name_type GSS_C_NULL_OID should be used to specify the
   default name space, and the input name_string should treated by the
   client's code as an opaque name-space specific input.

   For example, when using Kerberos V5 naming, the imported name may be
   of the form "SERVICE:socks@socks_server_hostname" where
   "socks_server_hostname" is the fully qualified host name of the
   server with all letters in lower case. Other mechanisms may, however,
   have different name forms, so the client should not make assumptions
   about the name syntax.

3.2 Client Context Establishment

   The client should then call gss_init_sec_context, typically passing:

         GSS_C_NO_CREDENTIAL into cred_handle to specify the default
         credential (for initiator usage),