RFC 1961          GSS-API Authentication for SOCKS V5          June 1996

3.7 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.8 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 |
    +------+------+

    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 0xff to represent an abort
      message

4. GSS-API Protection-level Options

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



RFC 1961          GSS-API Authentication for SOCKS V5          June 1996

4.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
   5.1.

   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 values:

         1 required per-message integrity
         2 required per-message integrity and confidentiality
         3 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.

4.3 Message Protection Subnegotiation Message Format

   The security context protection level is sent from client to server
   and vice versa using the following protected message format:

    +------+------+------+.......................+
    + ver  | mtyp | len  |   token               |
    +------+------+------+.......................+
    + 0x01 | 0x02 | 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 2 to represent a protection
      -level negotiation message

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