RFC 1961          GSS-API Authentication for SOCKS V5          June 1996

    - "token" is the GSS-API encapsulated protection level

4.4 Message Protection Subnegotiation Message Generation

   The token is produced by encapsulating an octet containing the
   required protection level using gss_seal()/gss_wrap() with conf_req
   set to FALSE.  The token is verified using gss_unseal()/
   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

5. 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_seal()/gss_wrap(), and gss_unseal()/ 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 following framing:

    +------+------+------+.......................+
    + ver  | mtyp | len  |       token           |
    +------+------+------+.......................+
    + 0x01 | 0x03 | 0x02 | up to 2^16 - 1 octets |
    +------+------+------+.......................+

    Where:

    - "ver" is the protocol version number, here 1 to represent the
      first version of the SOCKS/GSS-API protocol

    - "mtyp" is the message type, here 3 to represent encapulated user
      data

    - "len" is the length of the "token" field in octets

    - "token" is the user data encapsulated by GSS-API



RFC 1961          GSS-API Authentication for SOCKS V5          June 1996

6. GSS-API Security Context Termination

   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.

7. References

    [RFC 1508] Linn, J., "Generic Security Service API",
               September 1993.

    [RFC 1509] Wray, J., "Generic Security Service API : C-bindings",
               September 1993.

    [SOCKS V5] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D.,
               and L. Jones, "SOCKS Protocol V5", RFC 1928, April
               1996.

8. Acknowledgment

   This document builds from a previous memo produced by Marcus Leech
   (BNR) - whose comments are gratefully acknowleged.  It also reflects
   input from the AFT WG, and comments arising from implementation
   experience by Xavier Gosselin (IUT Lyons).

9. 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.



RFC 1961          GSS-API Authentication for SOCKS V5          June 1996