[dnsext] Review request - new version of CGA-TSIG draft - draft-rafiee-intarea-cga-tsig-11

[Hosnieh Rafiee <[e-mail]>]

Folks,

I have revised CGA-TSIG document . You can find the following summary in the introduction as well. Just to motivate more people to review the draft, the following is the description of the mechanism.

Thanks Joel Halpern for his comments and reviews which helped to improve its readability and content.

I would love to receive your inputs on this version so that I know whether now it is easily readable and understandable. :-)

Thanks,
Best,
Hosnieh

< https://tools.ietf.org/html/draft-rafiee-intarea-cga-tsig-11 >
------------------------------
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 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) [1]. 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 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.

---------------------------------------
[1]< http://tools.ietf.org/html/draft-rafiee-6man-ssas-11 >