Internet DRAFT - draft-rafiee-intarea-cga-tsig

draft-rafiee-intarea-cga-tsig






DNS Extensions                                                 H. Rafiee
INTERNET-DRAFT                                                          
Updates RFC 2845 (if approved)                                 C. Meinel
Intended Status: Standards Track                Hasso Plattner Institute
Expires: November 8, 2015                                    May 8, 2015


CGA-TSIG/e: Algorithms for Secure DNS Authentication and Optional DNS 
Confidentiality 
                 <draft-rafiee-intarea-cga-tsig-12.txt>

Abstract

   This document describes a new mechanism for secure DNS authentication 
   and a possible mechanism for DNS data confidentiality in various 
   scenarios especially DNS resolvers. It also focuses on reducing human 
   interaction during secure authentication and DNS message encryption. 
   This document supports both IPv4 and IPv6 enabled networks. 



Status of this Memo

   This Internet-Draft is submitted in full conformance with the 
   provisions of BCP 78 and BCP 79. 

   Internet-Drafts are working documents of the Internet Engineering 
   Task Force (IETF). Note that other groups may also distribute working 
   documents as Internet-Drafts. The list of current Internet-Drafts is 
   at http://datatracker.ietf.org/drafts/current. 

   Internet-Drafts are draft documents valid for a maximum of six months 
   and may be updated, replaced, or obsoleted by other documents at any 
   time. It is inappropriate to use Internet-Drafts as reference 
   material or to cite them other than as "work in progress." 

   This Internet-Draft will expire on November 8, 2015. 

   



Copyright Notice

   Copyright (c) 2015 IETF Trust and the persons identified as the 
   document authors. All rights reserved. This document is subject to 
   BCP 78 and the IETF Trust's Legal Provisions Relating to IETF 
   Documents (http://trustee.ietf.org/license-info) in effect on the 
   date of publication of this document. Please review these documents 
   carefully, as they describe your rights and restrictions with respect 


Rafiee, et al.     Expires November 8, 2015                     [Page 1]

INTERNET DRAFT             New algorithms in TSIG            May 8, 2015

   to this document. Code Components extracted from this document must 
   include Simplified BSD License text as described in Section 4.e of 
   the Trust Legal Provisions and are provided without warranty as 
   described in the Simplified BSD License. 



Table of Contents

   1.  Changes to this document [only for authors/editors]  . . . . .  4
   2.  Introduction   . . . . . . . . . . . . . . . . . . . . . . . .  4
     2.1.  Functional description of CGA-TSIG/e Mechanisms  . . . . .  5
   3.  Conventions Used In This Document  . . . . . . . . . . . . . .  7
   4.  Algorithm Overview   . . . . . . . . . . . . . . . . . . . . .  8
     4.1.  CGA-TSIG   . . . . . . . . . . . . . . . . . . . . . . . .  8
       4.1.1.  The CGA-TSIG DATA Structure    . . . . . . . . . . . .  8
       4.1.2.  CGA-TSIG DATA    . . . . . . . . . . . . . . . . . . .  9
         4.1.2.1.  IPv6 Specific Data   . . . . . . . . . . . . . . . 10
         4.1.2.2.  IPv4 Specific Data   . . . . . . . . . . . . . . . 10
       4.1.3.  Generation of CGA-TSIG DATA    . . . . . . . . . . . . 10
   5.  General Verification Steps   . . . . . . . . . . . . . . . . . 11
   6.  CGA-TSIG/CGA-TSIGe Use Case Scenarios  . . . . . . . . . . . . 13
     6.1.  DNS Resolving Scenario (stub to recursive)   . . . . . . . 13
       6.1.1.  Client Verification Process (CGA-TSIGe only)   . . . . 14
       6.1.2.  Resolver Verification Process  . . . . . . . . . . . . 14
     6.2.  DNS Resolving Scenario (Authoritative NS to Recursive NS)  15
   7.  SeND Is Not Supported (IPv6 only)  . . . . . . . . . . . . . . 16
   8.  CGA-TSIG/e Attack Protections  . . . . . . . . . . . . . . . . 16
     8.1.  IP Spoofing    . . . . . . . . . . . . . . . . . . . . . . 16
     8.2.  Resolver Configuration Attack  . . . . . . . . . . . . . . 17
     8.3.  Exposing A Shared Secret   . . . . . . . . . . . . . . . . 17
     8.4.  Replay Attack    . . . . . . . . . . . . . . . . . . . . . 17
     8.5.  Data Confidentiality   . . . . . . . . . . . . . . . . . . 17
   9.  Update to TSIG Specification   . . . . . . . . . . . . . . . . 17
   10.  Security Considerations . . . . . . . . . . . . . . . . . . . 18
   11.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
   12.  Appendix  . . . . . . . . . . . . . . . . . . . . . . . . . . 19
     12.1.  A Sample Key Storage For CGA-TSIG   . . . . . . . . . . . 19
     12.2.  Stored parameters in the node   . . . . . . . . . . . . . 19
     12.3.  CGA Generation Script   . . . . . . . . . . . . . . . . . 20
     12.4.  CGA-TSIGe (DNS privacy)   . . . . . . . . . . . . . . . . 21
       12.4.1.  The CGA-TSIGe DATA Structure    . . . . . . . . . . . 21
         12.4.1.1.  Public Key Request  . . . . . . . . . . . . . . . 22
         12.4.1.2.  Public Key Response   . . . . . . . . . . . . . . 22
       12.4.2.  Generation of CGA-TSIGe DATA    . . . . . . . . . . . 23
         12.4.2.1.  IPv6 Specifics  . . . . . . . . . . . . . . . . . 23
           12.4.2.1.1.  Generation of Query Request Message   . . . . 23
           12.4.2.1.2.  Generation of Query Response Message  . . . . 26
         12.4.2.2.  IPv4 Scenario   . . . . . . . . . . . . . . . . . 26
           12.4.2.2.1.  Generation of Query Request Message   . . . . 27
           12.4.2.2.2.  Generation of Query Response Message  . . . . 27
       12.4.3.  Process of Public Key Response Message  . . . . . . . 27
         12.4.3.1.  IPv6 only Scenarios   . . . . . . . . . . . . . . 27


Rafiee, et al.     Expires November 8, 2015                     [Page 2]

INTERNET DRAFT             New algorithms in TSIG            May 8, 2015

         12.4.3.2.  IPv4 only Scenarios   . . . . . . . . . . . . . . 28
       12.4.4.  Process of Encrypted Query Request Message  . . . . . 28
       12.4.5.  Process of Encrypted Query Response Message   . . . . 28
     12.5.  Other Optional Use case scenarios   . . . . . . . . . . . 28
       12.5.1.  The FQDN Or PTR Update (IPv6 only)  . . . . . . . . . 29
         12.5.1.1.  Verification Process  . . . . . . . . . . . . . . 29
       12.5.2.  DNS Zone Transfer   . . . . . . . . . . . . . . . . . 30
         12.5.2.1.  Verification Process  . . . . . . . . . . . . . . 31
   13.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . 31
   14.  References  . . . . . . . . . . . . . . . . . . . . . . . . . 31
     14.1.  Normative . . . . . . . . . . . . . . . . . . . . . . . . 31
     14.2.  Informative . . . . . . . . . . . . . . . . . . . . . . . 32
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34










































Rafiee, et al.     Expires November 8, 2015                     [Page 3]

INTERNET DRAFT             New algorithms in TSIG            May 8, 2015


1.  Changes to this document [only for authors/editors] 

   This section should be removed before any publication. 

   - Introduction section: added explanation about secure authentication 
   and the exact focus of this document. updated explanation to DNS 
   privacy problems and added a reference to DNS privacy problem 
   statement document, removed problem statement section since it is 
   already mentioned in introduction. Removed terminology and added 
   reference to existing DNS terminology draft 

   - Overview of CGA-TSIG algorithm section: explained different 
   operations via questions and answers to keep the readers focus on the 
   main functions. 

   - Appendix section: moved DNS privacy to appendix section. moved FQDN 
   and PTR scenario to appendix section in other supported scenario. 

   - CGA-TSIG section: removed IP tag, old signature and old public key. 
   Removed the text about DNS update 

   - CGA-TSIGe section: removed IP tag, old signature and old public 
   key. 


2.  Introduction 

   Authentication is a key feature that protects both DNS server and 
   client from several attacks ? identity spoofing, unauthorized update 
   of DNS records, phishing, etc. This is especially critical in 
   different DNS scenarios. This draft only focuses on three DNS 
   scenarios that are during Dynamic DNS (DDNS) [RFC2136] of updating 
   PTR and Fully Qualified Domain Name (FQDN) resource records (RRs) and 
   any other values on DNS Servers , DNS zone update ([AI]XFR) for 
   multiple DNS servers (authenticating two DNS servers), and during 
   authentication of recursive DNS servers on clients. 

   TSIG [RFC2845] is based on MAC authentication. It uses one way 
   hashing and a shared secret for the authentication of DNS messages 
   especially during DDNS. In this mechanism there need to be a shared 
   secret shared among all clients and DNS servers that want to process 
   DDNS. The configuration and sharing this shared secret among all 
   these nodes are manual. If the shared secret is known to attacker, 
   then the manual step for sharing this shared secret should be 
   repeated. TSIG is also unable to protect a node against some 
   well-known DNS attacks. One example is DNS amplification attack. 

   To address the above problems and securing the last miles of the 
   internet where DNSSEC might not be able to protect it easily, this 
   document introduces CGA-TSIG algorithm. The purpose of CGA-TSIG is 
   automation (minimizing human interaction) and secure authentication. 



Rafiee, et al.     Expires November 8, 2015                     [Page 4]

INTERNET DRAFT             New algorithms in TSIG            May 8, 2015

   Besides, DNS messages might contain important data which might allow 
   an attacker to analyze the behavior of users in a network or pursue 
   further attacks. These data might be confidential and need 
   protection. There are recently a lot of concerns about DNS privacy 
   and hiding the data exchanges between stub resolvers' and DNS server 
   from prying eyes (either in active or passive attacks). 

   In appendix of this document, the small changes that needed in 
   CGA-TSIG algorithm to also consider DNS privacy is introduced and 
   call this new algorithm as CGA-TSIGe. CGA-TSIGe protects a node 
   against DNS privacy attacks explained in [dns-privacy]. It does this 
   by providing a node with a mechanism to securely verify the DNS 
   resolver (to avoid spoofed DNS messages) and encrypt the whole DNS 
   message. It uses the current available Resource Records (RRs) to 
   carry any parameters requires for this process. After encryption 
   process, this encrypted message is encapsulated in a new DNS message 
   (new DNS header is added to it) and the required parameters are added 
   in the additional section of this new DNS message for decryption 
   purposes in the receiver node. CGA-TSIGe uses both asymmetric and 
   symmetric cryptography. Asymmetric cryptography is used for 
   encrypting the 16 byte secret key. This secret key then can be used 
   as a key for the symmetric encryption algorithm in order to encrypt 
   the whole DNS message. This process will increase the DNS performance 
   by avoiding the encryption of a large DNS message using a public key 
   cryptography. Both CGA-TSIG and CGA-TSIGe support both IPv4 and IPv6 
   enabled network and considered as new algorithms in the TSIG Resource 
   Record (RR). 


2.1.  Functional description of CGA-TSIG/e Mechanisms 

   - Purpose 

   1-secure authentication, 2-minimize human interaction and 3- provide 
   data confidentiality required to accomplish a shared secret or key 
   exchange. If only number 1 and 2 is the purpose, then the algorithm 
   is called CGA-TSIG. When 1,2, and 3 all together is the purpose, then 
   the algorithm is called CGA-TSIGe (it is explained in Appendix). 

   Since this protocol is added to "Other Data" section of TSIG RR, when 
   a DNS client or server does not support CGA-TSIG, it easily ignores 
   CGA-TSIG option without returning any error and returns back to 
   compatibility mode, i.e., using DNS server without encryption. 

   

   - How client and server receives the IP address/hash of public key of 
   DNS server? 

   There are two possibilities: 1- From a DNS option in router 
   advertisement message [RFC6106] 2- From a DHCP/v6 server protected 
   via SAVI approaches [savi-dhcp] or any monitoring node 



Rafiee, et al.     Expires November 8, 2015                     [Page 5]

INTERNET DRAFT             New algorithms in TSIG            May 8, 2015

   

   - What if the network is not trusted (e.g. untrusted DHCP server, 
   untrusted router, untrusted DNS server) 

   This is only applicable for resolver scenario. User can easily 
   introduce the IP address of trusted resolver (or select home resolver 
   from the list of trusted resolvers in its computer). For automation 
   purpose, the implementation SHOULD provide a possibility to store a 
   short list of trusted resolvers so that the client can pick one of 
   them. 

   

   - How CGA-TSIG/e Prevents Spoofing and authenticate DNS servers or 
   clients (depends on scenario) 

   In the IPv6 scenario, the algorithms use Cryptographically Generated 
   Addresses (CGA) [RFC3972] or Secure Simple Addressing Scheme for IPv6 
   Autoconfiguration (SSAS) [4, 5]. Both CGA and SSAS provide the nodes 
   with the necessary proof of IP address ownership by providing a 
   cryptographic binding between a host's public key and its IP address 
   without the need for the introduction of infrastructure. In other 
   word, by receiving any message from a DNS resolver, client can verify 
   its signature and since the key is bound to the IP address, the 
   client can make sure that the value is from the same resolver as it 
   already received the IP address from DHCP server or an option in 
   router advertisement message. 

   In IPv4 scenarios, the algorithms use the hash of public key as an 
   authentication approach. For example, in resolver scenario, the 
   client receives the DNS resolver?s hash of (IPv4 + public key) from a 
   DHCPv4 server that is protected by SAVI approaches or other 
   monitoring approaches. When the client receives the key from DNS 
   server it calculates the hash of (IPv4 + public key) and compare this 
   value with what it received from DHCP server. If it matches, then the 
   client can trust any value received from the DNS server. 

   

   - How Client and server do key exchange in DNS privacy scenario 
   (Appendix) 

   Client sends an empty message and adding TSIG in additional part and 
   set the algorithm to CGA-TSIGe. This message then can be sent to DNS 
   server. DNS server then knows it should submit its key to client, 
   sign it with its own private key. 

   

   - In CGA-TSIGe, if the whole message is encrypted, How the DNS server 
   knows how to decrypt the message 



Rafiee, et al.     Expires November 8, 2015                     [Page 6]

INTERNET DRAFT             New algorithms in TSIG            May 8, 2015

   After a client receives the public key of DNS server in a secure 
   manner (as explained in prior paragraphs), it generates a random 
   number and call this number a secret key (it is similar to session 
   key in TLS or SSL). It, then, encrypts the whole DNS message and 
   encapsulates it in a new DNS message (that is adding new header and 
   additional section). In additional section of this new DNS message, 
   it includes CGA-TSIGe and all its required parameters. In other word, 
   the whole encrypted messages is like a query section in new DNS 
   message. Then the secret key is encrypted using the public key of DNS 
   server and this message is submitted to the DNS server. 

   When the DNS server receives this message, if the additional section 
   includes CGA-TSIGe, then it first decrypts the secret key using 
   public key cryptography and then decrypts the whole DNS message using 
   this secret key and a symmetric algorithm such as AES. 

   


3.  Conventions Used In This Document 

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
   document are to be interpreted as described in RFC 2119 [RFC2119]. 

   In this document, these words will appear with that interpretation 
   only when in ALL CAPS. Lower case uses of these words are not to be 
   interpreted as carrying RFC 2119 significance. 

   => This sign in the document should be interpreted as "change to". 

   IPv6 only: this indicates that the explained approach can be used 
   only in IPv6 scenario 

   IPv4 only: this indicates that the explained approach can be used 
   only in IPv4 scenario 

   IPv4 and IPv6: This indicates that the explained approach can be used 
   in both IPv4 and IPv6 scenario and there are no differences. 

   | This sign in this document should be interpreted as 
   ?concatenation?. 

   Note: This document uses the names CGA-TSIG and CGA-TSIGe. But it 
   does not mean that the algorithm in use in this document is only CGA. 
   The "CGA" name was taken from the first versions of this draft and 
   continued to be appeared in the latest versions of this draft. This 
   draft also uses TSIG as a carrier protocol to avoid changing the 
   current DNS protocol. 

   The terms used in this documents are defined in [dns-terms]. 




Rafiee, et al.     Expires November 8, 2015                     [Page 7]

INTERNET DRAFT             New algorithms in TSIG            May 8, 2015

4.  Algorithm Overview 

   The following section explain the CGA-TSIG (secure authentication) 
   data structure in IPv4 and IPv6 scenarios. A CGA-TSIG data structure 
   is an option to the TSIG Resource Record (RR). 


4.1.  CGA-TSIG  


4.1.1.  The CGA-TSIG DATA Structure  

   The CGA-TSIG data structure SHOULD be added to the Other DATA section 
   of the RDATA field in the TSIG Resource Record (RR) (see figures 1 
   and 2). The DNS RRTYPE MUST be set to TSIG [RFC2845]. The RDATA 
   Algorithm Name MUST be set to CGA-TSIG. The CGA-TSIG name is used 
   when there is no need for DNS data confidentiality. The CGA-TSIGe 
   (Please refer to Appendix) is used when all parts of a DNS message 
   should be encrypted to provide data confidentiality. The Name MUST be 
   set to root (.). This is the smallest possible value that can be 
   used. The MAC Size MUST be set to 0 when the Algorithm Name is 
   CGA-TSIG. 

   A detailed explanation of the standard RDATA fields can be found in 
   section 2.3 [RFC2845]. This document focuses only on the new 
   structure added to the Other DATA section. These new fields are 
   CGA-TSIG Len and CGA-TSIG DATA. The TSIG RR is added to an additional 
   section of the DNS message. 

   +---------------------------------------+
   |              Algorithm Name           |
   |               (CGA-TSIG)              |
   +---------------------------------------+
   |              Time Signed              |
   |                                       |
   +---------------------------------------+
   |                  Fudge                |
   |                                       |
   +---------------------------------------+
   |                 MAC Size              |
   |                                       |
   +---------------------------------------+
   |                   MAC                 |
   |                                       |
   +---------------------------------------+
   |               Original ID             |
   |                                       |
   +---------------------------------------+
   |                   Error               |
   |                                       |
   +---------------------------------------+
   |                Other Len              |
   |                                       |


Rafiee, et al.     Expires November 8, 2015                     [Page 8]

INTERNET DRAFT             New algorithms in TSIG            May 8, 2015

   +---------------------------------------+
   |               Other Data              |
   |                                       |
   +---------------------------------------+
   Figure 1:   Modified TSIG RDATA
   The CGA-TSIG DATA Field and the CGA-TSIG Len will occupy the first 
   two slots of Other DATA. Figure 2 shows the layout. Any extra 
   options/data should be placed after CGA-TSIG field. CGA-TSIG Len is 
   the length of CGA-TSIG DATA in byte. 

   +---------------------------------------+
   |             CGA-TSIG Len              |
   |              (2 bytes)                |
   +---------------------------------------+
   |             CGA-TSIG DATA             |
   |                                       |
   +---------------------------------------+
   |             Other Options             |
   |                                       |
   +---------------------------------------+
   Figure 2: Other DATA section of RDATA field

4.1.2.  CGA-TSIG DATA  

   Figure 3 explains detail structure of CGA-TSIG DATA section. Fields 
   that are marked (*) are different depending on IPv6 or IPv4. 

   +---------------------------------------+
   |             AsyAlgorithm              |
   |              (15 bytes)               |
   +---------------------------------------+
   |                  Type *               |
   |                (u_int16_t)            |
   +---------------------------------------+
   |              Parameters Len           |
   |                (1 byte)               |
   +---------------------------------------+
   |                Parameters *           |
   |                (variable)             |
   +---------------------------------------+
   |             Signature Len             |
   |               (1 bytes)               |
   +---------------------------------------+
   |                Signature              |
   |               (variable)              |
   +---------------------------------------+
   Figure 3: structure of CGA-TSIG DATA section
   - AsyAlgorithm: Asymmetric algorithm. IANA numeric value for RSA 
   algorithm 1.2.840.113549.1.1.1[RFC4055]. For ECC, IANA needs to 
   define a new number. 

   - Type: Name of algorithm 



Rafiee, et al.     Expires November 8, 2015                     [Page 9]

INTERNET DRAFT             New algorithms in TSIG            May 8, 2015

   - Parameters Len: Length of parameters 

   - Signature Len: Length of public key cryptography signature 

   - Signature: Please refer to section 4.1.3 of this document 

   


4.1.2.1.  IPv6 Specific Data 

   For IPv6, the Type field indicates the Interface ID generation 
   algorithm that is used in SeND (An Interface ID is the 64 rightmost 
   bits of an IPv6 address). The field allows for future development. 
   The default value for CGA is 1 and for SSAS is 2. 


4.1.2.2.  IPv4 Specific Data 

   For IPv4, the Type field indicates the hashing function used to 
   generate the hash of (public key + IPv4). By default, it is SHA256. 
   This value SHOULD be set to 1 for SHA256 and other numeric 
   incremental value for other hashing algorithms. This allows for 
   future hashing functions. 


4.1.3.  Generation of CGA-TSIG DATA  

   In order to use CGA-TSIG as an authentication approach, some of the 
   parameters need to be cached during IP address generation. If no 
   parameters are available in the cache, please see section 7. 

   1. Obtain Require Parameters From Cache. 

   For IPv6, if the Type Field above is CGA, then the parameters that 
   SHOULD be cached are the modifier, algorithm type, location of the 
   public/private keys and the IP addresses of the host. For IPv4, the 
   location to the key pairs needs to be cached in order to generate the 
   signature. 

   Note: If the node is a DNS server (resolver or Authoritative Name 
   Server) that does not support SeND but wants to use the CGA-TSIG 
   algorithm, a script can be used to generate the CGA parameters. 
   (Please refer to the section 12.2. appendix) 

   2. Generate Signature 

   The signature is generated by concatenation of the following values 
   where Type is the 128-bit Message Type tag value. This value for CGA 
   (SeND) is 0x086F CA5E 10B2 00C9 9C8C E001 6427 7C08. 

   Plain text= Type | Entire DNS message (Please refer to figure 4 and 
   figure 5) 


Rafiee, et al.     Expires November 8, 2015                    [Page 10]

INTERNET DRAFT             New algorithms in TSIG            May 8, 2015


   Then the node uses its own private key obtained from the cache as 
   explained in last step to sign the plain text. This signature MUST be 
   added to the signature field of the CGA-TSIG DATA record. The Time 
   Signed field uses the same timestamp in RDATA. This will prevent 
   replay attacks by changing the signature each time a Node sends a DNS 
   message. The format of DNS messages is explained in section 4.1.3 
   [RFC1035]. 

   +-----+------+--------+
   |Type |Length|Reserved|
   |1byte|1 byte| 1 byte |
   +---------------------+
   |        Header       |
   |       12 bytes      |
   +---------------------+
   |     Zone section    |
   |   variable length   |
   +---------------------+
   |    prerequisite     |
   |   variable length   |
   +---------------------+
   |    Update section   |
   |   variable length   |
   +---------------------+
   |   Additional Data   |
   |   variable length   |
   +---------------------+
   Figure 4 DNS update message
   
   +-----+------+--------+
   |Type |Length|Reserved|
   |1byte|1 byte| 1 byte |
   +---------------------+
   |        Header       |
   |       12 bytes      |
   +---------------------+
   |       Question      |
   |   variable length   |
   +---------------------+
   |       Answer        |
   |   variable length   |
   +---------------------+
   |       Authority     |
   |   variable length   |
   +---------------------+
   |   Additional Data   |
   |   variable length   |
   +---------------------+
   Figure 5 DNS Query message (section 4.)

5.  General Verification Steps 



Rafiee, et al.     Expires November 8, 2015                    [Page 11]

INTERNET DRAFT             New algorithms in TSIG            May 8, 2015

   This section explains general verification steps and can be used as a 
   reference for verification in different scenarios. The modification 
   of these steps is possible according the use case scenarios (next 
   section). 

   Sender authentication is necessary in order to prevent attackers from 
   making unauthorized modifications to DNS servers through the use of 
   spoofed DNS messages. The verification process uses the following 
   steps: 

   1. Verify The Signature (IPv4 and IPv6) 

   The Signature contained in CGA-TSIG DATA should be verified. This can 
   be done by retrieving the public key and signature from CGA-TSIG DATA 
   and using this public key to verify the signature. If the 
   verification process is successful, then execute step 2. Otherwise, 
   the message should be discarded. 

   2. Check The Time Signed (IPv4 and IPv6) 

   The Time Signed value is obtained from TSIG RDATA and is called t(1). 
   The current system time is then obtained and converted to UTC time 
   and is called t(2). Fudge time is obtained from TSIG RDATA and is 
   called t(fudge). If t(1) is in the range of t(2) and t(2) minus/plus 
   t(fudge) (see formula 1), then step 3 will be executed. Otherwise, 
   the message will be considered spoofed and discarded. The range is 
   used in consideration of the delays that can occur during its 
   transmission over TCP or UDP. Both times must use UTC time in order 
   to avoid differences in time based on different geographical 
   locations. 

   (t(1) - t(fudge)) <= t(2) <=(t(1) + t(fudge)) 

   Formula: (1) 

   3. Execute The CGA Verification (IPv6 only) 

   These steps are in section 5 of [RFC3972]. If the sender of the DNS 
   message uses another algorithm, instead of CGA, then this step 
   becomes the verification step for that algorithm. If the verification 
   process is successful, then step 6 will be executed. Otherwise the 
   message will be discarded without further action. 

   4. Generate The Hash of (public key | IP address) (IPv4 only) 

   The DNS server retrieves the hashing Algorithm Type from the 
   CGA-TSIGe DATA structure. It then uses the following concatenations. 

   Digest = hash(public key | IP address of the update requester) 

   Where hash is SHA256 algorithm (by default) or another algorithm 
   identified in Type section of CGA-TSIG DATA structure. It then 
   compares digest with the hash value available in the DNS 


Rafiee, et al.     Expires November 8, 2015                    [Page 12]

INTERNET DRAFT             New algorithms in TSIG            May 8, 2015

   configuration. If they are the same, the Update Message should be 
   processed, otherwise, go to step 5. 

   5. Verify The Source IP Address (IPv6 only) 

   The source IP Address of the Update requester MUST be checked against 
   the one contained in the DNS configuration. If they are the same, the 
   Update Message should be processed, otherwise, proceed to step 7. 

   6. Verify The Public Key (IPv6 only) 

   The DNS server checks whether or not the public key retrieved from 
   CGA-TSIG DATA is the same as what is available in the cache where the 
   public keys and IP addresses are saved. If this Public Key is not 
   found in the cache, then the update will be rejected. Otherwise, when 
   the Old Public Key Length is not zero go to step 8. 


6.  CGA-TSIG/CGA-TSIGe Use Case Scenarios 


6.1.  DNS Resolving Scenario (stub to recursive) 

   A DNS query request sent by a host, such as a client or a mail 
   server, does not need to generate CGA-TSIG DATA because the resolver 
   responds to anonymous queries. The Resolver's response SHOULD contain 
   the CGA-TSIG DATA field in order to verify him. However, the client 
   needs to include the TSIG RDATA and set the Algorithm Type to 
   CGA-TSIG, and it MUST set the CGA-TSIG Len to zero (0). This allows 
   the resolver to include CGA-TSIG in the client. 

   If the Node needs to deploy DNS data confidentiality (please refer to 
   section 12.4.), then it needs to set the Algorithm Type to CGA-TSIGe 
   and follows the step explained in section 12.4.2. In this particular 
   scenario, the Node MUST set Message Hash in CGA-TSIGe. This allows 
   the DNS server to ensure data integrity without going to the process 
   of message decryption. 

   In the generation of the CGA-TSIG/CGA-TSIGe for a Resolver, there is 
   no need to include the IP Tag. This is because the Resolvers do not 
   usually have several IP addresses so the client does not need to keep 
   several IP addresses for the same resolver. 

   +----------------+                        +----------------+
   |  DNS Resolver  |                        |   DNS client   |
   |                |  Ask for public key    |                |
   |                |   <------------------- |                |
   |                |      Here you are      |                |
   |                |   -------------------> |                |
   |                |                        | Verification   |
   |                |                        | explained in   |
   |                |                        | section 12.4.3  |
   |                |                        |                |


Rafiee, et al.     Expires November 8, 2015                    [Page 13]

INTERNET DRAFT             New algorithms in TSIG            May 8, 2015

   |                |                        | Generation of  |
   |                |                        | Query request  |
   |                |                        |set message hash|
   |                |                        |explained in    |
   |                |                        |section 12.4.2   |
   |                |   Encrypted DNS message|                |
   |                |   <------------------- |                |
   |   Verification |                        |                |
   |   explained in |                        |                |
   |   section 6.1.1|                        |                |
   |                |                        |                |
   |   DNS message  |                        |                |
   |   decryption   |                        |                |
   |   explained in |                        |                |
   |   section 12.4.4|                        |                |
   |   Encrypt Query|                        |                |
   |   response     |                        |                |
   |   explained in |                        |                |
   |   section 12.4.2|                        |                |
   |                |Encrypted Query response|                |
   |                |   -------------------> |                |
   |                |                        | Verification   |
   |                |                        | explained in   |
   |                |                        | section 6.1.2  |
   |                |                        |                |
   |                |                        | DNS message    |
   |                |                        | decryption     |
   |                |                        | explained in   |
   |                |                        | section 12.4.5  |
   +----------------+                        +----------------+
   Figure 11. DNS resolving scenario using CGA-TSIGe
   (Data confidentiality and secure authentication)

6.1.1.  Client Verification Process (CGA-TSIGe only) 

   1. Retrieves Hashing Algorithm From CGA-TSIGe 

   The resolver retrieves the hashing algorithm from CGA-TSIGe Type 
   field. 

   2. Executes Hashing Algorithm on DNS Message 

   The Resolver computes the SHA algorithm on the whole DNS message. It 
   compares this with the value obtained from Message Hash of CGA-TSIGe. 
   If they are the same, it decrypts the message using the shared secret 
   obtained from the digest_secret_key section of the Other DATA section 
   of TSIG RRType. 


6.1.2.  Resolver Verification Process 

   When a Resolver responds to the client's query request for the first 
   time, the client saves its Public Key in a file. This allows the 


Rafiee, et al.     Expires November 8, 2015                    [Page 14]

INTERNET DRAFT             New algorithms in TSIG            May 8, 2015

   client to verify this Resolver when it changes its IP Address due to 
   privacy or security concerns. The steps 2 and 3 of the verification 
   process are the same as those steps explained in section 5. These 
   steps are as follows: 

   1. Verify The Hash of Public Key (IPv4 only) 

   The client retrieves the SHA Algorithm Type from the Type section of 
   CGA-TSIG/CGA-TSIGe, concatenates the following values: 

   digest= hash(Resolver's Public Key | the Resolver's IP address) 

   Where hash is a hash function (by default; SHA256). The client 
   compares the digest with the value in its cache (received securely 
   from a DHCP server or manually set by client). If they are the same, 
   it stores its Public Key in its cache, and continues onto the next 
   step. Otherwise the message will be discarded. 

   2. Verify The Signature (IPv4 and IPv6) 

   The Signature contained in CGA-TSIG/CGA-TSIGe DATA can be verified by 
   retrieving the Public Key and Signature from the CGA-TSIG/CGA-TSIGe 
   DATA. If the verification process is successful, continue onto step 
   3, otherwise the message will be discarded. 

   3. Check The Time Signed (IPv4 and IPv6) 

   4. Execute The CGA Verification (IPv6 only) 

   5. Verify The Source IP Address (IPv6 only) 

   If the Resolver's source IP address is the same as that which is 
   known for the host or the length of Old Public Key is not zero (0), 
   then step 6 will be executed. Otherwise the message SHOULD be 
   discarded without further action. 

   6. Verify The Public Key (IPv6 only) 

   The client checks whether or not the Public Key retrieved from 
   CGA-TSIG/CGA-TSIGe DATA matches any Public Key that was previously 
   saved in the storage where the Public Key and IP addresses of 
   Resolvers are saved. If there is a match, then the message is 
   processed. If not, then step 7 will be executed. 


6.2.  DNS Resolving Scenario (Authoritative NS to Recursive NS) 

   This verification step of Authoritative Name Server to Recursive Name 
   Server is the same as that explained in section 5. In this case the 
   Recursive Name Server does not need to generate CGA-TSIG DATA, but 
   the Root Name Server does need to include it in order to enable the 
   Recursive Name Server to verify it. The Recursive Name Server needs 
   to include the TSIG RDATA and set the Algorithm Type to CGA-TSIG. It 


Rafiee, et al.     Expires November 8, 2015                    [Page 15]

INTERNET DRAFT             New algorithms in TSIG            May 8, 2015

   MUST set the CGA-TSIG Len to zero (0). This allows the Root Name 
   Server to know when to include CGA-TSIG for verification process in 
   client. 

   In case the node needs to use DNS data confidentiality, then it needs 
   to set the Algorithm Type to CGA-TSIGe and follows the step explained 
   in section 12.4.2. In this particular scenario, the Node MUST set the 
   Message Hash in CGA-TSIGe. This allows the DNS server to ensure the 
   data integrity of this message without going to the process of 
   message decryption. 


7.  SeND Is Not Supported (IPv6 only) 

   In the case where there are no cache parameters available during the 
   IP Address generation, there are then three scenarios that come into 
   play here. In the first scenario there is the case where the sender 
   of a DNS message needs to generate a key pair and generate the 
   CGA-TSIG or CGA-TSIGe data structure as explained in section 4.1 or 
   section 12.4. The Node SHOULD skip the first section of the 
   verification processes explained in section 5, section 6.1.1, and 
   section 6.1.2. 

   In the second scenario, as explained in section 4.1.3 (step 1), it is 
   not necessary for the server to support the SeND or CGA algorithm. 
   The DNS administrator can make a one-time use of a CGA script to 
   generate the CGA parameters and then manually configure the IP 
   address of the DNS server. Later, the DNS server can use those values 
   as a means for authenticating other Nodes. The verifier Nodes also do 
   not necessarily need to support SeND. They only need to support 
   CGA-TSIG. 

   In the third scenario, as explained in section 12.4.2.2., the Node 
   can use the same approach used for IPv4 and retrieve the hash of 
   (Public Key + IPv6 Address) from the DHCPv6 server. 


8.  CGA-TSIG/e Attack Protections 

   There are several types of attacks that CGA-TSIG/CGA-TSIGe can 
   prevent. The use of CGA-TSIG will reduce the number of messages 
   needed between a client and a server in order to establish a secure 
   channel. To exchange the shared secret between a DNS Resolver and a 
   client, when TSIG is used, a minimum of four (4) messages are 
   required. By modifying [RFC2845] to use CGA-TSIG, this will decrease 
   the number of messages needed . The messages used in [RFC2930] (TKEY 
   RR) are not needed when CGA-TSIG is used. 


8.1.  IP Spoofing  

   This prevents the attack by finding a binding between the IP address 
   and the Public Key for both IPv4 and IPv6 , with different 


Rafiee, et al.     Expires November 8, 2015                    [Page 16]

INTERNET DRAFT             New algorithms in TSIG            May 8, 2015

   approaches. 


8.2.  Resolver Configuration Attack 

   When using CGA-TSIG/CGA-TSIGe, the DNS server (or client), would not 
   need further configuration. This reduces the possibility of human 
   errors being introduced into the DNS configurations. Since this type 
   of attack is predicated on human error, the chances of it occurring 
   are minimized. 


8.3.  Exposing A Shared Secret 

   Using CGA-TSIG/CGA-TSIGe will decrease the number of manual steps 
   required in generating the new shared secret and in exchanging it 
   among the hosts to update the old shared secret. This manual step is 
   required after a shared secret is leaked. 


8.4.  Replay Attack  

   Using the Time Signed value in the Signature modifies the content of 
   the Signature each time the Node generates and sends it to the DNS 
   server. If the attacker attempts to spoof the timestamp, the DNS 
   server will check this message by verifying the signature. In this 
   case, the verification process will fail preventing the replay 
   attack. 


8.5.  Data Confidentiality 

   Encrypting the whole DNS message will deny the attacker from knowing 
   the content of DNS messages. This will avoid zone walking and many 
   other attacks on DNS RRs. 


9.  Update to TSIG Specification 

   To support CGA-TSIG/e as a new algorithm in TSIG, updates needs to be 
   made in the following sections of TSIG specification. In case any 
   node does not support CGA-TSIG/e, it only ignores these new 
   algorithms. 

   - Section 4.2: The server MUST not generate a signed response to an 
   unsigned request => The server MUST not generate a signed response to 
   an unsigned request, unless the Algorithm Name filed contains 
   CGA-TSIG or CGA-TSIGe. 

   - Section 4.5.2: It MUST include the client's current time in the 
   time signed field, the server's current time (a u_int48_t) in the 
   other data field, and 6 in the other data length field => It MUST 
   include the client's current time in the time signed field, the 


Rafiee, et al.     Expires November 8, 2015                    [Page 17]

INTERNET DRAFT             New algorithms in TSIG            May 8, 2015

   server's current time (a u_int48_t) in the other data field, and if 
   the Algorithm Name is CGA-TSIG or CGA-TSIGe, then add the length of 
   this client's current time to the total length of Other DATA field. 
   The client's current time in this case will be placed after the 
   CGA-TSIG/CGA-TSIGe Data. 

10.  Security Considerations

   The approach explained in this draft, CGA-TSIG, is a solution for 
   securing DNS messages from spoofing type attacks like those explained 
   in section 1.1. 

   A problem that may arise here concerns attacks against the CGA 
   algorithm. In this section we will explain the possibility of such 
   attacks against CGA [5] and explain the available solutions that we 
   considered in this draft. 

   a) Discover an Alternative Key Pair Hashing of the Victim's Node 
   Address 

   In this case an attacker would have to find an alternate key pair 
   hashing of the victim's address. The probability for success of this 
   type of attack will rely on the security properties of the underlying 
   hash function, i.e., an attacker will need to break the second 
   pre-image resistance of that hash function. The attacker will perform 
   a second pre-image attack on a specific address in order to match 
   other CGA parameters using Hash1 and Hash2. The cost of doing this is 
   (2^59+1) * 2^(16*1). If the user uses a sufficient security level, it 
   will be not feasible for an attacker to carry out this type of attack 
   due to the cost involved. Changing the IP address frequently will 
   also decrease the chance for this type of attack succeeding. 

   b) DoS to Kill a CGA Node 

   Sending a valid or invalid CGA signed message with high frequency 
   across the network can keep the destination node(s) busy with the 
   verification process. This type of DoS attack is not specific to CGA, 
   but it can be applied to any request-response protocol. One possible 
   solution ,to mitigate this attack, is to add a controller to the 
   verifier side of the process to determine how many messages a node 
   has received over a certain period of time from a specific node. If a 
   determined threshold rate is exceeded, then the node will stop 
   further receipt of incoming messages from that node. 

   c) CGA Privacy Implication 

   Due to the high computational complexity necessary for the creation 
   of a CGA, it is likely that once a node generates an acceptable CGA 
   it will continue its use at that subnet. The result is that nodes 
   using CGAs are still susceptible to privacy related attacks. One 
   solution to these types of attacks is setting a lifetime for the 
   address as explained in RFC 4941. 



Rafiee, et al.     Expires November 8, 2015                    [Page 18]

INTERNET DRAFT             New algorithms in TSIG            May 8, 2015



11.  IANA Considerations

   The IANA has allowed for choosing new algorithm(s) for use in the 
   TSIG Algorithm name. Algorithm name refers to the algorithm described 
   in this document. The requirement to have this name registered with 
   IANA is specified. 

   In section 5.1, Type should allow for the use of future optional 
   algorithms with regard to SeND. The default value is CGA. For this 
   algorithm and other algorithms, (such as SSAS [4, 5], there needs to 
   be a new number sequentially. 

   IANA also needs to define a numeric algorithm number for ECC. The 
   similar way that is defined for RSA. 




12.  Appendix 


12.1.  A Sample Key Storage For CGA-TSIG 

   create table cgatsigkeys (
   id		INT auto_increment,
   pubkey	VARCHAR(300),
   primary key(id)
   );
   create table cgatsigips (
   id		INT auto_increment,
   idkey	INT,
   IP		VARCHAR(20),
   FOREIGN KEY (idkey) REFERENCES cgatsigkeys(id)
   primary key(id)
   );
   CGA-TSIG tables on mysql backend database

12.2.  Stored parameters in the node 

   Here is a sample format of stored parameters in the node. For 
   example, the modifier is stored as bytes and each byte might be 
   separated by a comma (for example : 284,25,14,...). Algorithmtype is 
   the algorithm used in signing the message. Zero is the default 
   algorithm for RSA. Secval is the CGA Sec value that is, by default, 
   one. GIP is the global IP address of this node (for example: 
   2001:abc:def:1234:567:89a). oGIP is the old IP address of this node, 
   before the generation of the new IP address. Keys contains the path 
   where the CGA-TSIG algorithm can find the PEM format used for the 
   public/private keys (for example: /home/myuser/keys.pem ). 

   <?xml version="1.0" encoding="UTF-8"?>


Rafiee, et al.     Expires November 8, 2015                    [Page 19]

INTERNET DRAFT             New algorithms in TSIG            May 8, 2015

   <Details>
   <CGATSIG>
   <modifier value=""/>
   <algorithmtype value="1.2.840.113549.1.1.1"/>
   <secval value="1"/>
   <GIP value=""/>
   <oGIP value=""/>
   <Keys value=""/>
   </CGATSIG>
   </Details>
   XML file contains the cached DATA

12.3.  CGA Generation Script 

   Here introduces a sample CGA generation script for the nodes that 
   does not support SeND. 

   byte[] modifier;
   typedef int bool;
   #define true 1
   #define false 0
   //  length_of_digest : 8 leftmost bytes of digest.
   //this function sets sec value on the first byte of digest
   //since interface ID is only 8 bytes, it returns only 8 leftmost bytes of digest
   byte[] set_secvalue(byte[] digest,int length_of_digest);
   //this function compares the 16 by cga_sec_value bits of digest to zero
   bool compare(byte[] digest, int cga_sec_value);
   //this function executes hashing function on cga_parameters
   byte[] sha1(byte[] cga_parameters);
   //this function reads public key from a file
   byte[] read_public_key(char[] public_key_path);
   //this function increments the modifier by one
   increment(byte[] modifier);
   //this function concatenates the input values.
   byte[] concat(byte[], byte[],....);
   //Write in a file
   CacheCGAparameters(byte[] ipv6_address, byte[] modifier, char[]
   public_key_path, int cga_sec_value, byte[] public_key_algorithm);
   //--------------main function ------------------------
   int main(char[] interface_name)
   {
   byte[] cga=cgagen("\\xxx\key.pub",prefix);
   byte[] ipv6_address=concat(prefix,cga);
   //set the CGA address on a desired interface
   setIP(ipv6_address,"eth0\0");
   CacheCGAparameters(ipv6_address,modifier,public_key_path, cga_sec_value,
   '1.2.840.113549.1.1.1');
   }
   //------------------sample function for CGA Generation--------------
   byte[] cgagen(char[] public_key_path, byte[] prefix, int cga_sec_value)
   {
   bool flag=true;
   byte[] cga;


Rafiee, et al.     Expires November 8, 2015                    [Page 20]

INTERNET DRAFT             New algorithms in TSIG            May 8, 2015

   byte[] public_key=read_public_key(public_key_path);
   modifier= randomnumber(16);
   while(flag)
   {
   //concatinate all values
   byte[] cgaparameters=concat(modifier,prefix,0,public_key);
   byte[] digest=sha1(cgaparameters);
   if(compare(digest,cga_sec_value)==false)
   increment(modifier);
   else
   flag=false;
   }
   cga=set_secvalue(digest,8);
   return cga;
   }
   //-------------Sample function for random number generator----
   //random generator explained in ra_privacy draft
   byte[] randomnumber(int length_byte)
   {
   byte[] num=new byte[length_byte];
   srand(time(NULL));
   for(int i=0;i<length_byte;i++)
   num[i]=rand() %254;
   }
   

12.4.  CGA-TSIGe (DNS privacy) 

   One possible solution to provide the encryption for DNS messages is 
   the use of a symmetric algorithm. The following sections explain this 
   process. CGA-TSIGe do this encryption step similar to TLS protocol. 
   The difference is that it encapsulate the whole DNS message and add a 
   new header while in TLS after a secure channel is established, all 
   data is sent via this secure channel. 


12.4.1.  The CGA-TSIGe DATA Structure  

   The node MUST set the Algorithm Type in TSIG RDATA to CGA-TSIGe. 
   Other sections of CGA-TSIGe DATA are similar to CGA-TSIG DATA 
   (explained in section 4.1). This section only explains the 
   differences between CGA-TSIG and CGA-TSIGe. Figure 6 shows CGA-TSIGe 
   DATA structure. 

   - Message Hash = 3-bit hashing algorithm identifier | hash (whole DNS 
   message) 

   The value of Message Hash is the concatenation of the 3 bits hashing 
   algorithm identifier with the hash of the whole DNS message (see 
   figure 4 and 5 for the whole DNS message). This is used for data 
   integrity of the packet. For SHA256, the value of hashing algorithm 
   SHOULD set to 1. For other hashing algorithms, this 3 bits SHOULD set 
   to sequential value after one. The field Message Hash Len is the 


Rafiee, et al.     Expires November 8, 2015                    [Page 21]

INTERNET DRAFT             New algorithms in TSIG            May 8, 2015

   length of Message Hash. 

   - digest_secret_key len: Length of digest_secret_key (encrypted 
   secret key) 

   - digest_secret_key = encryption of a 16 byte random number using DNS 
   server?s public key 

   +---------------------------------------+
   |             AsyAlgorithm              |
   |                                       |
   +---------------------------------------+
   |                Type                   |
   |                                       |
   +---------------------------------------+
   |             Parameter Len             |
   |              (1 byte)                 |
   +---------------------------------------+
   |             Parameters                |
   |             (variable)                |
   +---------------------------------------+
   |            Signature Len              |
   |               (1 byte)                |
   +---------------------------------------+
   |              Signature                |
   |              (variable)               |
   +---------------------------------------+
   |          Message Hash Len             |
   |              (1 byte)                 |
   +---------------------------------------+
   |            Message Hash               |
   |             (variable)                |
   +---------------------------------------+
   |          digest_secret_key Len        |
   |              (1 byte)                 |
   +---------------------------------------+
   |           digest_secret_key           |
   |             (variable)                |
   +---------------------------------------+
   Figure 6 CGA-TSIGe DATA Field

12.4.1.1.  Public Key Request 

   In the TSIG RDATA section, the Algorithm Name MUST be set to 
   'CGA-TSIGe', and the CGA-TSIGe Len field MUST be set to zero. This 
   alerts the DNS server that the other Node needs its public key for 
   encryption purposes. This format is used if a Node does not want to 
   use DNSKEY RR [RFC3757] to retrieve the public key of the DNS server. 


12.4.1.2.  Public Key Response 

   The DATA structure is similar to CGA-TSIG. There is only a flag field 


Rafiee, et al.     Expires November 8, 2015                    [Page 22]

INTERNET DRAFT             New algorithms in TSIG            May 8, 2015

   which indicates that it is a response to the public key request 
   message. 

   +---------------------------------------+
   |             AsyAlgorithm              |
   |                                       |
   +---------------------------------------+
   |                Type                   |
   |                                       |
   +---------------------------------------+
   |             Parameter Len             |
   |              (1 byte)                 |
   +---------------------------------------+
   |             Parameters                |
   |             (variable)                |
   +---------------------------------------+
   |              Signature                |
   |              (variable)               |
   +---------------------------------------+
   |            Signature Len              |
   |               (1 byte)                |
   +---------------------------------------+
   |              Signature                |
   |              (variable)               |
   +---------------------------------------+
   |         	   Flag                    |
   |             (1 bit)                   |
   +---------------------------------------+
   Figure 7 CGA-TSIGe DATA Field (public key response)

12.4.2.  Generation of CGA-TSIGe DATA  


12.4.2.1.  IPv6 Specifics 

   Nodes can securely obtain the IP address of DNS resolvers from the 
   DHCPv6 server (use SAVI-DHCP [savi-dhcp]); or from a DNS option of 
   Router Advertisement message [RFC6106] after authenticating with the 
   router via a trusted authority. The IP addresses can be generated 
   using CGA, SSAS or other mechanisms. 

   This is the same approach that a node can use for obtaining a DNS 
   server IP address during a Dynamic DNS update. 

   In case this approach is used for zone transfer, to avoid any 
   malicious update to DNS server, it is RECOMMENDED that this IP 
   address is set manually on the DNS server for the first time or cache 
   the IP address of trusted resolvers in a trusted list and randomly 
   select them in a insecure network. 


12.4.2.1.1.  Generation of Query Request Message 



Rafiee, et al.     Expires November 8, 2015                    [Page 23]

INTERNET DRAFT             New algorithms in TSIG            May 8, 2015

   1. Retrieve Public Key of DNS Server 

   To encrypt the DNS message using a symmetric algorithm for 
   performance purposes, first, a Node needs to retrieve the public key 
   of the DNS server. It is possible to use the current DNSKEY RR 
   [RFC3757] to send the public key of the DNS server. When the client 
   wants to update any records on the DNS server, it first sends a DNS 
   message asking for the public key of the DNS Server. The DNS Server 
   then answers this query and includes the public key contained in the 
   DNSKEY RR with the SEP flag set to zero (0). This indicates that it 
   is not the zone key. It is also possible to use the RR format 
   explained in sections 12.4.1.1 and 12.4.1.2 of this document. The DNS 
   server SHOULD include CGA-TSIGe DATA so that the client can verify 
   its IP address. In this case, there will be a binding between a DNS 
   Server's public key and its IP address. If the Node can verify the 
   DNS Server public key (explained below), it goes to step 2. Otherwise 
   it discards the DNS message without further action. 

   2. Obtain Required Parameters From Cache. 

   This step is the same as what is explained in section .1.3. 

   3. Generation of Secret Key 

   After a successful verification, the Node generates a 16 byte random 
   number called a secret key. The Node can use any algorithm explained 
   in [RFC4086] to generate a good randomized value. It encrypts the 
   secret key using the DNS Server?s public key. Then, the Node sets the 
   digest_secret_key in CGA-TSIGe DATA structure to this encrypted 
   secret key and set the digest_secret_key len to the length of this 
   encrypted value. Similar to CGA-TSIG, MAC Size in TSIG RDATA MUST set 
   to 0. The DNS Server knows what to do with MAC field from the 
   Algorithm Type in TSIG. 

   4. Encryption of DNS message 

   The Node uses the secret key generated in the previous step to 
   encrypt the header, zone section, prerequisite, and update section 
   for the DNS update message (see figure 8) or encrypt header, 
   question, answer, authority of a DNS Query (see figure 9). It then 
   calculates the length of a digest as a number of bytes in multiples 
   of 8. For example, if the digest is 242 bytes then 242 = (30 * 8) + 
   2. Therefore, 6 bytes are added as padding, and then 31 is placed at 
   the beginning of digest (see figure 10). If there is no padding for 
   the digest then one zero-filled byte will be added at the end of 
   digest. This allows the DNS Server to interpret this digest as a long 
   string. 

   +-----+------+--------+
   |Type |Length|Reserved|
   |1byte|1 byte| 1 byte |
   +---------------------+
   |        Header       |


Rafiee, et al.     Expires November 8, 2015                    [Page 24]

INTERNET DRAFT             New algorithms in TSIG            May 8, 2015

   |       12 bytes      |
   +---------------------+
   |  Encrypted sections |
   |   variable length   |
   +---------------------+
   |   Additional Data   |
   |   variable length   |
   +---------------------+
   Figure 8 Encrypted DNS update message
   
   +-----+------+--------+
   |Type |Length|Reserved|
   |1byte|1 byte| 1 byte |
   +---------------------+
   |        Header       |
   |       12 bytes      |
   +---------------------+
   |  Encrypted sections |
   |   variable length   |
   +---------------------+
   |   Additional Data   |
   |   variable length   |
   +---------------------+
   Figure 9 Encrypted DNS Query message
   
   +---------------------+
   |    Len of digest    |
   |     (1 byte)        |
   +---------------------+
   |        digest       |
   |   variable length   |
   +---------------------+
   Figure 10 Digest format in DNS question section
   
   The Node then adds a new header with the following data. This will 
   allow the DNS Server to process this message. CGA-TSIGe actually uses 
   the whole encrypted section as one single question followed by 
   additional data. 

   Field Sub-field Value Intrepretation
   -------------------------------------------------------
   ID             0xdb42  Response should have ID 0xdb42
   Flags           0x0100
   QR       0     It's a query
   OPCODE    0     Standard query
   TC       0     Not truncated
   RD       1     Recursion requested
   RA       0     Not meaningful for query
   Z        0     Reserved
   RCODE      0     Not meaningful for query
   QDCOUNT           0x0001 One question follows
   ANCOUNT           0x0000 No answers follow
   NSCOUNT           0x0000 No records follow


Rafiee, et al.     Expires November 8, 2015                    [Page 25]

INTERNET DRAFT             New algorithms in TSIG            May 8, 2015

   ARCOUNT           0x0001 No additional records follow
   The digest will be interpreted like the following table. 

   Data       Intrepretation
   ------------------------------------------
   0x1f       String of length 248 follows
   0x777777.. String is xxxxxx
   0x00       End of this string
   5. Generation of Message Hash 

   In a case where a DNS Server responds to anonymous queries, as in a 
   DNS Resolver scenario, the Node executes SHA256 by default on the 
   whole DNS message. This includes the additional section and the TSIG 
   RR as a part of additional section of DNS message. It then computes 
   the Message Hash Len. In this case the message does not need to be 
   signed by the Node (stub resolver) using its private key. This is 
   because the DNS Server does not expect to verify the Node and it only 
   checks for the message integrity and confidentiality. In the case a 
   message contains Message Hash, the Node MUST set the Parameters Len , 
   Signature Len, Old Pubkey Len and Old Signature Len to zero (0) and 
   it SHOULD skips steps 6 and 7. 


12.4.2.1.2.  Generation of Query Response Message 

   This is similar to generation of query request message as explained 
   in section 12.4.2.1.1. of this document. However, steps 1, 3 and 5 
   should be skipped. 

   1. Obtain Required Parameters From Cache. 

   2. Encryption of DNS message 

   Query response needs to be encrypted using a shared secret obtain 
   from the Query Request message explained in section 12.4.4. 

   3. Generation of Signature 

   This step is the same as what is explained in section 4.1.3. 


12.4.2.2.  IPv4 Scenario 

   The key pairs needs to be cached in order to generate a signature. If 
   this Node changes its IP address, it also needs to cache the old IP 
   address. Similar to the IPv6 scenario, the Node can obtain the hash 
   of (public key + IPv4) and the IPv4 address of the DNS server from a 
   DHCPv4 server. It can use [savi-dhcp]. If this Node is in unsecured 
   environment, it can manually add the hash of (public key + IPv4 
   address) of its trusted DNS server. This is especially true in the 
   Resolver scenario. The implementers SHOULD define a possibility for 
   users to change the default value for CGA-TSIGe. 



Rafiee, et al.     Expires November 8, 2015                    [Page 26]

INTERNET DRAFT             New algorithms in TSIG            May 8, 2015


12.4.2.2.1.  Generation of Query Request Message 

   1. Retrieves Public Key of DNS server 

   This is similar to IPv6 scenario. 

   2. Obtain Required Parameters From Cache. 

   This step is the same as what is explained in section 4.1.3. 

   3. Generation of Secret Key 

   4. Encryption of DNS Message 

   5. Generation of Message Hash 

   All Three are similar to IPv6 scenario. 

   6. Generation of Signature 

   This step is the same as what is explained in section 4.1.3. 


12.4.2.2.2.  Generation of Query Response Message 

   This is similar to IPv6 scenario. 

   2. Obtain Required Parameters From Cache. 

   This step is the same as what is explained in section 4.1.3. 

   1. Obtain Required Parameters From Cache. 

   2. Encryption of DNS message 

   Query response needs to be encrypted using a shared secret obtain 
   from the Query Request message explained in section 12.4.4. 

   3. Generation of Signature 

   This step is the same as what is explained in section 4.1.3. 


12.4.3.  Process of Public Key Response Message 

   This section explains the verification needed for the process of 
   public key response (The format of this message was explained in 
   section 12.4.1.2) 


12.4.3.1.  IPv6 only Scenarios 



Rafiee, et al.     Expires November 8, 2015                    [Page 27]

INTERNET DRAFT             New algorithms in TSIG            May 8, 2015

   Depends on the algorithm used by the DNS server, CGA or SSAS 
   verification process MUST be executed. 


12.4.3.2.  IPv4 only Scenarios 

   The verifier node MUST execute hashing function on (public key + IPv4 
   address) and compare this value with the value exists on its cache or 
   the value retrieved from a DNS server in a secure manner. 


12.4.4.  Process of Encrypted Query Request Message 

   When the DNS server receives the message from any node with TSIG 
   RDATA Algorithm type set to CGA-TSIGe, it executes the following 
   steps: 

   1- Retrieves The Secret Key 

   The DNS server retrieves the secret key from digest_secret_key field. 
   Secret key is a random value generated by the node (such as a stub 
   resolver) and encrypted using the public key of this DNS server 
   (section 12.4.2.1.1 explains the steps to generate and encrypt this 
   value). DNS server then decrypts this secret key using its own 
   private key. 

   2- Decrypts the DNS Message 

   The DNS server decrypts the DNS server message using this secret key 
   and the symmetric algorithm, which by default is AES. The DNS server 
   can then start the verification process explained in the next 
   section. 


12.4.5.  Process of Encrypted Query Response Message 

   When the node (like a client) receives a query response message from 
   any node with TSIG RDATA Algorithm type set to CGA-TSIGe, it executes 
   the following steps: 

   1- Retrieves The Secret Key 

   This node, itself, generated this secret key. It fetches this secret 
   key from its memory. 

   2- Decrypts the DNS Message 

   The node decrypts the query response message using this secret key 
   and the symmetric algorithm, which by default is AES. The node can 
   then start the verification process explained in the next sections. 


12.5.  Other Optional Use case scenarios 


Rafiee, et al.     Expires November 8, 2015                    [Page 28]

INTERNET DRAFT             New algorithms in TSIG            May 8, 2015


   Besides DNS privacy, secure authentication mechanism introduced in 
   this document can be used in other DNS scenario for the purpose of 
   reducing human interaction and secure Dynamic DNS updates. Minimizing 
   the amount of human interaction reduces the vulnerability to attacks 
   introduced by human errors. This is because secure authentication 
   (and prevent IP spoofing) can be seen as a base to prevent many 
   different DNS attacks such as DNS spoofing, DNS amplification, 
   Unauthorized DNS Update (DDNS), etc. For example, protecting DNS 
   servers from unauthorized update during dynamic DNS update (DDNS) is 
   an example scenario that requires human interactions for the 
   configuration of each node for a secure authentication. Manual 
   configuration of each node to enable them securely update their PTR 
   or FQDN only increases overheads on domain administrators. This is 
   because nodes might join and leave the networks or might frequently 
   change their IP addresses. Therefore, they want to update their PTR 
   or FQDN records on DNS servers accordingly. If the Dynamic Host 
   Configuration Protocol (DHCP) is in use, then the DHCP server can do 
   this update on behalf of the nodes in this network on a DNS server. 
   When Neighbor Discovery Protocol (NDP) is in use, there is no feature 
   available that allows the host process a secure update for its own 
   FQDN or PTR. Using a shared secret which is shared between many nodes 
   for secure authentication during DDNS process, similar to TSIG 
   mechanism requires the exchange of this shared secret manually 
   between these nodes. This results in repeating the key exchange 
   between many nodes (This process involves human interaction) where 
   one of these nodes are compromised due to virus or other problems. 


12.5.1.  The FQDN Or PTR Update (IPv6 only) 

   Normally the DHCPv6 server will update the client's RRs on their 
   behalf in the scenario where SeND is used as a secure NDP, the Nodes 
   will need to do this process unless a stateless DHCPv6 server is 
   available. CGA-TSIG/CGA-TSIGe can be used to give Nodes the ability 
   of doing this process themselves. In this case the clients need to 
   include the CGA-TSIG/CGA-TSIGe option to allow the DNS server to 
   verify them. The verification process is as following. 


12.5.1.1.  Verification Process 

   The verification steps are the same as those is explained in section 
   5, but removing step 4 and modifying step 5. 

   1. Verify The Signature 

   2. Check The Time Signed 

   3. Execute The CGA Verification 

   4. Verify The Public Key 



Rafiee, et al.     Expires November 8, 2015                    [Page 29]

INTERNET DRAFT             New algorithms in TSIG            May 8, 2015

   The DNS server checks if the public key retrieved from 
   CGA-TSIG/CGA-TSIGe DATA is the same as what was available in cache. 
   If no entry is found for this public key, and the FQDN or PTR is also 
   not available in the DNS server, then the DNS server will store the 
   public key of this Node and add this Node's PTR and FQDN. 


12.5.2.  DNS Zone Transfer 

   This section discusses the use of CGA-TSIGe for the secure 
   authentication and encryption of DNS messages exchanged between a 
   Master Server and a Slave Server. In the case of processing a DNS 
   zone update ([AI]XFR) for multiple DNS servers (authenticating two 
   DNS servers), there are three possible scenarios with regard to the 
   authentication process which differs from that of the authentication 
   of a Node (client) with one DNS server. This is needed for human 
   intervention. Since the zone contains important information, both DNS 
   servers MUST use CGA-TSIGe and encrypt the values. The only exception 
   is when CGA-TSIG is required for secure authentication and the data 
   encryption is handled by other protocols. 

   a. Add The DNS servers' IP address To A Slave Server Configuration 
   (IPv6 only) 

   A DNS server administrator should only manually add the IP address of 
   the Master Server to the configuration file of the Slave Server. When 
   the DNS update message is processed, the Slave Server can 
   authenticate the Master Server based on the source IP address and 
   then, prove the ownership of this address by use of the CGA-TSIGe 
   option from the TSIG RR. This scenario will be valid until the IP 
   address in any of these DNS servers, changes. 

   To automate this process, the sender's public key of the DNS Update 
   message must be saved on the other DNS server, after the source IP 
   address has been successfully verified for the first time. In this 
   case, when the sender generates a new IP address by executing the CGA 
   algorithm using the same public key, the other DNS server can still 
   verify it and add its new IP address to the DNS configuration file 
   automatically. 

   b. Retrieve Public/Private Keys From A Third Party Trusted Authority 
   (TA) (IPv6 only) 

   The message exchange option of SeND [RFC3971] may be used for the 
   retrieval of third party certificates. This may be done automatically 
   from the TA by using the Certificate Path Solicitation and 
   Certificate Path Advertisement messages. Like in section 4.2, the 
   certificate should be saved on the DNS server for later use. Whenever 
   any of those servers want to generate a new IP address, the DNS 
   update process can be accomplished without human intervention. 

   c. Store The Hash of (public key + IPv4 address) to DNS configuration 
   file (IPv4 and IPv6) 


Rafiee, et al.     Expires November 8, 2015                    [Page 30]

INTERNET DRAFT             New algorithms in TSIG            May 8, 2015


   An administrator needs to manually generate the hash of the 
   concatenation of public key with the IPv4 address of the authorized 
   node the DNS configuration file. Whenever a node wants to change its 
   IP address or public key, the DNS server can generates this value 
   automatically and compare with the old value it has and then after a 
   successful verification steps (it will be explain in next section), 
   it will replace the old hash value with the new one. 


12.5.2.1.  Verification Process 

   The verification steps are similar to section 5 of this document. 

13.  Acknowledgements

   The continual improvement of this document is as a result of the 
   helps and assistance of its supporters. 

   The authors would like to thank all those people who directly helped 
   in improving this draft and all supporters of this draft, especially 
   Ralph Droms, Andrew Sullivan, Ted Lemon, Brian Haberman, Erik 
   Nordmark, Brian Dickson, Dan Wing. The authors would like also to 
   special acknowledge the supports of NLnet Labs director and 
   researchers; Olaf Kolkman, Matthijs Mekking and their master student 
   Marc Buijsman. 

   The authors would like to express their special appreciation and 
   thanks to Tim Wicinski and Joel Halpern who spent a lot of time to 
   review, revise and improve this draft. 



14.  References

14.1.  Normative References 

   [RFC2119] Bradner, S., "Key words for use in RFCs to 
             Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 

   [RFC3972] Aura, T., "Cryptographically Generated Addresses 
             (CGA)," RFC 3972, March 2005. 

   [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, 
             "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005. 

   [RFC2119] Bradner, S., "Key words for use in RFCs to 
             Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 

   [RFC2930] Eastlake 3rd, D., "Secret Key Establishment for 
             DNS (TKEY RR)", RFC 2930, September 2000. 

   [RFC1035] Mockapetris, P., "Domain Names - Implementation 


Rafiee, et al.     Expires November 8, 2015                    [Page 31]

INTERNET DRAFT             New algorithms in TSIG            May 8, 2015

             And Specification", RFC 1035, November 1987. 

   [RFC4941] Narten, T., Draves, R., Krishnan, S., "Privacy 
             Extensions for Stateless Address Autoconfiguration in 
             IPv6", RFC 4941, September 2007. 

   [RFC2136] Vixie, P. (Editor), Thomson, S., Rekhter, Y., 
             Bound, J., "Dynamic Updates in the Domain Name System (DNS 
             UPDATE)", RFC 2136, April 1997. 

   [RFC2845] Vixie, P., Gudmundsson, O. , Eastlake 3rd, D., 
             Wellington, B., " Secret Key Transaction Authentication for 
             DNS (TSIG)", RFC 2845, May 2000. 

   [RFC6106] Jeong, J., Park, S., Beloeil, L., Madanapalli, 
             S.,"IPv6 Router Advertisement Options for DNS 
             Configuration",RFC 6106, November 2010. 

   [RFC4086] Eastlake, D., Schiller, J., and Crocker, D., 
             "Randomness Requirements for Security", BCP 106, RFC 
             4086,June 2005. 

   [RFC4055] Schaad, J., Kaliski, B., and Housley, R., 
             "Additional Algorithms and Identifiers for RSA Cryptography 
             for use in the Internet X.509 Public Key infrastructure 
             Certificate and Certificate Revocation List (CRL) Profile", 
             RFC 4055,June 2005. 

   [RFC6840] Weiler, S. and Blacka, D., "Clarifications and 
             Implementation Notes for DNS Security (DNSSEC)", RFC 
             6840,February 2013. 

   [RFC3757] Kolkman, O., Schlyter, J., and Lewis, E., "Domain 
             Name System KEY (DNSKEY) Resource Record (RR) Secure Entry 
             Point (SEP) Flag",RFC 3757,April 2004. 

14.2.  Informative References 

   [1] Aura, T., "Cryptographically Generated Addresses (CGA)", 
       Lecture Notes in Computer Science, Springer, vol. 2851/2003, pp. 
       29-43, 2003. 

   [2] Montenegro, G. and Castelluccia, C., "Statistically Unique 
       and Cryptographically Verifiable (SUCV) Identifiers and 
       Addresses," ISOC Symposium on Network and Distributed System 
       Security (NDSS 2002), the Internet Society, 2002. 

   [3] AlSa'deh, A., Rafiee, H., Meinel, C., "IPv6 Stateless Address 
       Autoconfiguration: Balancing Between Security, Privacy and 
       Usability". Lecture Notes in Computer Science, Springer(5th 
       International Symposium on Foundations & Practice of Security 
       (FPS). October 25 - 26, 2012 Montreal, QC, Canada), 2012. 



Rafiee, et al.     Expires November 8, 2015                    [Page 32]

INTERNET DRAFT             New algorithms in TSIG            May 8, 2015

   [4] Rafiee, H., Meinel, C., "A Simple Secure Addressing 
       Generation Scheme for IPv6 AutoConfiguration (SSAS)". Work in 
       progress, http://tools.ietf.org/html/draft-rafiee-6man-ssas, 
       2013. 

   [5] Rafiee, H., Meinel, C., "A Simple Secure Addressing Scheme 
       for IPv6 AutoConfiguration (SSAS)", 11th International conference 
       on Privacy, Security and Trust (IEEE PST), 2013. 

   [6] AlSa'deh, A., Rafiee, H., Meinel, C., "Cryptographically 
       Generated Addresses (CGAs): Possible Attacks and Proposed 
       Mitigation Approaches," in proceedings of 12th IEEE International 
       Conference on Computer and Information Technology (IEEE CIT'12), 
       pp.332-339, 2012. 

   [7] Rafiee, H., Meinel, C., "A Secure, Flexible Framework for DNS 
       Authentication in IPv6 Autoconfiguration" in proceedings of The 
       12th IEEE International Symposium on Network Computing and 
       Applications (IEEE NCA13), 2013. 

   [savi-dhcp] Bi, J., Wu, J., Yao, G, Baker, F.,"SAVI 
               Solution for DHCP", 
               http://tools.ietf.org/html/draft-ietf-savi-dhcp-23, April 
               2014 

   [dns-privacy] Bortzmeyer, S., " DNS privacy 
                 considerations", 
                 https://tools.ietf.org/html/draft-ietf-dprive-problem-statement-02, 
                 August 2015 

   [dns-terms] Hoffman, P., Sullivan, A., Fujiwara, K., "DNS 
               Terminology", 
               https://tools.ietf.org/html/draft-hoffman-dns-terminology-01, 
               July 2015 





















Rafiee, et al.     Expires November 8, 2015                    [Page 33]

INTERNET DRAFT             New algorithms in TSIG            May 8, 2015

Authors' Addresses

      Hosnieh Rafiee
      http://www.rozanak.com
      Munich, Germany
      Phone: +49 (0)162 204 74 58
      E-mail: ietf@rozanak.com


      Christoph Meinel
      Hasso-Plattner-Institute
      Prof.-Dr.-Helmert-Str. 2-3
      Potsdam, Germany
      Email: meinel@hpi.uni-potsdam.de







































Rafiee, et al.     Expires November 8, 2015                    [Page 34]