DNS Extensions H. Rafiee
INTERNET-DRAFT Huawei TECHNOLOGIES Duesseldorf GmbH
Updates RFC 2845 (if approved) M. v. Loewis
Intended Status: Standards Track C. Meinel
Hasso Plattner Institute
Expires: April 24, 2015 October 24, 2014
CGA-TSIG/e: Algorithms for Secure DNS Authentication and Optional DNS
Confidentiality
<draft-rafiee-intarea-cga-tsig-11.txt>
Abstract
This document describes a new mechanism for secure DNS authentication
and DNS data confidentiality in various scenarios. The purpose of
this document is to reduce human interaction during different DNS
scenarios such as the communications of resolvers to stub resolvers,
recursive resolvers to Authoritative Name Server, Dynamic DNS
updates, (especially updating PTR and FQDN records). The aim of this
document is to assist DNSSEC to protect the last miles of Internet
easier. 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 April 24, 2015.
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. This document is subject to
Rafiee, et al. Expires April 24, 2015 [Page 1]
INTERNET DRAFT New algorithms in TSIG October 24, 2014
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
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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Overview of CGA-TSIG/e Mechanisms . . . . . . . . . . . . 5
2.2. Problem Statement . . . . . . . . . . . . . . . . . . . . 7
2.2.1. Transaction SIGnature (TSIG) . . . . . . . . . . . . 7
2.2.2. DNS Security Extension (DNSSEC) . . . . . . . . . . . 7
2.2.3. SIG0 . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2.4. Pros and Cons with DNS privacy proposals . . . . . . 8
2.2.4.1. Private DNS (JSON): . . . . . . . . . . . . . . . 8
2.2.4.2. DNS over DTLS (DNSoD): . . . . . . . . . . . . . 9
2.2.4.3. DNS using TLS (DTLS): . . . . . . . . . . . . . . 9
2.2.4.4. DNS over TLS: . . . . . . . . . . . . . . . . . . 9
3. Conventions Used In This Document . . . . . . . . . . . . . . 10
4. Algorithm Overview . . . . . . . . . . . . . . . . . . . . . 10
4.1. CGA-TSIG . . . . . . . . . . . . . . . . . . . . . . . . 10
4.1.1. The CGA-TSIG DATA Structure . . . . . . . . . . . . 10
4.1.2. CGA-TSIG DATA . . . . . . . . . . . . . . . . . . . 12
4.1.2.1. IPv6 Specific Data . . . . . . . . . . . . . . . 13
4.1.2.2. IPv4 Specific Data . . . . . . . . . . . . . . . 13
4.1.3. Generation of CGA-TSIG DATA . . . . . . . . . . . . 14
4.2. CGA-TSIGe . . . . . . . . . . . . . . . . . . . . . . . . 15
4.2.1. The CGA-TSIGe DATA Structure . . . . . . . . . . . . 15
4.2.1.1. Public Key Request . . . . . . . . . . . . . . . 17
4.2.1.2. Public Key Response . . . . . . . . . . . . . . . 17
4.2.2. Generation of CGA-TSIGe DATA . . . . . . . . . . . . 18
4.2.2.1. IPv6 Specifics . . . . . . . . . . . . . . . . . 18
4.2.2.1.1. Generation of Query Request Message . . . . . 18
4.2.2.1.2. Generation of Query Response Message . . . . 20
4.2.2.2. IPv4 Scenario . . . . . . . . . . . . . . . . . . 21
4.2.2.2.1. Generation of Query Request Message . . . . . 21
4.2.2.2.2. Generation of Query Response Message . . . . 22
4.2.3. Process of Public Key Response Message . . . . . . . 22
4.2.3.1. IPv6 only Scenarios . . . . . . . . . . . . . . . 22
4.2.3.2. IPv4 only Scenarios . . . . . . . . . . . . . . . 22
4.2.4. Process of Encrypted Query Request Message . . . . . 22
4.2.5. Process of Encrypted Query Response Message . . . . . 23
5. General Verification Steps . . . . . . . . . . . . . . . . . 23
6. CGA-TSIG/CGA-TSIGe Use Case Scenarios . . . . . . . . . . . . 25
6.1. The FQDN Or PTR Update (IPv6 only) . . . . . . . . . . . 25
6.1.1. Verification Process . . . . . . . . . . . . . . . . 26
Rafiee, et al. Expires April 24, 2015 [Page 2]
INTERNET DRAFT New algorithms in TSIG October 24, 2014
6.2. DNS Resolving Scenario (stub to recursive) . . . . . . . 26
6.2.1. Client Verification Process (CGA-TSIGe only) . . . . 27
6.2.2. Resolver Verification Process . . . . . . . . . . . . 28
6.3. DNS Resolving Scenario (Authoritative NS to Recursive NS) 29
7. SeND Is Not Supported (IPv6 only) . . . . . . . . . . . . . . 29
8. CGA-TSIG/e Attack Protections . . . . . . . . . . . . . . . . 30
8.1. IP Spoofing . . . . . . . . . . . . . . . . . . . . . . 30
8.2. Resolver Configuration Attack . . . . . . . . . . . . . . 30
8.3. Exposing A Shared Secret . . . . . . . . . . . . . . . . 30
8.4. Replay Attack . . . . . . . . . . . . . . . . . . . . . 30
8.5. Data Confidentiality . . . . . . . . . . . . . . . . . . 31
9. Update to TSIG Specification . . . . . . . . . . . . . . . . 31
10. Security Considerations . . . . . . . . . . . . . . . . . . . 31
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
12. Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . 32
12.1. A Sample Key Storage For CGA-TSIG . . . . . . . . . . . 32
12.2. Stored parameters in the node . . . . . . . . . . . . . 33
12.3. CGA Generation Script . . . . . . . . . . . . . . . . . 33
12.4. Other Optional Use case scenarios . . . . . . . . . . . 35
12.5. DNS Zone Transfer . . . . . . . . . . . . . . . . . . . 35
12.5.1. Verification Process . . . . . . . . . . . . . . . . 36
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 36
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 36
14.1. Normative . . . . . . . . . . . . . . . . . . . . . . . . 36
14.2. Informative . . . . . . . . . . . . . . . . . . . . . . . 37
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 39
Rafiee, et al. Expires April 24, 2015 [Page 3]
INTERNET DRAFT New algorithms in TSIG October 24, 2014
1. Terminology
The terms used in this document have the following standard meaning:
- Bot: a malicious program that is installed on a node and allows an
attacker to control some functions of that node to send malicious
messages.
- Name Server: A server that supports DNS service.
- Recursive Name Server: A Name Server that responds to all queries.
- Stub Resolver: A DNS resolver that is unable to resolve queries
recursively, and relies on a Recursive DNS Server to resolve queries.
- Authoritative Name Server: Provides answers to DNS queries that it
contains in its system configuration.
There are two types of Authoritative Name Servers:
1. Master Server (Primary): A Master Server stores the original
copies of all zone records. Each Slave Server gets updated via a
special automatic updating mechanism within the DNS protocol. All
Slave Servers maintain identical copies of the master records.
2. Slave Server (Secondary): A Slave Server is an exact replica of
the master server.
- Root Name Server: An Authoritative Name Server for the root domain
(i.e., '.' (dot))
- Client: a client can be any computer (server, laptop, etc) that
only supports stub DNS servers and not other DNS services. It can be
a mail server, web server or a laptop computer.
- Node: a node can be anything such as a client, a DNS server
(resolver, authoritative) or a router.
- Host: all nodes except routers
2. Introduction
Protecting stub resolvers (clients) from spoofed DNS messages and
fake DNS resolvers requires manual configuration of each stub
resolvers with a list of trusted anchors so that DNSSEC can be used
and work to protect the nodes. Introducing a list of trusted anchors
to the clients is not easy and requires human interaction,
especially, when the clients are dynamic in the network or in public
networks where clients are anonymous.
Furthermore, protecting DNS servers from unauthorized update during
Rafiee, et al. Expires April 24, 2015 [Page 4]
INTERNET DRAFT New algorithms in TSIG October 24, 2014
dynamic DNS update (DDNS) is another scenario that requires human
interactions for the configuration of each node for a secure
authentication during DNS update. Manual configuration only increases
overheads on domain administrators. This is because nodes join and
leave the networks or 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. However, DHCP alone
cannot provide the necessary secure authentication for the nodes and
other monitoring approaches are needed. 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.
Besides, 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).
To address these existing problems with TSIG, as well as considering
DNS data protection where it is needed (Data confidentiality),
considering different factors such ? automation (minimizing human
interaction); secure authentication; performance; encryption, and to
secure the last miles of Internet where DNSSEC cannot easily handle
this protection, this document proposes two algorithms -- one is for
secure authentication that is called CGA-TSIG and one for both secure
authentication and DNS data encryption (DNS privacy) that is called
CGA-TSIGe. In DNS privacy, this document 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. These algorithms support both IPv4 and IPv6 enabled
network and considered as new algorithms in the TSIG Resource Record
(RR).
2.1. Overview of CGA-TSIG/e Mechanisms
The purpose of CGA-TSIG and CGA-TSIGe is to minimize the human
intervention required to accomplish a shared secret or key exchange
(automation as much as possible), secure authentication, with the end
result of providing data confidentiality to prevent DNS spoofing.
Minimizing the amount of human intervention reduces the vulnerability
to attacks introduced by human errors. As explained earlier,
CGA-TSIG/e can be used to assist DNSSEC server in last mile of
Rafiee, et al. Expires April 24, 2015 [Page 5]
INTERNET DRAFT New algorithms in TSIG October 24, 2014
Internet. CGA-TSIG/e supports both IPv4 and IPv6 scenarios. 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. For example,
in DNS stub resolver to resolver scenario, CGA-TSIG provides this
secure authentication by receiving the IP address of a DNS resolver
via an option from a secure Router Advertisement (RA) or from DHCPv6
server that is protected via SAVI approaches [savi-dhcp]. When it
(client) wants to resolve a query, it sends a DNS query message by
only setting algorithm type to ?CGA-TSIG? without signing this
message or adding any more information. This is because resolver does
not need to verify the client and a client can be anonymous. If
resolvers supports CGA-TSIG algorithm, then it sends a DNS query
response message by setting algorithm type to ?CGA-TSIG?, include
required parameters such as its public key in CGA-TSIG data (to be
verifiable on client), sign this message and submit it. When the
client receives this message, since there is a binding between this
public key and the IP address of the resolver, by verifying the
signature, the client makes sure that this public key belongs to the
target resolver. In other word, public key of the resolver is sent in
a same message as a DNS query (no separate message is required). In
case of DNS confidentiality (CGA-TSIGe), if this client haven?t
already cached the public key of the resolver, it sends an empty DNS
query message by only setting the algorithm type to ?CGA-TSIGe?. Then
the resolver knows that it should submit its public key to the
client. Since this binding exists, client can use the public key of
the DNS resolver to exchange a random value (called shared key). Then
DNS resolver uses AES or other secure symmetric algorithm to encrypt
all DNS message with this random value received from this client.
In case the network is not secure, user can easily introduce the IP
address of trusted resolver (or select home resolver from the list of
trusted resolvers in its computer).
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. If the network is not reliable, then this hash
value can be introduced once manually to the stub resolver. The other
option is that when the client receives the IP address or hash of
(IPv4 + public key) securely from a secure DHCP server or an option
in RA message, it caches this value in a list of trusted resolver
(called trusted list). Whenever there is no trusted resolver
available (like public network), the implementation can provide a way
for the user to select one of the trusted resolver stored in this
trusted list or it can be some random selection mechanisms. This will
avoid any manual configuration for the user. However, if this trusted
list is empty and the network is not reliable, the only way to
provide this reliability is to introduce the DNS server?s IP address
Rafiee, et al. Expires April 24, 2015 [Page 6]
INTERNET DRAFT New algorithms in TSIG October 24, 2014
manually. Similar to IPv6 scenario, the public key is sent by the
resolver in a DNS query response message. When this client resolves
any query response, it compare the hash of (resolver?s source IP
address + public key) with what is available on its own and if there
is a match, it verifies the resolver and accepts the message. In case
of DNS confidentiality (CGA-TSIGe), the same approach that is
explained in the prior paragraph can be in use. The detail steps for
these scenarios are explained in next sections.
2.2. Problem Statement
There are several different methods where DNS records (during DDNS
processes) on a DNS server can become compromised. Two examples of
methods are DNS Spoofing; Unauthorized DNS Update. There are also
several different methods where harm user?s privacy or poison user?s
devices caches (Stub resolver?s cache). Some examples of methods are
Resolver Source IP Spoofing; User Privacy Attack; and Human
Intervention.
The following sections only focus on the problem with current
available solutions.
2.2.1. Transaction SIGnature (TSIG)
- No protection against IP spoofing and DNS amplification
- Not scalable and applicable for specific scenarios. Currently there
is little deployment of TSIG for resolver authentication with
clients. One reason is that resolvers respond to anonymous queries
and can be located in any part of the network.
- Offline exchange of shared secrets. For each group of hosts there
needs to be one shared secret and the administrator will need to
manually add it to the DNS configuration file for each of these
hosts. When this shared secret is leaked, it makes it necessary to
repeat this manual share key exchange process. It will also have to
be invoked in the case where any of these hosts needs to change their
IP addresses, such as privacy issues explained in RFC4941 [RFC4941],
or when moving networks, etc. The manual TSIG process for the
exchange of shared secrets makes it difficult to configure each new
client with the shared secret of a DNS server like a resolver.
- Does not easily protect DNS data confidentiality. TSIG provides the
node with transaction level authentication and it is not used for
encrypting the content of DNS messages.
2.2.2. DNS Security Extension (DNSSEC)
- Offline generation of the signature and no support for DNS privacy
Rafiee, et al. Expires April 24, 2015 [Page 7]
INTERNET DRAFT New algorithms in TSIG October 24, 2014
DNSSEC [RFC6840] needs manual step for the configuration. For
instance, in case a DNSSEC needs to sign the zone offline (However
there are new efforts to automate this process). It is also needed
that the DNSSEC verifier node to be configured with the list of root
trusted anchors. Therefore, it is not scalable to end users since it
is not easy to do this configuration and checkup. This makes it
difficult to use it for the authentication of stub resolver to
recursive resolver scenarios (last miles of Internet) where anonymous
nodes need to verify a resolver. (This is what this draft aims to
address and assists DNSSEC in this step)
2.2.3. SIG0
- Not scalable and does not support automation (key management
problem)
- No protection against IP spoofing and DNS amplification
- Does not support DNS privacy
2.2.4. Pros and Cons with DNS privacy proposals
To address DNS privacy, there are currently some proposals available.
This section only compares CGA-TSIGe with these proposals by
considering some factors ? change on DNS protocol, performance,
Attacks (MITM), automation and authentication. This is because most
of these proposals need to change DNS protocol. But CGA-TSIGe kept
this change in a minimal level. In other words, for using the
CGA-TSIGe, one only needs to register these algorithms with IANA.
2.2.4.1. Private DNS (JSON):
Private DNS [private-dns] is one of privacy approaches that uses TLS
and consider using JSON. To establish a secure communications, many
messages needs to back and forth because the assumption is that a
node itself needs to verify the TLS certificate.
- Might not have good performance (number of messages exchanged to
establish this secure communication)
- Needs a change on DNS protocol since it uses TLS and JSON
- IP spoofing and MITM might be possible only when there is no CA or
predefined Trusted Anchors (TA) so that it makes it possible for an
attacker intercepts this communication at the beginning of TLS
establishment. This approach is supposed to provide protection for a
recursive resolver. Certificate is usually provided for a domain name
but there is no binding between this domain and the IP address of
this resolver. If this certificates was signed by a CA, this binding
is not necessary as an attacker does not have the private key of a
Rafiee, et al. Expires April 24, 2015 [Page 8]
INTERNET DRAFT New algorithms in TSIG October 24, 2014
node. When this CA is not available or a node was not
pre-reconfigured with a list of TAs, an attacker has a chance to
intercept this communication at the beginning of establishment and
forge the identity of this DNS resolver.
2.2.4.2. DNS over DTLS (DNSoD):
DNSoD [dnsod] uses DTLS [RFC6347]. DTLS is quite similar to TLS but
works on UDP. The disadvantages of this approach are as follows:
- IP spoofing and MITM might be possible only when the attacker
intercepts this communication at the beginning of TLS establishment
(as explained in private DNS section). The document suggests having a
list of IP addresses and domain names of trusted nodes. But there is
no binding between these IP addresses and trusted node?s domain name.
So, if an attacker is inside this network, he can spoof the IP
address of one of these trustees. When there is no trusted server
available, then there is no solution offered while CGA-TSIG does not
have this problem.
2.2.4.3. DNS using TLS (DTLS):
DNS using TLS (DTLS) [dtls] is another proposal that uses TLS for a
secure communication. The disadvantages of this approach are as
follows:
- Need to change on DNS protocol since it uses TLS as an encryption
mechanism. However there is explanation of how to handle this process
in case DNS server or client does not support it.
- IP spoofing and MITM might be possible only when the attacker
intercepts this communication at the beginning of TLS establishment
(as explained in private DNS section).
2.2.4.4. DNS over TLS:
Stub resolver to resolver authentication [dnstlsstub] is another
proposal that uses opportunistic encryption and similar to DTLS, uses
TLS for secure communications. The disadvantages of this approach are
as follows:
- Use different port than DNS port that is 443. So it needs to change
DNS protocol
- IP spoofing and MITM might be possible only when the attacker
intercepts this communication at the beginning of TLS establishment
(as explained in private DNS section.
- There is no practical authentication approach offered by this
mechanisms and the assumption is that the other services provide this
Rafiee, et al. Expires April 24, 2015 [Page 9]
INTERNET DRAFT New algorithms in TSIG October 24, 2014
authentication. So, it is vulnerable to active attacks. It also
cannot protect the node against passive attacks. It is because a
surveillance actor has access to the whole traffic and can sniff the
traffic initiated from certain network or node. So the content of
that encrypted message is not hidden. This actor already knows the
content and encryption wasn?t helpful.
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.
4. Algorithm Overview
The following sections explain the CGA-TSIG 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
Rafiee, et al. Expires April 24, 2015 [Page 10]
INTERNET DRAFT New algorithms in TSIG October 24, 2014
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 section 4.2) 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 |
| |
+---------------------------------------+
| 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) |
Rafiee, et al. Expires April 24, 2015 [Page 11]
INTERNET DRAFT New algorithms in TSIG October 24, 2014
+---------------------------------------+
| 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) |
+---------------------------------------+
| IP Tag * |
| (variable) |
+---------------------------------------+
| Parameters Len |
| (1 byte) |
+---------------------------------------+
| Parameters * |
| (variable) |
+---------------------------------------+
| Signature Len |
| (1 bytes) |
+---------------------------------------+
| Signature |
| (variable) |
+---------------------------------------+
| Old Pubkey Len |
| (1 byte) |
+---------------------------------------+
| old Pubkey |
| (variable) |
+---------------------------------------+
| Old Signature Len |
| (1 byte) |
+---------------------------------------+
| Old 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.
Rafiee, et al. Expires April 24, 2015 [Page 12]
INTERNET DRAFT New algorithms in TSIG October 24, 2014
- Type: Name of algorithm
- IP Tag: Tag used to identify the IP address
- Parameters Len: Length of parameters
- Signature Len: Length of public key cryptography signature
- Signature: Please refer to section 4.1.3 of this document
- Old Pubkey Len: Length of old public key field
- Old Pubkey: Old public key in ASN.1 DER format (same format as
public key)
- Old Signature Len: Length of old signature field
- Old Signature: Old signature generated by old public key.
The IP Tag is one of the old IP addresses of the Node. A client's
public key can be associated with several IP addresses on a server.
The DNS server SHOULD store the IP addresses and the public keys to
indicate their association. If a client wants to add RRs by using a
new IP address, then the IP tag field will be zeroed out. The server
will then store the new IP address that was passed to it in storage.
If the client wants to replace an existing IP address in a DNS Server
with a new one, then the IP Tag field will be populated with the IP
address which is to be replaced. The DNS server will then look for
the IP address referenced by the IP tag stored and replace it with
the new one. This enables the client to update his own RRs using
multiple IP addresses while, at the same time, giving him the ability
to change IP addresses. If a Node changes its public key, then it
MUST add the old public key to the Old Pubkey field. It MUST also
retrieve the current time from the Time Signed field, sign it using
the old private key, and then add the signature to the old signature
field. This enables the verifier node to authenticate a host with a
new public key. The verification steps are explained in detail in
sections 5, 6.1.1, 6.2.1 and 6.2.2.
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. IP Tag for IPv6 is
16 octets.
4.1.2.2. IPv4 Specific Data
Rafiee, et al. Expires April 24, 2015 [Page 13]
INTERNET DRAFT New algorithms in TSIG October 24, 2014
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. If this node changes its IP address, it also needs to
cache the old IP address.
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)
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 |
Rafiee, et al. Expires April 24, 2015 [Page 14]
INTERNET DRAFT New algorithms in TSIG October 24, 2014
+---------------------+
| 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.)
3. Generate Old Signature
If the nodes generated new key pairs, they need to add the old public
key, signed by the old private key, to the CGA-TSIG DATA. A node will
sign the new public key with the old private key, and then will add
the contents of this signature to the old signature field of CGA-TSIG
DATA. This step MUST be skipped when the node did not generate new
key pairs.
4.2. CGA-TSIGe
One possible solution to provide the DNS server with data
confidentiality during DNS update or other DNS query processes is the
use of symmetric encryption with CGA-TSIG that is called CGA-TSIGe.
4.2.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. This
Rafiee, et al. Expires April 24, 2015 [Page 15]
INTERNET DRAFT New algorithms in TSIG October 24, 2014
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
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 |
| |
+---------------------------------------+
| IP tag |
| (16 bytes) |
+---------------------------------------+
| Parameter Len |
| (1 byte) |
+---------------------------------------+
| Parameters |
| (variable) |
+---------------------------------------+
| Signature Len |
| (1 byte) |
+---------------------------------------+
| Signature |
| (variable) |
+---------------------------------------+
| old pubkey Len |
| (1 byte) |
+---------------------------------------+
| old pubkey |
| (variable) |
+---------------------------------------+
| old Signature Len |
| (1 byte) |
+---------------------------------------+
| old Signature |
| (variable) |
Rafiee, et al. Expires April 24, 2015 [Page 16]
INTERNET DRAFT New algorithms in TSIG October 24, 2014
+---------------------------------------+
| Message Hash Len |
| (1 byte) |
+---------------------------------------+
| Message Hash |
| (variable) |
+---------------------------------------+
| digest_secret_key Len |
| (1 byte) |
+---------------------------------------+
| digest_secret_key |
| (variable) |
+---------------------------------------+
Figure 6 CGA-TSIGe DATA Field
4.2.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.
4.2.1.2. Public Key Response
The DATA structure is similar to CGA-TSIG. There is only a flag field
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 |
Rafiee, et al. Expires April 24, 2015 [Page 17]
INTERNET DRAFT New algorithms in TSIG October 24, 2014
| (1 bit) |
+---------------------------------------+
Figure 7 CGA-TSIGe DATA Field (public key response)
4.2.2. Generation of CGA-TSIGe DATA
4.2.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 unsecure network.
4.2.2.1.1. Generation of Query Request Message
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 4.2.1.1 and 4.2.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 5.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
Rafiee, et al. Expires April 24, 2015 [Page 18]
INTERNET DRAFT New algorithms in TSIG October 24, 2014
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 |
| 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
+---------------------+
Rafiee, et al. Expires April 24, 2015 [Page 19]
INTERNET DRAFT New algorithms in TSIG October 24, 2014
| 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
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.
4.2.2.1.2. Generation of Query Response Message
This is similar to generation of query request message as explained
Rafiee, et al. Expires April 24, 2015 [Page 20]
INTERNET DRAFT New algorithms in TSIG October 24, 2014
in section 4.2.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 4.2.4.
3. Generation of Signature
This step is the same as what is explained in section 4.1.3.
4. Generation of Old Signature
This step is the same as what is explained in section 4.1.3.
4.2.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.
4.2.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.
Rafiee, et al. Expires April 24, 2015 [Page 21]
INTERNET DRAFT New algorithms in TSIG October 24, 2014
7. Generation of Old Signature
This step is the same as what is explained in section 4.1.3.
4.2.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 4.2.4.
3. Generation of Signature
This step is the same as what is explained in section 4.1.3.
4. Generation of Old Signature
This step is the same as what is explained in section 4.1.3.
4.2.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 4.2.1.2)
4.2.3.1. IPv6 only Scenarios
Depends on the algorithm used by the DNS server, CGA or SSAS
verification process MUST be executed.
4.2.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.
4.2.4. Process of Encrypted Query Request Message
When the DNS server receives the message from any node with TSIG
Rafiee, et al. Expires April 24, 2015 [Page 22]
INTERNET DRAFT New algorithms in TSIG October 24, 2014
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 4.2.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.
4.2.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.
5. General Verification Steps
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-TSIGe DATA should be verified. This
Rafiee, et al. Expires April 24, 2015 [Page 23]
INTERNET DRAFT New algorithms in TSIG October 24, 2014
can be done by retrieving the public key and signature from CGA-TSIGe
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
configuration. If they are the same, the Update Message should be
processed, otherwise, go to step 5.
5. Generate The Hash of (Old Public Key + IPv4 Address) (IPv4 only)
If the Old Public Key Length is zero, then skip this step and discard
the DNS update message. If the Old Public Key Length is not zero,
then the DNS server retrieves the hashing algorithm Type from the
CGA-TSIGe DATA structure. It then concatenates the following values:
Digest_old = hash (Old Public Key | IP address of the update
requester)
Rafiee, et al. Expires April 24, 2015 [Page 24]
INTERNET DRAFT New algorithms in TSIG October 24, 2014
Where hash is the SHA256 algorithm (by default) or another algorithm
identified in Type section of CGA-TSIGe DATA. It then compares
digest_old with the hash value available in the DNS configuration. If
they are the same, the Update Message should be processed, otherwise,
go to step 8.
6. 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.
7. Verify The Public Key (IPv6 only)
The DNS server checks whether or not the public key retrieved from
CGA-TSIGe 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.
8. Verify The Old Public Key (IPv4 and IPv6)
If the Old Public Key Length is zero, skip this step and discard the
DNS update message. If the Old Public Key Length is not zero, then
the DNS server will retrieve the Old Public Key from CGA-TSIGe DATA
and check to see if it is the same as what was saved in the DNS
server's cache. If they are the same, execute step 6, otherwise
discard the message.
7. Verify The Old Signature (IPv4 and IPv6)
The Old Signature contained in CGA-TSIGe DATA should be verified.
This can be done by retrieving the Old Public Key and the Old
Signature from CGA-TSIGe DATA and then using this Old Public Key to
verify the Old Signature. If the verification is successful, the
Update Message should be processed and the New Public Key should be
replaced with the Old Public Key in the DNS server. If the
verification process fails, discard the message.
6. CGA-TSIG/CGA-TSIGe Use Case Scenarios
6.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.
Rafiee, et al. Expires April 24, 2015 [Page 25]
INTERNET DRAFT New algorithms in TSIG October 24, 2014
6.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
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. Otherwise
if any PTR is available, and the Node IP tag is empty, or there is
currently another public key associated with the Node's FQDN, then
the update will be skipped. Otherwise, if the Old Public Key Length
is not zero, go to step 5.
5. Verify The Public Key
6. Verify The Old Public Key
7. Verify The Old Signature
6.2. 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, then it needs
to set the Algorithm Type to CGA-TSIGe and follows the step explained
in section 4.2.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.
+----------------+ +----------------+
Rafiee, et al. Expires April 24, 2015 [Page 26]
INTERNET DRAFT New algorithms in TSIG October 24, 2014
| DNS Resolver | | DNS client |
| | Ask for public key | |
| | <------------------- | |
| | Here you are | |
| | -------------------> | |
| | | Verification |
| | | explained in |
| | | section 4.2.3 |
| | | |
| | | Generation of |
| | | Query request |
| | |set message hash|
| | |explained in |
| | |section 4.2.2 |
| | Encrypted DNS message| |
| | <------------------- | |
| Verification | | |
| explained in | | |
| section 6.2.1| | |
| | | |
| DNS message | | |
| decryption | | |
| explained in | | |
| section 4.2.4| | |
| Encrypt Query| | |
| response | | |
| explained in | | |
| section 4.2.2| | |
| |Encrypted Query response| |
| | -------------------> | |
| | | Verification |
| | | explained in |
| | | section 6.2.2 |
| | | |
| | | DNS message |
| | | decryption |
| | | explained in |
| | | section 4.2.5 |
+----------------+ +----------------+
Figure 11. DNS resolving scenario using CGA-TSIGe
(Data confidentiality and secure authentication)
6.2.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.
Rafiee, et al. Expires April 24, 2015 [Page 27]
INTERNET DRAFT New algorithms in TSIG October 24, 2014
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.2.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
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.
Rafiee, et al. Expires April 24, 2015 [Page 28]
INTERNET DRAFT New algorithms in TSIG October 24, 2014
7. Verify The Old Public Key (IPv4 and IPv6)
If the Old Public Key Length is zero (0), discard this message
without further action. If the Old Public Key Length is not zero(0),
then the host will retrieve the Old Public Key from
CGA-TSIG/CGA-TSIGe DATA and will check whether or not it is the same
as what was saved in the host's storage where the Public Keys and IP
addresses are stored. If it is the same, then step 8 will be
executed.
8. Verify The Old Signature (IPv4 and IPv6)
The Old Signature contained in CGA-TSIG/CGA-TSIGe DATA can be
verified by retrieving the Old Public Key and Old Signature from
CGA-TSIG/CGA-TSIGe DATA and then using this Old Public Key to verify
the Old Signature. If the verification is successful, the DNS Message
should be processed and the New Public Key should be replaced with
the Old Public Key of the Resolver in the host. If the verification
process fails, then the message will be discarded.
6.3. 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
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 4.2.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 4.2. The Node SHOULD skip the first section of the
verification processes explained in section 5, section 6.1.1, section
6.2.1, and section 6.2.2.
In the second scenario, as explained in section 4.1.3 (step 1), it is
Rafiee, et al. Expires April 24, 2015 [Page 29]
INTERNET DRAFT New algorithms in TSIG October 24, 2014
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 4.1.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
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
Rafiee, et al. Expires April 24, 2015 [Page 30]
INTERNET DRAFT New algorithms in TSIG October 24, 2014
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
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
Rafiee, et al. Expires April 24, 2015 [Page 31]
INTERNET DRAFT New algorithms in TSIG October 24, 2014
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.
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
Rafiee, et al. Expires April 24, 2015 [Page 32]
INTERNET DRAFT New algorithms in TSIG October 24, 2014
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"?>
<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
Rafiee, et al. Expires April 24, 2015 [Page 33]
INTERNET DRAFT New algorithms in TSIG October 24, 2014
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;
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;
}
Rafiee, et al. Expires April 24, 2015 [Page 34]
INTERNET DRAFT New algorithms in TSIG October 24, 2014
12.4. Other Optional Use case scenarios
12.5. 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)
An administrator needs to manually generate the hash of the
Rafiee, et al. Expires April 24, 2015 [Page 35]
INTERNET DRAFT New algorithms in TSIG October 24, 2014
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.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
And Specification", RFC 1035, November 1987.
Rafiee, et al. Expires April 24, 2015 [Page 36]
INTERNET DRAFT New algorithms in TSIG October 24, 2014
[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.
[4] Rafiee, H., Meinel, C., "A Simple Secure Addressing
Generation Scheme for IPv6 AutoConfiguration (SSAS)". Work in
Rafiee, et al. Expires April 24, 2015 [Page 37]
INTERNET DRAFT New algorithms in TSIG October 24, 2014
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",
http://tools.ietf.org/html/draft-bortzmeyer-dnsop-dns-privacy-02,
April 2014
[dnsod] Reddy, T., Wing, D., Patil, P., "DNS over DTLS
(DNSoD)",http://tools.ietf.org/html/draft-wing-dnsop-dnsodtls-00,
April 2014
[private-dns] Hallam-Baker, P., "
Private-DNS",http://tools.ietf.org/html/draft-hallambaker-privatedns-00,
May 2014
[dtls] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels,
D., " Starting TLS over
DNS",http://tools.ietf.org/html/draft-hzhwm-start-tls-for-dns-00,
February 2014
[dnstlsstub] Hoffman, P., "Using TLS for Privacy Between
DNS Stub and Recursive
Resolvers",http://www.ietf.org/id/draft-hoffman-dns-tls-stub-00,
August 2014
Rafiee, et al. Expires April 24, 2015 [Page 38]
INTERNET DRAFT New algorithms in TSIG October 24, 2014
Authors' Addresses
Hosnieh Rafiee
HUAWEI TECHNOLOGIES Duesseldorf GmbH
Riesstrasse 25, 80992
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
Martin von Loewis
Hasso-Plattner-Institute
Prof.-Dr.-Helmert-Str. 2-3
Potsdam, Germany
Rafiee, et al. Expires April 24, 2015 [Page 39]