[Search] [txt|pdf|bibtex] [Tracker] [WG] [Email] [Nits]

Versions: 00 01 02 rfc1961                                              
    Internet-Draft                      GSS-API Authentication for SOCKS V5
    Expires: 25SEP95                                                24MAR95
    <draft-ietf-aft-gssapi-00.txt>                         P V McMahon, ICL
    
    
                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 document 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 ds.internic.net (US East Coast), nic.nordu.net
       (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
       Rim).
    
       Comments on this document are welcome and should be sent to
       aft@unify.com, the mailing list of the Authenticated Firewall
       Traversal Working Group of the IETF.
    
    
    
    Contents List
    
         1. Purpose
         2. Introduction
         3. GSS-API Call Specification for SOCKS V5
         4. References
         5. Acknowledgments
         6. Security Considerations
         7. Author's Address
    
    
    
    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 an GSS-API authentication method
    encapsulation that provides integrity, authentication and optional
    confidentiality.
    
    McMahon                                                        [Page 1]


    Internet-Draft                      GSS-API Authentication for SOCKS V5
    
    
    
    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].
    
    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 gss_init_sec_context() interface enables the context
    initiator to know what security services the target supports for the
    chosen mechanism.
    
    The GSS-API per-message protection calls are used to encapsulate any
    further TCP traffic between client and server, and, for integrity
    protection of UDP datagrams.
    
    
    
    3. GSS-API Call Specification for SOCKS V5
    
    3.1 Preparation
    
    Prior to use of GSS-API primitives, the client and server should
    be locally authenticated, and have established 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 as an opaque name-space specific input.
    For example, when using Kerberos V5 naming, the imported name
    is 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.
    
    
    3.2 Client Context Establishment
    
    The client should then call gss_init_sec_context, typically
    passing GSS_C_NO_CREDENTIAL into cred_han to specify the default
    credential (for initiator usage), GSS_C_NULL_OID into mech_type to
    specify the default mechanism, GSS_C_NO_CONTEXT into context_handle to
    
    McMahon                                                        [Page 2]


    Internet-Draft                      GSS-API Authentication for SOCKS V5
    
    specify a NULL context (initially), and the previously imported server
    name into targ_name.
    
    The client must also 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_MUTUAL_FLAG into req_flags).  However, GSS_C_SEQUENCE_FLAG should
    only be passed in for TCP-based clients, not for UDP-based clients.
    
    
    3.3 Client Context Establishment Major Status codes
    
    The gss_init_sec_context returned status code can take two different
    success values:
    
    - If gss_init_sec_context returns GSS_S_CONTINUE_NEEDED, then the
      client should expect the server to issue a token in the subsequent
      subnegotiation response.  The client must pass the token to another
      call to gss_init_sec_context, and repeat this procedure until
      continue operations are complete.
    
    - If gss_init_sec_context returns GSS_S_COMPLETE, then the client
      should respond to the server with any resulting output_token.  If
      there is no output_token, the client should proceed to sending the
      protected request details.
    
    
    3.4 Client initial token
    
    The client's GSS-API implementation then typically responds with the
    resulting output_token which the client sends in a message to
    the server.
    
    +------+------+------+.......................+
    + ver  | mtyp | len  |       token           |
    +------+------+------+.......................+
    + 0x01 | 0x01 | 0x02 | up to 2^16 - 1 octets |
    +------+------+------+.......................+
    
    If, however, the client's GSS-API implementation failed during
    gss_init_sec_context, the the client must close its connection to
    the server.
    
    
    3.5 Server Context Establishment
    
    For the case where a client successfully sends a token emitted by
    gss_init_sec_context() to the server, the server must pass the
    client-supplied token to gss_accept_sec_context as input_token.
    
    McMahon                                                        [Page 3]


    Internet-Draft                      GSS-API Authentication for SOCKS V5
    
    For portability, verifier_cred_handle is set to GSS_C_NO_CREDENTIAL
    (for acceptor usage), context_handle initially set to GSS_C_NO_CONTEXT.
    
    If gss_accept_sec_context returns GSS_CONTINUE_NEEDED, the server
    should return the generated output_token to the client, and
    subsequently pass the resulting client supplied token to another call
    to gss_accept_sec_context.
    
    If gss_accept_sec_context returns GSS_S_COMPLETE, then if an
    output_token is returned, the server should return it to the client.
    If no token is returned, a zero length token should be sent
    by the server to signal to the client that it is ready to receive
    the client's request.
    
    
    3.6 Server Reply
    
    In all continue/confirmation cases, the server uses the same message
    type as for the client -> server interaction.
    
    +------+------+------+.......................+
    + ver  | mtyp | len  |       token           |
    +------+------+------+.......................+
    + 0x01 | 0x01 | 0x02 | up to 2^16 - 1 octets |
    +------+------+------+.......................+
    
    
    3.7 Security Context Failure
    
    If the server refuses the client's connection for any reason (GSS-API
    authentication failure or otherwise), it will return:
    
    +------+------+
    + ver  | mtyp |
    +------+------+
    + 0x01 | 0xff |
    +------+------+
    
    
    3.8 UDP Protection
    
    When using GSS-API, the authentication key material identified in
    [SOCKS V5] for computation of the value for the XCOOKIE digest within
    the UDP MAC field is encapsulated by the authentication mechanism.
    
    Therefore, for UDP-based clients, the XCOOKIE digest value for UDP is
    derived by invoking gss_get_mic() for the COOKIE from the UDP ASSOCIATE
    request.
    
    
    
    
    McMahon                                                        [Page 4]


    Internet-Draft                      GSS-API Authentication for SOCKS V5
    
    
    4. References
    
    [RFC 1508] Generic Security Service API, J Linn,
               September 1993
    
    [RFC 1509] Generic Security Service API : C-bindings, J Wray,
               September 1993
    
    [SOCKS V5] SOCKS Protocol V5, draft-ietf-aft-socks-proto-v5-01.txt
               M Leech, March 1995
    
    
    
    
    5. Acknowledgment
    
    This document builds from a previous draft produced by Marcus Leech
    (BNR) - whose comments are gratefully acknowleged.
    
    
    
    6. Security Considerations
    
    The security services provided through the GSS-API are entirely
    dependent on the effectiveness of the underlying security mechanisms,
    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.
    
    
    
    7. Author's Address
    
    P V McMahon
    post: ICL Enterprises, Kings House, 33 Kings Road, Reading, RG1 3PX, UK
    email: p.v.mcmahon@rea0803.wins.icl.co.uk
    phone: +44 734 634882
    fax:   +44 734 855106
    
    
    
    
    
    
    McMahon                                                        [Page 5]