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

Versions: 00 01                                                         
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]