One document matched: draft-rafiee-intarea-cga-tsig-02.txt
Differences from draft-rafiee-intarea-cga-tsig-01.txt
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: August 24, 2013 February 24, 2013
Transaction SIGnature (TSIG) using CGA Algorithm in IPv6
<draft-rafiee-intarea-cga-tsig-02.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 consists of modifying the DNS
configuration so that the DNS server will know what key to use with
which host, because this shared secret is only valid between a pair
of hosts. This document, CGA-TSIG, proposes a possible way to
eliminate the human intervention needed for the generation and
exchange of keys between a DNS server and a host when SEcure Neighbor
Discovery (SEND) (RFC 3971) is used. CGA-TSIG will facilitate the
authentication process of a host with a DNS server and will reduce
the time needed to accomplish DNS Updates. It will also provide a
means for securing the authentication process between resolvers and
clients. CGA-TSIG will be added, as an extension, to TSIG in order to
provide data integrity and proof of IP address ownership. The current
signature generation and verification process used in TSIG will be
substituted with the use of the same parameters as are used in
generating a secure address in IPv6 networks, i.e., Cryptographically
Generated Addresses (CGA) (RFC 3972).
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."
Rafiee, et al. Expires August 24, 2013 [Page 1]
INTERNET DRAFT TSIG using CGA in IPv6 February 24, 2013
This Internet-Draft will expire on May 20, 2013.
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 . . . . . . . . . . . . 5
3.2. DNS Dynamic Update Spoofing . . . . . . . . . . . . . . . 5
3.3. Resolver Configuration Attack . . . . . . . . . . . . . . 5
3.4. Exposing Shared Secret (key pairs) . . . . . . . . . . . 5
3.5. Replay attack . . . . . . . . . . . . . . . . . . . . . . 5
4. Algorithm Overview . . . . . . . . . . . . . . . . . . . . . 6
4.1. Modification to the TSIG Record . . . . . . . . . . . . . 6
4.2. Generation of CGA-TSIG DATA . . . . . . . . . . . . . . . 9
4.3. Verification of the CGA-TSIG DATA for DNS update messages 11
4.4. Verification of the CGA-TSIG DATA for DNS Query Response 13
5. Security Considerations . . . . . . . . . . . . . . . . . . . 14
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
7. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 16
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
9.1. Normative . . . . . . . . . . . . . . . . . . . . . . . . 16
9.2. Informative . . . . . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
Rafiee, et al. Expires August 24, 2013 [Page 2]
INTERNET DRAFT TSIG using CGA in IPv6 February 24, 2013
1. Introduction
Transaction SIGnature (TSIG) [RFC2845] is a protocol that provides
endpoint authentication and data integrity by the use of one-way
hashing and shared secret keys in order to establish a trust
relationship between two hosts which can be either a client and a
server, or two servers. The TSIG keys, which are manually exchanged
between these two hosts, need to 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.
It is possible to extend the TSIG protocol with the use of newly
defined algorithms. This document proposes the use of
Cryptographically Generated Addresses (CGA) [RFC3972] for use as a
new algorithm in the TSIG Resource Record (RR). CGA is an important
option available in SEcure Neighbor Discovery (SEND) [RFC3971] which
provides nodes with the necessary proof of IP address ownership by
providing a cryptographic binding between a host and its IP address
without the need for the introduction of a new infrastructure. 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
ownership of the sender's IP address 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
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.
3. Problem Statement
Rafiee, et al. Expires August 24, 2013 [Page 3]
INTERNET DRAFT TSIG using CGA in IPv6 February 24, 2013
This document addresses the authentication problems associated with
the need for hosts to change their IP addresses frequently in order
to maintain privacy. This problem is present in two different
situations: the authentication of a resolver with a client and the
authentication of two hosts (a client and a DNS server and two DNS
servers) during the DNS Update process.
The DNS Update process is vulnerable to several types of spoofing
attacks -- man in the middle, reflector , source IP spoofing, etc.
TSIG secures this process by providing the transaction level
authentication necessary by use of a shared secret. The problem is
that this protocol is not widely used. The current problem with the
use of TSIG is the need for manual processing required to generate
and exchange 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 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 process's vulnerability to attacks
introduced by human errors when SEcure Neighbor Discovery (SEND) is
used for addressing purposes.
This 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 for
authentication. If the attacker spoofed the resolver's IP address and
if the attacker responds faster than the legitimate resolver, then
the client's cache will be updated with the attacker's response. The
client does not have any way to authenticate the resolver. In the
above scenario, the resolver SHOULD add the TSIG Resource Record (RR)
to the DNS query response and use the CGA-TSIG Algorithm. CGA-TSIG
assures the client that the query response comes from the true
originator and not from an attacker. Currently there is no
consideration for the use of the TSIG RR for resolver authentication
with clients. One reason is that resolvers respond to anonymous
queries and can be located in any part of the network. A second
reason is that the manual TSIG process makes it hard to configure
each new client with the shared secret of the resolver.
There are several types of attack that CGA-TSIG can prevent. Here we
will evaluate some of them. The use of CGA-TSIG will also reduce the
number of messages needed in exchange between a client and a server
in order to establish a secure channel. 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 for
the establishment of a secure channel (especially for another secure
DNS Update mechanism, DNSSEC). Modifying RFC-2845 to use CGA-TSIG
will decrease the number of messages needed in the exchange. The
Rafiee, et al. Expires August 24, 2013 [Page 4]
INTERNET DRAFT TSIG using CGA in IPv6 February 24, 2013
messages used in RFC-2930 (TKEY RR) are not needed when CGA-TSIG is
used.
3.1. IP Spoofing and Reflector Attacks
During the DNS Update process it is important that both communicating
parties know that the one that they are communicating with is the
actual owner of that IP address and that the messages are not being
sent from a spoofed IP address. This can be accomplished by the use
of the CGA algorithm that utilizes the node for IP address
verification of other nodes. 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
Dynamic Update Spoofing is eliminated because the signature contains
both the CGA parameters and the DNS update message. This will offer
proof of the sender's IP 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, would not need further
configuration. This would reduce the possibility of human errors
being inserted into the DNS configuration file. Since this type of
attack is predicated on human error, the chances of it occurring,
when our proposed extension is used, are minimized.
3.4. Exposing Shared Secret (key pairs)
In order to decrease the chances of attackers gaining unauthorized
access to private keys on a node, it is recommended that key pairs be
generated "on-the-fly".
3.5. Replay attack
Using the Time Signed value in the signature modifies the content of
the signature each time the node generates it and sends it to the DNS
Rafiee, et al. Expires August 24, 2013 [Page 5]
INTERNET DRAFT TSIG using CGA in IPv6 February 24, 2013
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 will fail and thus the replay
attack will also be prevented.
4. Algorithm Overview
The following sections explain the use of CGA, or other future
algorithms used in place of CGA, for securing the DNS process when
using the TSIG Resource Record (RR).
4.1. Modification to the TSIG Record
The modified TSIG Resource Record (RR) will use 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 [RFC1035], where the algorithm type must be
set to TSIG. The RDATA field is also extended in order to provide a
place to store the CGA-TSIG DATA (see figures 2 and 3). The RDATA
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 the RDATA field.
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]. If
another algorithm is used in place of CGA for SEND, such as SSAS [4],
then CGA-TSIG Len will be the length for the parameters of this
algorithm and CGA-TSIG DATA will consist of the parameters required
for verification of that algorithm, like signature, public key, etc.
+---------------------------------------+
| Algorithm type |
| (CGA-TSIG) |
+---------------------------------------+
| Time Signed |
| |
+---------------------------------------+
| Fudge |
| |
+---------------------------------------+
| MAC Size |
| |
+---------------------------------------+
| Mac |
| |
+---------------------------------------+
Rafiee, et al. Expires August 24, 2013 [Page 6]
INTERNET DRAFT TSIG using CGA in IPv6 February 24, 2013
| Original ID |
| |
+---------------------------------------+
| Error |
| |
+---------------------------------------+
| OTHER LEN |
| |
+---------------------------------------+
| OTHER DATA |
| |
+---------------------------------------+
Figure 2 Modified TSIG RDATA
CGA-TSIG DATA Field and CGA-TSIG Len will occupy the first two slots
of Other DATA. Figure 3 shows the layout.
+---------------------------------------+
| CGA-TSIG Len |
| |
+---------------------------------------+
| CGA-TSIG DATA |
| |
+---------------------------------------+
| Other Options |
| |
+---------------------------------------+
Figure 3 Other DATA section of RDATA field
CGA-TSIG DATA Field Name Data Type Notes
--------------------------------------------------------------
Algorithm type u_int16_t Name of the algorithm
[RFC3972] RSA (by default) CGA
type u_int16_t Name of the algorithm used in
SEND
IP tag 16 octet the tag used to identify the IP
address
Parameters Len Octet the length of CGA parameters
Parameters variable CGA parameters Section 3 RFC-3972
Signature Len Octet the length of CGA signature
Signature variable Section 3.2.1 This document
old pubkey Len variable the length of old public key
field
old pubkey variable Old public key
old Signature Len variable the length of old signature field
old Signature variable Old signature generated by old
public key.
Rafiee, et al. Expires August 24, 2013 [Page 7]
INTERNET DRAFT TSIG using CGA in IPv6 February 24, 2013
+---------------------------------------+
| Algorithm type |
| |
+---------------------------------------+
| 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) |
+---------------------------------------+
Figure 4 CGA-TSIG DATA Field
Type indicates the Interface ID generation algorithm that was used in
SEND. This field allows for the use of future algorithms in place of
CGA. The default value for CGA is 1. Other algorithms would be
assigned a new number sequentially. For example, a new algorithm
called SSAS could be assigned a value of 2. The IP tag is a node's
old IP address. It is only used during the DNS update process and not
for resolving a query. A client's public key can be associated with
several IP addresses on a server. The DNS server, or the DNS message
verifier node, SHOULD store the IP addresses and the public keys so
as to indicate their association to each other. An example of how to
store this formated data in mysql is shown in figure 5. If a client
wants to add RRs to the server by using a new IP address, then the IP
tag field will be set to binary zeros. The server will then store the
new IP address that was passed to it in storage. (Figure 5 shows how
to store it in the CGATSIGIPs table.) If the client wants to replace
Rafiee, et al. Expires August 24, 2013 [Page 8]
INTERNET DRAFT TSIG using CGA in IPv6 February 24, 2013
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 in its storage and replace that IP address 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 in order to
maintaining privacy, then it SHOULD add the old public key to the old
pubkey field. It SHOULD also retrieve the current time from Time
signed field, sign it using the old private key, and add the digest
(signature) to the old signature field. This enables the verifier
node to authenticate a host with a new public key. The detailed
verification steps are explained in section 4.3. and section 4.4.
Note: When a host sends a DNS message to a DNS server or a client for
the first time, the verifier host SHOULD save the public key for this
client/resolver in a storage. (Figure 5 table CGATSIGkeys shows an
example.)
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)
);
Figure 5 CGA-TSIG tables on mysql backend database
4.2. Generation of CGA-TSIG DATA
All DNS messages, except those from a client resolving a query, need
to contain the CGA-TSIG option. To generate the CGA-TSIG DATA, a host
must execute the following steps. Figure 6 shows what parameters
SHOULD be cached by a host for further usage by the CGA-TSIG
algorithm. If the Type (section 4.1) 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 this host. For example,
the modifier is stored as bytes and each byte should 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,
Rafiee, et al. Expires August 24, 2013 [Page 9]
INTERNET DRAFT TSIG using CGA in IPv6 February 24, 2013
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="0"/>
<secval value="1"/>
<GIP value=""/>
<oGIP value=""/>
<Keys value=""/>
</CGATSIG>
</Details>
Figure 6 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 section 3 RFC-3972). If the old IP address is not available,
CGA-TSIG must set the old IP address (IP tag) to zero.
In the case of processing a DNS update for 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
server, because of the need for human intervention. These scenarios
do not apply to the authentication of a resolver to a client.
a. Add the DNS servers' IP address to a slave configuration file
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 the
CGA-TSIG option from the TSIG RR. This scenario will be 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.
Rafiee, et al. Expires August 24, 2013 [Page 10]
INTERNET DRAFT TSIG using CGA in IPv6 February 24, 2013
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 want 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, the default, or any future algorithm used in
place of RSA, and the private key which was obtained from cache in
the first step. This signature must be added to the signature field
of the CGA-TSIG DATA. 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 message. The format of DNS messages is explained in section
4.1.2 RFC-1035 [RFC1035].
+-----------------------------------------------------------+
| Modifier | Subnet Prefix |collision count | Public key |
| (128 bits)| (64 bits) | (8 bit) | (variable) |
+-----------------------------------------------------------+
| IP tag |Time Signed | DNS Update Message |
| (128 bits)| | |
+-----------------------------------------------------------+
Figure 7 CGA-TSIG Signature
3. Generate old signature
If the nodes generated new key pairs, then they need to add the old
public key and messag,e signed by the old private key, to the
CGA-TSIG DATA. A node will retrieve the timestamp from Time Signed,
will use the old private key to sign it, and then will add the
content of this signature to old signature field of the CGA-TSIG
DATA. This step MUST be skipped when the node did not generate new
key pairs.
4.3. Verification of the CGA-TSIG DATA for DNS update messages
Sender authentication is necessary in order to prevent attackers from
Rafiee, et al. Expires August 24, 2013 [Page 11]
INTERNET DRAFT TSIG using CGA in IPv6 February 24, 2013
making unauthorized modifications to DNS servers through the use of
spoofed DNS messages. The verification process uses the following
steps:
1. Execute the CGA verification
These steps are found in section 5 RFC-3972. 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 successfu,l then step 2 will be executed. Otherwise the message
will be discarded without further action.
2. Check the Time Signed
The Time Signed value is obtained from the TSIG RDATA and is called
t1. The current system time is then obtained and converted to UTC
time and is called t2. If t1 is in the range of t2 and t2 minus x
minutes (see formula 1, x minutes may vary according to the
transmission lag time) then step 3 will be executed, otherwise, the
message will be considered a spoofed message and the message should
be discarded without further action. 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.
t2-x <= t1 <= t2 (1)
3. Verify the signature
The signature contained in the CGA-TSIG DATA should be verified. This
can be done by retrieving the public key and signature from the
CGA-TSIG DATA and using this public key 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 4 will be executed. If the
verification fails, then the message should be discarded without
further action.
4. 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, then
the requester source IP address must be checked against the one
contained in the DNS configuration file. If it is the same, then the
Update Message should be processed, otherwise, step 5 will be
executed.
5. Verify the public key
The DNS server checks whether or not the public key retrieved from
the CGA-TSIG DATA is the same as what was available in the storage
where the public keys and IP addresses were saved. If it is the same,
Rafiee, et al. Expires August 24, 2013 [Page 12]
INTERNET DRAFT TSIG using CGA in IPv6 February 24, 2013
then the Update Message should be processed, otherwise step 6 will be
executed.
6. Verify the old public key
If the old public key length is zero, then skip this step and discard
the DNS update message without further action. If the old public key
length is not zero, then the DNS server will retrieve the old public
key from the CGA-TSIG DATA and will check whether or not it is the
same as what was saved in the DNS server's storage where the public
keys and IP addresses are stored. If it is the same, then step 7 will
be executed, otherwise the message should be discarded without
further action.
7. Verify the old signature
The old signature contained in the CGA-TSIG DATA should be verified.
This can be done by retrieving the old public key and old signature
from the CGA-TSIG DATA and using this old public key to verify the
old signature. If the verification is successful, then 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, then the message should be discarded without further
action.
4.4. Verification of the CGA-TSIG DATA for DNS Query Response
A DNS query request sent by a host, such as a client or a mail
server, does not need to include the CGA-TSIG DATA because the
resolver responds to anonymous queries. But the resolver's response
SHOULD contain the CGA-TSIG DATA field in order to enable this client
to verify him. 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 first 2 steps in the
verification process are the same as the similar steps explained in
section 4.3. These steps are as follows:
1. Execute the CGA verification
2. Check the Time Signed
3. Verify the Source IP address
If the resolver's source IP address is the same as that which is
known for the host, then step 4 will be executed. Otherwise the
message SHOULD be discarded without further action.
4. Verify the signature
The signature contained in the CGA-TSIG DATA should be verified. This
Rafiee, et al. Expires August 24, 2013 [Page 13]
INTERNET DRAFT TSIG using CGA in IPv6 February 24, 2013
can be done by retrieving the public key and signature from the
CGA-TSIG DATA and using this public key to verify the signature. If
the verification process is successful, then step 4 will be executed.
If the verification fails, then the message should be discarded
without further action.
5. Verify the public key
The host checks whether or not the public key retrieved from the
CGA-TSIG DATA is the same as what was available in the storage where
the public keys and IP addresses of resolvers are saved. If it is the
same, then the message is processed. If not, then step 5 will be
executed.
5. Verify the old public key
If the old public key length is zero, then skip this step and discard
the DNS query response without further action. If the old public key
length is not zero, then the host will retrieve the old public key
from the CGA-TSIG 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 6 will be
executed, otherwise the message should be discarded without further
action.
6. Verify the old signature
The old signature contained in the CGA-TSIG DATA should be verified.
This can be done by retrieving the old public key and old signature
from the CGA-TSIG DATA and using this old public key to verify the
old signature. If the verification is successful, then 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 should be discarded
without further action.
5. Security Considerations
Rafiee, et al. Expires August 24, 2013 [Page 14]
INTERNET DRAFT TSIG using CGA in IPv6 February 24, 2013
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 section 3.
The problem that can arise here are attacks against the CGA
algorithm. In this section we explain the possibility of attacks
against CGA [5] itself, 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 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 will also decrease the chance for 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 applied 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 any 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 its use at that subnet. The result is that nodes
using CGAs are still susceptible to privacy related attacks. One
solution to these types of attacks is setting a lifetime for the
address as explained in RFC-4941.
Rafiee, et al. Expires August 24, 2013 [Page 15]
INTERNET DRAFT TSIG using CGA in IPv6 February 24, 2013
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 introduces 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. 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 IP 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 together
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.
This document also proposes an automatic process for authenticating a
resolver in a client. This will help to eliminate the possibility of
attacks against a client's DNS during the query request and responses
processes.
8. Acknowledgements
The author would like to thank all those who helped directly in
improving of this draft and all supporters of this draft especially
Ralph Droms, Andrew Sullivan and Brian Haberman.
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.
Rafiee, et al. Expires August 24, 2013 [Page 16]
INTERNET DRAFT TSIG using CGA in IPv6 February 24, 2013
[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.
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.
[4] Rafiee, H., Meinel, C., "A Simple Secure Addressing
Generation Scheme for IPv6 AutoConfiguration (SSAS)". Work in
progress, http://tools.ietf.org/html/draft-rafiee-6man-ssas-01,
2013.
[5] AlSa'deh, A., Rafiee, H., Meinel, C., ?Cryptographically
Generated Addresses (CGAs): Possible Attacks and Proposed
Mitigation Approaches,? in 12th IEEE International Conference on
Computer and Information Technology (IEEE CIT?12), pp.332-339,
2012.
Rafiee, et al. Expires August 24, 2013 [Page 17]
INTERNET DRAFT TSIG using CGA in IPv6 February 24, 2013
Authors' Addresses
Hosnieh Rafiee
Hasso-Plattner-Institute
Prof.-Dr.-Helmert-Str. 2-3
Potsdam, Germany
Phone: +49 (0)331-5509-546
Email: ietf@rozanak.com
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 August 24, 2013 [Page 18]
| PAFTECH AB 2003-2026 | 2026-04-24 02:35:14 |