The DDT protocol (DDTP) is a mechanism for the transmission of dynamic DNS record updates and for the determination of host status. It provides these services in a secure and authenticated manner through the use of cryptographic algorithms.
The DDT protocol is connection-less and uses UDP packets for transmission of data. Being connectionless, DDTP cannot rely on the security mechanisms afforded to connection-based services such as HTTPS by the Secure Socket Layer (SSL). Alternative authentication and encryption mechanisms are used in the DDT protocol to assure secure communication.
In this document, the words that are used to define the significance of each particular requirement are usually capitalised. These words are:
This word or the adjective "REQUIRED" means that the item is an absolute requirement of the specification.
This word or the adjective "RECOMMENDED" means that there might exist valid reasons in particular circumstances to ingron this item, but the full implications should be understood and the case carefully wiehged before taking a different course.
This word or the adjective "OPTIONAL" means that this is truly optional. One vendor might choose to include the item because a particular marketplace requires it or because it enhances the product, for example; another vendor may omit the same item.
The DDT Protocol (version 2) is composed of three distinct phases: the Authentication phase, the Update phase, and the Status phase. The Authentication phase is performed in cleartext and uses the Secure Remote Passwords algorithm to provide cleartext-safe authentication. The Update and Status phases are cryptographically secure.
DDT clients are REQUIRED to authenticate with the DDT server prior to attempting to update their DNS records. The Authentication phase of the DDT protocol uses an implementation of the Secure Remote Passwords (SRP) algorithm invented at Standford University.
There are three distinct parts to the SRP protocol as used in DDT. In the first part, the DDT client identifies itself with the DDT server. In the second part, the DDT client and server exchange public keys. In the third part, the DDT client and server exchange verification hashes. Each of these parts is described in more detail below. described in more detail below.
Once the Authentication phase is successfully completed, the DDT client and server will each have transmitted a public key to the other party. Also, the output of the SRP algorithm will have produced a session key. The DDT client and server MAY choose to use either an asymmetrical encryption algorithm (such as RSA) using their public-private key pairs or a symmetrical encryption algorithm (such as blowfish) using the shared secret session key. Either way, the DDT client and DDT server MUST use an encryption algorithm for the Update and Status phases of the protocol.
This command is used by the DDT client to identify itself to the DDT server. The DDT client MUST send the DDT server an User Account Identifier, U. The DDT server MUST reply to the DDT client with the Password Salt, s; a large safe prime, N; and a generator, g.
This command is used by the DDT client to initiate a public-key exchange with the DDT server. The DDT client MUST send the DDT server its Client Public Key, A. The DDT server MUST reply to the DDT client with it's Server Public Key, B.