Transaction SIGnature (TSIG) using CGA Algorithm in IPv6
draft-rafiee-intarea-cga-tsig-01
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | Hosnieh Rafiee , Martin von Loewis , Christoph Meinel | ||
| Last updated | 2012-12-21 (Latest revision 2012-11-22) | ||
| Replaces | draft-rafiee-cga-tsig | ||
| RFC stream | (None) | ||
| Formats | |||
| Reviews | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-rafiee-intarea-cga-tsig-01
DNS Extensions H. Rafiee
INTERNET-DRAFT Hasso Plattner Institute
Updates RFC 2845 (if approved) M. v. Loewis
Intended Status: Standards Track Hasso Plattner Institute
C. Meinel
Hasso Plattner Institute
Expires: May 22, 2013 November 22, 2012
Transaction SIGnature (TSIG) using CGA Algorithm in IPv6
<draft-rafiee-intarea-cga-tsig-01.txt>
Abstract
The first step in the Transaction SIGnature (TSIG) (RFC 2845) process
is the generation of a shared secret to be used between a DNS server
and a host. The second step is the manual exchange of the shared
secret between the DNS server and the host. This document, CGA-TSIG,
proposes a possible way to automate the now manual process used for
the authentication of a node with a DNS server during the DNS Update
process by using the same parameters as are used in generating a
secure address in IPv6 networks, i.e., Cryptographically Generated
Addresses (CGA) (RFC 3972). CGA-TSIG facilitates this authentication
process and reduces the time needed for DNS Updates. The current
signature generation process and verification mechanism in TSIG are
thus replaced with CGA. This algorithm is added, as an extension, to
TSIG to eliminate the human intervention needed for generation and
exchange of keys between a DNS server and a host when SEcure Neighbor
Discovery (SEND) (RFC 3971) is used.
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 May 20, 2013.
Rafiee, et al. Expires May 22, 2013 [Page 1]
INTERNET DRAFT TSIG using CGA in IPv6 November 22, 2012
Copyright Notice
Copyright (c) 2012 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
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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions used in this document . . . . . . . . . . . . . . 3
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3
3.1. IP Spoofing and Reflector Attacks . . . . . . . . . . . . 4
3.2. DNS Dynamic Update Spoofing . . . . . . . . . . . . . . . 4
3.3. Resolver Configuration Attack . . . . . . . . . . . . . . 4
3.4. Shared Secret (key pairs) Exposing . . . . . . . . . . . 5
3.5. Replay attack . . . . . . . . . . . . . . . . . . . . . . 5
4. Algorithm Overview . . . . . . . . . . . . . . . . . . . . . 5
4.1. CGA Generation Algorithm . . . . . . . . . . . . . . . . 5
4.2. Modification to TSIG protocol . . . . . . . . . . . . . . 7
4.2.1. Modified TSIG Record format . . . . . . . . . . . . . 7
4.2.1.1. Generation of the DNS Update request/response . 10
4.2.1.2. Verification of the DNS Update Request/Response 12
4.2.1.3. Generation of DNS Query Response . . . . . . . . 13
4.2.1.4. Verification of DNS Query Response . . . . . . . 14
5. Security Considerations . . . . . . . . . . . . . . . . . . . 14
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
7. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 15
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
Rafiee, et al. Expires May 22, 2013 [Page 2]
INTERNET DRAFT TSIG using CGA in IPv6 November 22, 2012
1. Introduction
Transaction SIGnature (TSIG) [RFC2845] is a protocol that provides
endpoint authentication and data integrity by using one-way hashing
and shared secret keys to establish a trust relationship between two
hosts which, can be, either a client and a server, or two servers.
The TSIG keys are manually exchanged between these two hosts and they
must be maintained in a secure manner. This protocol is used to
secure a Dynamic Update or to give assurance to the slave name server
that the zone transfer is from the original master name server and
that it has not been spoofed by hackers. It does this by verifying
the signature using a cryptographic key that is shared with the
receiver.
The TSIG protocol can be extended using newly defined algorithms.
This document defines an algorithm based on Cryptographically
Generated Addresses (CGA) [RFC3972]. CGA is one of the important
options available in SEcure Neighbor Discovery (SEND) [RFC3971] that
can easily provide nodes with the necessary proof of address
ownership by providing a cryptographic binding between a host and its
IP address without the introduction of new infrastructure.
2. 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 convention aids reviewers in quickly identifying or finding the
explicit compliance requirements of this RFC.
3. Problem Statement
The DNS Update process is vulnerable to several types of spoofing
attacks, such as man in the middle, reflector , source IP spoofing,
etc. TSIG secures this process by providing the transaction level
authentication necessary by using a shared secret. The problem is
that this protocol is not widely used. The current problem with the
use of TSIG is the manual process that is required for the generation
and exchange of the shared secrets. For each paired host there needs
to be one shared secret and the administrator needs to add it
manually to the DNS configuration file for each of these hosts. So,
whenever these two hosts change their IP addresses, because of
Rafiee, et al. Expires May 22, 2013 [Page 3]
INTERNET DRAFT TSIG using CGA in IPv6 November 22, 2012
privacy issues as explained in RFC-4941 [RFC4941] or when moving to
another subnet within the same network, this manual process will need
to be invoked. The purpose of CGA-TSIG is to minimize the amount of
human intervention required to accomplish this exchange and, as a
byproduct, to reduce the processes vulnerability to attacks
introduced by human errors when SEcure Neighbor Discovery (SEND) is
used for addressing purposes.
The same problem exists between a client and a DNS resolver. When a
client sends a DNS query to a resolver, an attacker can send a
response to this client with the spoofed source IP address of this
resolver. The client checks the resolver's source IP address. If the
attacker sends its response faster than the legitimate resolver, then
the client's cache will be updated by the attacker's response. The
client does not have any way of authenticating the resolver. In this
scenario, CGA-TSIG offers a solution. It assures the client that the
query response comes from the real originator of that and not from
the attacker.
There are several attacks that CGA-TSIG can prevent. Here we will
evaluate some of them.
3.1. IP Spoofing and Reflector Attacks
During the DNS Update process it is important for both communicating
parties to know that the one they are communicating with is the owner
of that IP address and that the messages have not been sent from a
spoofed IP address. This can be fulfilled by using the CGA algorithm
that utilizes the node to verify the address ownership of the other
node. The reflector attack is a kind of distributed Denial of Service
attack. It uses the IP address of the victim as a source of the DNS
message and sends several queries to the DNS server which then
redirects this traffic to the victim thus keeping the victim busy
processing these packets. Using the CGA signature and authentication
approach will prevent this type of attack.
3.2. DNS Dynamic Update Spoofing
Because the signature contains both CGA parameters and the DNS update
message, proof is offered of the sender's address ownership (CGA
parameters) and the validity of the update message.
3.3. Resolver Configuration Attack
In CGA-TSIG, the DNS server or the client might not need further
configuration. This may reduce the possibility of human errors being
inserted into the DNS configuration file. Since this type of attack
Rafiee, et al. Expires May 22, 2013 [Page 4]
INTERNET DRAFT TSIG using CGA in IPv6 November 22, 2012
is predicated on human error, the chances of it occurring when our
proposed extension is used are minimized.
3.4. Shared Secret (key pairs) Exposing
On-the-fly key pair generation is recommended to decrease the chances
of giving attackers unauthorized access to private keys on a node.
3.5. Replay attack
Using Time Signed in the signature modifies the content of the
signature each time the node generates it and sends it to the DNS
server. This value is the node's current time in UTC. If the attacker
tries to spoof this value with another timestamp, to show that the
update message is current, the DNS server checks this message by
verifying and regenerating the signature (when the private key of the
other DNS server is manually set in this DNS server). In this case
steps 2 and 8 of verification process fail. Therefore the replay
attack is also prevented.
4. Algorithm Overview
CGA is a one-way hashing algorithm used to generate Interface IDs for
IPv6 addresses in a secure manner. An interface ID consists of the
rightmost 64 bits of the 128 bit IPv6 address. CGA verifies the
address ownership of the sender by finding a relationship between the
sender's IP address and his public key [1,2].
+------------------------------------------------+
| Subnet Prefix | Interface ID |
| (8 octets) | (8 octets) |
+------------------------------------------------+
Figure 1 IPv6 addresses
4.1. CGA Generation Algorithm
A node proceeds with the following steps in order to generate the CGA
(When a node wants to generate new address, this process must be
repeated and the CGA parameters should be cached in the server for
further usage by CGA-TSIG):
1. Key pairs, called public/private keys, and a new random number,
called a modifier, are generated [key pair format: Section 3.
Rafiee, et al. Expires May 22, 2013 [Page 5]
INTERNET DRAFT TSIG using CGA in IPv6 November 22, 2012
RFC3972]
- It is recommended that key pairs be generated on the fly the first
time a node wants to generate its IP address. This eliminates the
need for having the keys manually generated and saved, in a
particular path, in the node, before the start of IP address
generation.
- It is recommended that the node change its IP address frequently
for privacy and security issues[3] . When the node's IP address is
temporary, the attacker has less time to process brute force attacks
against CGA or to track this node.
2. The modifier is concatenated with other parameters such as a zero
value prefix (64 bits), a zero value collision count (8 bits) and the
RSA public key
+-----------------------------------------------------------+
| Modifier | Subnet Prefix |collision count | Public key |
|(16 octets)| (8 octets) | (1 octet) | (variable) |
+-----------------------------------------------------------+
Figure 2 CGA Parameters
3. The Secure Hash Algorithm (SHA1) is executed using the output from
step 2. The first leftmost 112 bits of the resulting digest is called
Hash2.
4. The computational complexity of Hash2 depends on the Sec value.
The Sec value is an unsigned 3-bit integer having a value between 0
and 7 (0 being the least secure while 7 the most) which indicates the
security level of the generated address against brute-force attacks.
The use of a security value of one is recommended. According to our
experimental results, it takes less than 500 milliseconds to generate
a CGA when the Sec value is equal to 1. This Sec value is also
acceptable if the nodes' IP address is temporary [3].
The 16xSec leftmost bits of Hash2 are compared to zero. If the
condition is not met, the modifier is incremented by one and steps 2
through 4 are repeated. If the condition is met, the next step is
executed
5. The modifier is concatenated with the prefix, the collision count,
and the public key. SHA1 is executed using the resulting output to
create Hash1. The CGA algorithm then uses the leftmost 64 bits from
Hash1 and sets the first leftmost 3 bits to the sec value. It also
sets bits 7 and 8 (bits u and g) which are called the Interface ID
(IID)
6. The subnet prefix is then concatenated with the IID and the
Duplicate Address Detection (DAD) process is executed in order to
detect address collision on the network. The node then includes the
Rafiee, et al. Expires May 22, 2013 [Page 6]
INTERNET DRAFT TSIG using CGA in IPv6 November 22, 2012
CGA parameters (modifier, subnet prefix, collision count, public key)
with the messages to give other nodes the ability to verify the
address ownership of the sender by finding a relationship between the
sender's IP address and his public key.
4.2. Modification to TSIG protocol
Normally, to initiate a secure DNS Update process between a DNS
server and a host (another DNS server or a client), a minimum of four
messages are required to establish a secure channel (especially for
another secure DNS Update mechanism, DNSSEC). A modification to
RFC-2845, CGA-TSIG, decreases the number of messages needed in the
exchange. The messages used in RFC-2930 (TKEY RR) are not needed when
CGA-TSIG is used.
The CGA-TSIG extension uses the creation of a TSIG Resource Record
(RR). This RR uses the same data as is used to generate a new IP
address in a node -- for example, the key pairs (public/private
keys), and the output value of the CGA generation function (Interface
ID). These values should be cached in the node's memory for later
use.
4.2.1. Modified TSIG Record format
The modified TSIG RR uses the same format as the other RRs in use in
the DNS field. The DNS RR format is explained in section 3.2.1
RFC-1035, where the algorithm type must be set to TSIG. The RDATA is
also extended in order to store the CGA parameters, IP tag, and the
modified CGA signature. The RDATA's algorithm type must be set to
CGA-TSIG, a detailed explanation of the RDATA standard fields can be
found in section 2.3 RFC-2845. This document focuses only on the new
extensions added to RDATA. These new fields are CGA-TSIG Len and
CGA-TSIG DATA. TSIG RR is added to an additional section of the DNS
messages. The general format for DNS messages is explained in RFC1035
[section 4.1 RFC-1035].
+---------------------------------------+
| Algorithm type |
| (CGA-TSIG) |
+---------------------------------------+
| Time Signed |
| |
+---------------------------------------+
| Fudge |
| |
+---------------------------------------+
| MAC Size |
| |
Rafiee, et al. Expires May 22, 2013 [Page 7]
INTERNET DRAFT TSIG using CGA in IPv6 November 22, 2012
+---------------------------------------+
| Mac |
| |
+---------------------------------------+
| Original ID |
| |
+---------------------------------------+
| Error |
| |
+---------------------------------------+
| OTHER LEN |
| |
+---------------------------------------+
| OTHER DATA |
| |
+---------------------------------------+
Figure 3 Modified TSIG RDATA
CGA-TSIG DATA Field and CGA-TSIG Len are placed in the initial part
of Other DATA. Figure 4 shows the layout.
+---------------------------------------+
| CGA-TSIG Len |
| |
+---------------------------------------+
| CGA-TSIG DATA |
| |
+---------------------------------------+
| Other Options |
| |
+---------------------------------------+
Figure 4 Other DATA
CGA-TSIG DATA Field Name Data Type Notes
--------------------------------------------------------------
Algorithm type u_int16_t Name of the algorithm
[RFC3972] RSA (by default) CGA
IP tag 16 octet the tag used to identify the IP
address
Parameters Len Octet the length of CGA parameters CGA
Parameters variable Section 3.1 this document CGA
Signature Len Octet the length of CGA signature
CGA Signature variable Section 3.2.1 This document
IP tag is a node's old IP address. A client's public key can be
associated with several IP addresses on a server. A DNS server keeps
a client's public key and IP addresses in a data field formated as
shown in figure 6. This allows the client to update his own RRs using
Rafiee, et al. Expires May 22, 2013 [Page 8]
INTERNET DRAFT TSIG using CGA in IPv6 November 22, 2012
multiple IP addresses While at the same time allowing him to change
IP addresses. If a client wants to add RRs to the server by using a
new IP address, the IP tag field will be set to binary zeroes and the
server will add the new IP address being passed to it to the CGATSIG
table on database. If the client wants to replace an existing IP
address in CGATSIG table on the server with a new one, then the IP
tag field will be populated with the IP address wihich is to be
replaced. The server will then look for the IP address referenced by
the IP tag in the CGATSIGips table (or file) and replace that IP
address with the new one.
Note: When a host sends a DNS Update message to a DNS server for the
first time, the DNS server must save the public key for this client
in CGATSIGkeys.
+---------------------------------------+
| Algorithm type |
| |
+---------------------------------------+
| IP tag |
| (16 byte) |
+---------------------------------------+
| CGA Parameter Len |
| (1 byte) |
+---------------------------------------+
| CGA Parameters |
| (variable) |
+---------------------------------------+
| CGA Signature Len |
| (1 byte) |
+---------------------------------------+
| CGA Signature |
| (variable) |
+---------------------------------------+
Figure 5 CGA-TSIG DATA Field
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)
);
Rafiee, et al. Expires May 22, 2013 [Page 9]
INTERNET DRAFT TSIG using CGA in IPv6 November 22, 2012
Figure 6 CGA-TSIG tables on mysql backend database
4.2.1.1. Generation of the DNS Update request/response
Both the DNS update request and response messages must contain the
CGA-TSIG option. To generate the CGA-TSIG DATA, a DNS server and a
host must follow steps 1 and 2. It is recommended that the CGA
parameters be cached in an XML file in the format as shown in figure
7. The modifier is the final modifier in the byte and each byte
separated by a comma (for example : 284,25,14,...). Algorithmtype is
the algorithm used in signing the message. Zero is the default
algorithm, i.e., 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 are the path where
the CGA-TSIG algorithm can find the PEM format of the public/private
keys (for example: /home/myuser/keys.pem ).
<?xml version="1.0" encoding="UTF-8"?>
<Details>
<CGATSIG>
<modifier value=""/>
<algorithmtype value="0"/>
<secval value="1"/>
<GIP value=""/>
<oGIP value=""/>
<Keys value=""/>
</CGATSIG>
</Details>
Figure 7 XML file contains the cached DATA
1.Obtain required parameters from cache.
The CGA-TSIG algorithm obtains the old IP address, modifier, subnet
prefix, public key from the cache (XML file). It concatenates the old
IP address with the CGA parameters, i.e., modifier, subnet prefix,
public key and collision count (the order of CGA parameters are shown
in figure 2). If the old IP address is not available, CGA-TSIG must
set the old IP address (IP tag) to zero.
In the case of multiple DNS servers (authentication of 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 serve,r because of the need for
human intervention.
a. Add the DNS servers' IP address to a slave configuration file
Rafiee, et al. Expires May 22, 2013 [Page 10]
INTERNET DRAFT TSIG using CGA in IPv6 November 22, 2012
A DNS server administrator should only manually add the IP address of
the master DNS server to the configuration file of the slave DNS
server. When the DNS update message is processed, the slave DNS
server can authenticate the master DNS server based on the source IP
address and then, prove the ownership of this address by using CGA.
This scenario is valid until the IP address in any of these DNS
servers changes.
To automate this step's process, the DNS Update message sender's
public key 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)
The message exchange option of SEND [RFC3971] may be used for the
retrieval of the third party certificate. This may be done
automatically from the TA by using the Certificate Path Solicitation
and the Certificate Path Advertisement messages. Like in scenario b,
saving the certificate on the DNS server for later use in the
generation of its address or in the DNS update process. In this case,
whenever any of these servers wants to generate a new IP address, the
DNS update process can still be done automatically without the need
for human intervention.
2. Generate signature
For signature generation, all CGA parameters (modifier, public key,
collision count and subnet prefix), that are concatenated with the
DNS update message, IP tag and the Time Signed field, are signed by
using a RSA algorithm and the private key which was generated in the
first step. This signature must be added as an initial option to the
Other DATA field. Time Signed is the same timestamp as is used in
RDATA. This value is the UTC date and time value obtained from the
signature generator. This approach will prevent replay attacks by
changing the content of the signature each time a node wants to send
a DNS Update Request. The Update Message contains all of the DNS
update message with the exclusion of the TSIG Resource Records (RRs).
A DNS update message consists of a header, a zone, a prerequisite, an
update and additional data. The header contains the control
information [RFC2136], the zone identifies the zones to which this
update should be applied [Section 4.1.2 RFC1035], the prerequisite
prescribes the RRs that must be in the DNS database, the update
contains the RR that needs to be modified or added and the additional
data is the data that is not part of the DNS update, but is necessary
in order to process this update.
Rafiee, et al. Expires May 22, 2013 [Page 11]
INTERNET DRAFT TSIG using CGA in IPv6 November 22, 2012
+-----------------------------------------------------------+
| Modifier | Subnet Prefix |collision count | Public key |
| (128 bits)| (64 bits) | (8 bit) | (variable) |
+-----------------------------------------------------------+
| IP tag |Time Signed | DNS Update Message |
| (128 bits)| | |
+-----------------------------------------------------------+
Figure 8 CGA-TSIG Signature
4.2.1.2. Verification of the DNS Update Request/Response
Sender authentication is necessary to prevent attackers from making
unauthorized modifications to DNS servers by use of spoofed DNS
Update messages. The verification process has the following steps:
1. Check the subnet prefix
The leftmost 64 bits of IPv6 addresses constitute the subnet prefix.
The receiver obtains the subnet prefix from the source IP address in
the sender's message. Then, the subnet prefix is obtained from the
CGA parameters in the TSIG Other DATA field of the received message.
A comparison is then made between these two subnet prefixes. If the
subnet prefixes match step 2 is executed, otherwise the node is
considered as an attacker and the message should be discarded without
further action.
2. Check the Time Signed
The Time Signed value is obtained from the TSIG RDATA and is denoted
t1. The current system time is then obtained and converted to UTC
time and is denoted t2. If t1 is in the range of t2 and t2 minus 2
minutes (see formula 1, 2 minutes may vary according to the
transmission lag time) step 3 is executed, otherwise, the message is
considered a spoofed message and the message should be discarded
without further action. The range of two seconds is used because the
update message may experience a delay during its transmission over
TCP or UDP. Both times must use UTC time to avoid any differences in
the time based on different geographical locations.
t2-2 <= t1 <= t2 (1)
3. Compare Hash1 to the Interface ID
The receiver should obtain all CGA parameters from the TSIG Other
DATA field and execute SHA1 against them. The leftmost 64 bits of the
resulting output constitutes Hash1. Hash1 is then compared to the
Rafiee, et al. Expires May 22, 2013 [Page 12]
INTERNET DRAFT TSIG using CGA in IPv6 November 22, 2012
rightmost 64 bits of the sender's IP address, which is known as the
Interface ID (IID). Any differences in the first three leftmost bits
of the IID (Sec value) and the u and the g bits (Section 3.1) are
ignored. u and g are bits 7 and 8 of the first byte of the IID. If
they match step 4 is executed, otherwise, the source is considered as
a spoofed source IP address and the message should be discarded
without further action.
4. Evaluate Hash2 with CGA parameters
The receiver obtains the CGA parameters. The collision count and the
subnet prefix are set to zero and SHA1 is executed on the resulting
data in order to obtain a result of which the leftmost 112 bits are
denoted as Hash2. The leftmost 16xSec bits of Hash2 are compared to
zero. If the condition is met step 5 is executed, otherwise, the CGA
parameters should be consider as spoofed CGA parameters and the
message should be discarded without further action.
5. Verify the signature
The signature contained in the TSIG Other DATA field of the DNS
update message should be verified. This can be done by retrieving the
public key from the TSIG Other DATA and using it to verify the
signature. If the verification process is successful and the node
does not want to update another node's RR, then the Update Message
will be processed. If the signature verification is successful and
the node wants to update another node's RRs, then step 6 is executed.
If the verification fails, then the message should be discarded
without further action.
6. Verify the Source IP address
If a node wants to update a/many RR(s) on another DNS server, like a
master DNS server wanting to update RRs on the slave DNS server, the
requester's source IP address must be checked against the one in the
DNS configuration file. If it is the same the Update Message should
be processed, otherwise, step 7 is executed.
7. Verify the public key
The DNS server checks whether or not the public key retrieved from
the TSIG Other DATA is the same as what was available in CGATSIGkeys
table. If it is the same the Update Message should be processed,
otherwise, the message should be discarded without further action.
4.2.1.3. Generation of DNS Query Response
When a host, such as a client or a mail server, wants to resolve a
domain or IP address, it generates a DNS query messages and sends its
request to the known resolver. The CGA-TSIG DATA field is not
required in this message because the resolver responds to anonymous
Rafiee, et al. Expires May 22, 2013 [Page 13]
INTERNET DRAFT TSIG using CGA in IPv6 November 22, 2012
queries. But the resolver's response should contain the CGA-TSIG DATA
field. The generation of the CGA-TSIG DATA field is explained in
section 4.2.1.1.
4.2.1.4. Verification of DNS Query Response
When a resolver responds to the host'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 issues. The resolver's responses should contain
the CGA-TSIG DATA field in order to enable this client to verify him.
The verification steps are the same as the first 5 steps explained in
section 4.2.1.2.
5. Security Considerations
The solution explained in this draft, CGA-TSIG, is an approach that
can secure DNS messages from spoofing type attacks as explained in
section 3.
Note: If a host does not support CGA-TSIG, the CGA-TSIG DATA Field
should be ignored. It is recommended that both communicating nodes
support this option in order to diminish the possibility for the
occurrence of the attacks explained in the next sections.
The problem that can arise here are attacks against the CGA
algorithm. In this section we explain the possibility of attacks
against CGA itself, and explain the available solutions we considered
in this draft.
a) Discover an Alternative Key Pair Hashing of the Victim's Node
Rafiee, et al. Expires May 22, 2013 [Page 14]
INTERNET DRAFT TSIG using CGA in IPv6 November 22, 2012
Address
In this case an attacker would have to find an alternate key pair
hashing of the victim?s address. The success of this 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 with Hash1
and Hash2. The cost of doing so 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 attack due to the cost involved. Changing
the IP address frequently, also, decrease the chance of this attack.
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 appied to any request-response protocol. One possible
solution to mitigate this attack is to add a controller at the
verifier side to determine the maximum number of messages that the
receiver can accept within a certain period of time from a specific
node. If this threshold rate is exceeded, the receiver drops the new
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 to use it 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 RFC4941.
6. 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
7. Conclusions
In TSIG, not all processing is done automatically and some steps
might even need to be done offline. To address this issue, and to
automate this process when Secure Neighbor Discovery (SEND) (RFC3971)
is used, this document is introduced as an extension to the TSIG
protocol (CGA-TSIG) in order to take advantage of the use of CGA for
the DNS Update authentication process of a node within a DNS server.
Rafiee, et al. Expires May 22, 2013 [Page 15]
INTERNET DRAFT TSIG using CGA in IPv6 November 22, 2012
CGA-TSIG also decreases the number of messages needed in the exchange
between the DNS server and the DNS client during the update process.
This enhances the performance of the DNS update process. Since CGA
does not need Public Key Infrastructure (PKI) framework to verify the
node's address ownerships, the authentication of a node with a DNS
server in the DNS update process is automated. This document also
makes use of SEND for the authentication of two DNS servers against
each other when processing DNS Update messages. However ,the first
step should be done manually the first time it is used to afford
greater security for this process.
8. Acknowledgements
The author would like to thank all those who helped directly in
improving of this draft and all supporters of this draft
9. References
9.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.
[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.
Rafiee, et al. Expires May 22, 2013 [Page 16]
INTERNET DRAFT TSIG using CGA in IPv6 November 22, 2012
9.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 May 22, 2013 [Page 17]
INTERNET DRAFT TSIG using CGA in IPv6 November 22, 2012
Authors' Addresses
Hosnieh Rafiee
Hasso-Plattner-Institute
Prof.-Dr.-Helmert-Str. 2-3
Potsdam, Germany
Phone: +49 (0)331-5509-546
Email: rafiee@hpi.uni-potsdam.de
Dr. Christoph Meinel
(Professor)
Hasso-Plattner-Institute
Prof.-Dr.-Helmert-Str. 2-3
Potsdam, Germany
Email: meinel@hpi.uni-potsdam.de
Dr. Martin von Loewis
Hasso-Plattner-Institute
Prof.-Dr.-Helmert-Str. 2-3
Potsdam, Germany
Email: martin@v.loewis.de
Rafiee, et al. Expires May 22, 2013 [Page 18]