R. De Lorenzo
												August 2007


			Socks 5 Secure User-Name and Password authentication protocol



1.	Introduction

	The protocol specification for SOCKS Version 5 specifies a
  	generalized framework for the use of arbitrary authentication
  	protocols in the initial socks connection setup (see RFC 1929). 
	This method is not secure because the Username and Password
	are negotiated in clear text and generate some security issues.
	This document describe a new secure protocol that will be integrated
	with the protocol described in RFC 1929.

Note:

	Unless otherwise noted, the decimal numbers appearing in packet-
	format diagrams represent the length of the corresponding field, in
	octets.  Where a given octet must take on a specific value, the
	syntax X'hh' is used to denote the value of the single octet in that
	field. When the word 'Variable' is used, it indicates that the
	corresponding field has a variable length defined either by an
	associated (one or two octet) length field, or by a data type field.


2.	Protocol description

	The protocol it previews 2 keys exchange negotiations:
	
	1) Autenthication: The client required a "host public key" (128 bit) ((DSS
   	   [FIPS-186-2])from the server with a certificate. The server host key is used during key 
	   exchange to verify that the client is really talking to the correct server.  
	   For this to be possible, the client must have a priori knowledge of the server's
   	   public host key. The client has a local database that associates each host name (as
      	   typed by the user) with the corresponding public host key. If the client dosen't
	   recognize the host key, it must terminate the connection. The server must store
	   the personal host key in a local database and never change it. 
	
	2) Diffie-Hellman Key Exchange: This step is used for exchange the session key that will
	   be used for encrypt subsequent communications using a symmetric key cipher (3des-cbc).


		   1. Client send to server a prime number "P" (> 1024) and a base of "P": "G"
		   2. Client chooses a secret integer "a" (< P), then sends Server: A = G^a mod P
   		   3. Server chose a secret integer "b" (< P), then sends Client B = G^b mod P
   		   4. Client computes the Key = B^a mod P
   		   5. Server computes the Key = A^b mod P

	Now the client (and server to) have the Session Key that will be used for encrypt the User-name and Password
	with the 3des-cbc cipher and can send to the Server the autentications data in security.
 


3.	Initial negotiation

	Once the SOCKS V5 server has started, and the it has selected the
	method "Secure Username/Password Authentication" protocol (0x21), the subnegotiation
	begins. The client send a host-key request to the server (whit a field KEY with all "0"
	and CERT (certificate) with len "0"):

	+-----+-----+------+-------+
	| STAT| KEY | LENC | CERT  |
	+-----+-----+------+-------+		STAT:
	|  1  | 16  |  1   | Var.  |			0x1: Request Host Key
 	+-----+-----+------+-------+

	Server Reply with a valid Host-Key signed:

	
	+-----+-----+------+-------+
	| STAT| KEY | LENC | CERT  |
	+-----+-----+------+-------+		STAT:
	|  1  | 16  |  1   | Var.  |			0x0: Succefull
 	+-----+-----+------+-------+			0x2: Error Generic
							0x3: Reserved


	Client verify if the server is valid and if not it will close the connection.
	Now The client are shure to talking with a correct server, and can start the Diffie-Hellman Key Exchange 


4.	Key Exchange

	Now can start the Key Exchange process based of Diffie-Hellman procedure:
        Client send a packet with "P", "G" and "A" to the server:
	

	+-----+-----+----+-----+
	| STAT|  P  | G  |  A  | 
	+-----+----+-----+-----+		STAT:
	|  1  | 4   | 4  | 4   | 			0x1: Request Key
 	+-----+-----+----+-----+


        Server response with the value of B:

	+-----+-----+
	| STAT|  B  | 
	+-----+-----+				STAT:
	|  1  | 4   | 					0x0: Succesfull
 	+-----+-----+					0x2: Error Generic



5.	Authentication request

	The client must encrypt the User-Name and Password field with the Key 
	and then send to the server the request:


	   +----+------+----------+------+----------+
           |VER | ULEN |  UNAME   | PLEN |  PASSWD  |
           +----+------+----------+------+----------+
           | 1  |  1   | 1 to 255 |  1   | 1 to 255 |
           +----+------+----------+------+----------+

	Notice that this is the same request defined in RFC 1929 (see also). The server verifies the 
	supplied UNAME and PASSWD, and sends the following response.


	  		+----+--------+
                        |VER | STATUS |
                        +----+--------+
                        | 1  |   1    |
                        +----+--------+

   	A STATUS field of X'00' indicates success. If the server returns a
   	`failure' (STATUS value other than X'00') status, it MUST close the
   	connection.





6.  Author's Address

   Raffaele De Lorenzo 
   EMail: raffaele.delorenzo@libero.it