GnuDIP Client-Server Update Protocol

There are in fact two update protocols. The original protocol involves a direct TCP connection by the client to the server. There is also an adaptation of the original protocol to HTTP (web server protocol). The HTTP protocol is more convenient for authors of generic Windows dynamic DNS update clients, such as DynSite.

With either of these protocols it is not possible for wire tappers to determine the clear text password, nor is it possible for them to "spoof" the update server using captured and modified update messages.

The Original Direct TCP Connection Protocol

ASCII is (of course) used for representing printable characters.

The client makes a TCP connection to the appropriate port on the server host. This port is normally 3495, but a GnuDIP site could choose another port.

As soon as the connection is established the server will send a randomly generated 10 character "salt" string. This is used in the following algorithm for hashing the password:

• Digest the user's password using the MD5 digest message digest algorithm. Convert the digest value (which is a binary value) to its hexadecimal character string representation (characters 0-9 and lower case a-f).

• Append a period (".") and the salt value to create a longer character string.

• Digest this longer character string and convert it to its hexadecimal character representation.

The update message character string is then transmited to the GnuDIP server. This must be in one of these forms:

• user_name:hashed_password:domain:0:address

  This requests that the IP address provided be registered as the (only) address for FQDN user_name.domain.

  In the most common case, the client would pass the address it detects at its end of the connection.

  By default, for compatibility with earlier releases of GnuDIP, the GnuDIP server will allow the IP adddress to be omitted. If the IP address is not provided, the server writes a notice to the log, and the IP address the server detects at the other end of the connection is registered instead. Note that these two addresses will be the same unless the client is behind some sort of proxy. However a site operator may choose to override this backwards compatibility, in order to discourage the use of old clients.

  In response to this message, the server will return one of:

  • 1

    This indicates an invalid login.

  • 0

    This indicates a successful update.

• user_name:hashed_password:domain:1

  This requests that any IP address currently registered for FQDN user_name.domain be removed ("offline" request). The FQDN user_name.domain will no longer correspond to any IP address.

  In response to this message, the server will return one of:

  • 1

    This indicates an invalid login.

  • 2

    This indicates a successful offline.

• user_name:hashed_password:domain:2

  This requests that the server determine the IP address it sees at the client end of the connection, and register that as the (only) address for FQDN user_name.domain. This IP address will also be returned to the client.

  In response to this message, the server will return one of:

  • 1

    This indicates an invalid login.

  • 0:address

    This indicates a successful update and provides the address that was registered.

The HTTP Based Protocol

The HTTP version of the protocol requires the client issue an HTTP GET request, parse the response, use MD5 to obscure the password, issue a second HTTP GET request and parse that response. We first give a conceptual overview, then a concrete example.

If a GnuDIP site operator follows the default installation procedure, the path part of the URL (the part after the host name) for the HTTP update server CGI script will be /gnudip/cgi-bin/gdipupdt.cgi.

In the first HTTP GET request, no query string (the part of an URL after the "?") is provided. It is interpreted as a "request for a salt". The response contains three pieces of data:

1. a randomly generated 10 character "salt" string
2. a "time salt generated" value
3. a "signature"

<meta name="salt" content="XLCDgXvzSo">
<meta name="time" content="1002164730">
<meta name="sign" content="8278f108c83d822048ce0375bede5c15">

The salt is used in the following algorithm for hashing the password:

• Digest the user's password using the MD5 digest message digest algorithm. Convert the digest value (which is a binary value) to its hexadecimal character string representation (characters 0-9 and lower case a-f).

• Append a period (".") and the salt value to create a longer character string.

• Digest this longer character string and convert it to its hexadecimal character representation.

Now the second HTTP GET request is issued. In this request the query string (the part of an URL after the "?") contains the following parameters:

1. the "salt" from the first response ("salt=")
2. the "time salt generated" value from the first response ("time=")
3. the "signature" from the first response ("sign=")
4. the GnuDIP user name ("user=")
5. the GnuDIP domain name ("domn=")
6. the MD5 digested password created above ("pass=")
7. the server "request code" ("reqc="):
   • "0" - register the address passed with this request
   • "1" - go offline
   • "2" - register the address you see me at, and pass it back to me
8. the IP address to be registered, if the request code is "0" ("addr=")

This is an example of a query string:

salt=XLCDgXvzSo&time=1002164730&sign=8278f108c83d822048ce0375bede5c15&user=gnudip&pass=305dff8b78e694a02eafb0c19e48292f&domn=dyn.mpis.net&reqc=0&addr=192.168.0.4

The response to the second request contains:

1. the return code
   • "0" - successful update
   • "1" - invalid login (or other problem)
   • "2" - successful offline
2. the IP address that the server registered, for request code "2"

<meta name="retc" content="0">
<meta name="addr" content="24.81.172.128">

This protocol allows the GnuDIP server to "time out" the prompt. If the response does not come within 60 seconds (for example), it would be denied. The signature is generated using a key known only to the server. This allows the server to know that the "salt" and "time generated" value are valid, without having to maintain state information on the server side.

There is a transcript of three actual protocol exchanges (done using the Perl GnuDIP client) in protocol_sample.txt.