Dear All, Since we have a timeslot to present http://tools.ietf.org/html/draft-rafiee-intarea-cga-tsig in DNSOP. I ask you please review it so that the discussion would be fruitful and we can receive good comments to improve it and to move ahead. This draft is not a new one as many of you already know or heard about it, it was first presented in IETF 85 and recently in IETF 88 in Int-area. The reason was because it was more related to DNSEXT and at that time it was going to shut down. It had several volunteer reviewers and it received some good comments. However, we would like to receive more comments in case we missed anything that needs to be addressed or we missed to clarify any section in the draft that needs more clarifications. Since now the DNS confidentiality is also an important topic and this proposal could handle it for IPv6 and during data transfer, I also included a section and explained the required changes to the original proposal.
Here again I briefly explain the purpose of this document for those who do not know about it or who do not know the exact purpose of it: This proposal is for the cases where DNS uses IPv6 and there is a need to use a security mechanism for DNS authentication or provide the data confidentiality for the DNS data during transferring data over the network. It is possible to use this proposal in different DNS scenarios such as DNS update, updating FQDN and PTR, or DNS resolving. In this case it is enough that the verifier node only knows the IP address of the DNS server or resolver. For DNS update, this IP address can be set manually for the first time in the DNS configuration file and for other times, the CGA-TSIG can handle the changes with the proposed specifications. For DNS resolver, it receives this IP address securely via the option in the router advertisement message. The implementation of this part is also available. one need to use a suitable solution for secure authentication purposes while at the same time decrease the human intervention for the configuration. CGA-TSIG is the combination of the use of SSAS or CGA as an authentication purpose for DNS protocol and TSIG. SSAS/CGA is the mechanism which provides the node with the proof of IP address ownership by finding a binding between the IP address and the nodes' public key. Since this approach prevent IP spoofing (in network layer), it also ensures the DNS server or the clients that the one who is talking with is the owner of this IP address without the need to check the public key to the root to find out that this public key is really belong to this node with this IP address. So, using this approach can eliminate the need for this check. It can be also integrated with DNSSEC for this purpose and prevent IP spoofing without the need to check the keys up to the root level and simplify the key exchange process. This proposal also can be helpful for resolving scenario that is now a problem. Since for DNSSEC, exchanging the key of the resolver is the problem because the resolver must answer to anonymous queries, it is not easy to exchange the keys of this DNSSEC resolver to all the nodes who wants to ask this resolver. But with using this approach as I explained earlier, the IP address of the resolver can be obtained in a secure manner via the RA message and then since there is a binding between the IP address and the public key, the CGA/SSAS verification helps to verify this resolver. There is a recent discussion about privacy and data confidentiality. This proposal can also handle data confidentiality during the data exchanged between two nodes (servers or clients). Since the node knows the IP address of the DNS server, it can ask the DNS server to send the node, its public key. Then the node can encrypt a secret key with this public key and then encrypt the whole message using this secret key and AES or other symmetric algorithms. The DNS server then decrypt the secret key with its own private key and decrypt the whole DNS message by using this secret key. This provides the data confidentiality during DNS updates or also it can be used during DNS resolving. (if necessary) If you don't know anything about CGA, I try to explain it in a very simple example: Note that all values are in hexadecimal CGA parameters= e387d788a9e529701ba9baf0bb3694de20051abcab8c7dc000e581e41c6891dd5c06fee6f3ab 149bcf00d18d90534606354b8b8d7511ff90552393f974082732f16b646a97d336190c26d5e1 0347422ebfd6da4036d1e363f9de5c85091448b330ca8b541d246c378de29e9f37b19c072974 2d0a04ac0befe2e5069dd16cea03762b6d621d5d15fbf00131a5ee48f91d5a46396af46d01e6 17010001 Sha1(CGA parameters) = e584448d597e3c927805fc18250598a1d1b71b46 now set bits u and g and sec value so only the first bytes will change CGA value= 2784448d Thank you and looking forward to see you all in our talk. Since I cannot make it and will not be in London, Erik will present in my place but can answer some questions and I will also follow it in jabber. I hope to see a fruitful conversations :-) -----------smile---------- Hosnieh _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
