Subject: [dnsext] Last Call before IETF meeting: draft-rafiee-intarea-cga-tsig-00.txt

From: "Rafiee, Hosnieh" <[email-masked]>
Date: Tue, 23 Oct 2012 17:06:42 +0200

Hello,

This is our "last call" request for comments concerning our draft, RFC "CGA-TSIG". If you feel so inclined, please feel free to comment on it. Any and all comments are greatly appreciated.
Thank you,

----------------------------------

A new version of I-D, draft-rafiee-intarea-cga-tsig-00.txt
has been successfully submitted by Hosnieh Rafiee and posted to the IETF repository.

Filename:	 draft-rafiee-intarea-cga-tsig
Revision:	 00
Title:		 Transaction SIGnature (TSIG) using CGA Algorithm in IPv6
Creation date:	 2012-10-15
WG ID:		 Individual Submission
Number of pages: 13
URL:             http://www.ietf.org/internet-drafts/draft-rafiee-intarea-cga-tsig-00.txt
Status:          http://datatracker.ietf.org/doc/draft-rafiee-intarea-cga-tsig
Htmlized:        http://tools.ietf.org/html/draft-rafiee-intarea-cga-tsig-00

Abstract:
   The first step of Transaction SIGnature (TSIG) (RFC 2845) is to
   generate a shared secret and exchange it manually between a DNS
   server and a host. This document, CGA-TSIG, proposes a possible way
   to automate the now manual process 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.

The IETF Secretariat

---

From: "Rafiee, Hosnieh" <[email-masked]>
Date: Wed, 24 Oct 2012 11:08:55 +0200

Dear Miek,

Thank you so much for your comments and careful review. 

>First up: it seems you have written this draft by hand? I.e., didn't use XML2RFC? There is some markup that is different than normal (i.e. no ^L in the page header/footer). If you don't like XML, you >could use my pandoc2rfc
>tooling: https://github.com/miekg/pandoc2rfc
It was not written in text editor, we first used word template and we realized that it is not easy to convert it to text, so again we used another program, i.e., NroffEdit. we have no problem using xml but also welcome the other editors that simplify this formatting. 
For converting Nroff file to txt , we used linux command and followed instruction of the following link http://www.rfc-editor.org/nroff.html. But it appears that it left some special character. Again thanks for your careful review. I will use your comment in next version and will take care of such special characters.

>In the section 1. you talk about 'named server' I suppose you mean 'name server'?
>Also is there a reason not to mention: rfc 6494?
RFC 6494 focused on Certification management for SEND. In our draft we are interested in the CGA option of SEND. The more details of this option can be found in RFC 3971. This is the why we referred to that rfc 

>"Convention used in this document", section 2, tells about lines starting with
>C: and S:, which don't actually appear in the document?
It was added as a default from the word template. I will remove it. 

>"3.2.1.  Modified TSIG Record format ", first sentence. You make a hint that TSIG is found in RFC1035 (which it isn't)?
The format of all DNS RRs are the same. TSIG also uses the same format as our modified version. This format can be found in RFC 1035.
In the our draft in this sentence "The modified TSIG RR uses the same format as other RRs in use in the DNS field. This is explained in section 3.2.1 RFC-1035... " We wanted just to confirm the same format as the other DNS Resource Records. You cannot find something about TSIG or modified TSIG in RFC 1035. I will change "this is explained " to "the DNS RR format is explained..." . It might clear the case.

>what does the last sentence of section 6 mean:

>    However ,the first step should be done manually the first time it is used to
 >   afford greater security for this process.

>Are you now saying a manual step is still needed?
It is Not required for the authentication of a client to a DNS server and it automates the whole process for them. But to have more secure communication between two or more DNS servers (masters and slaves or ...), we recommended to use one of the 3 mentioned scenarios in section 3.2.1.1 of this draft RFC (especially a. and b.). 

Thank you again,
Best Regards,
Hosnieh

---

From: Donald Eastlake <[email-masked]>
Date: Wed, 24 Oct 2012 09:26:08 -0400

On getting rid of "special characters" in your output, you probably need to
add a " -Tascii " or the like to your command line.

Donald

from iPhone

On Wednesday, October 24, 2012, Rafiee, Hosnieh wrote:

> >First up: it seems you have written this draft by hand? I.e., didn't use
> XML2RFC? There is some markup that is different than normal (i.e. no ^L in
> the page header/footer). If you don't like XML, you >could use my pandoc2rfc
> It was not written in text editor, we first used word template and we
> realized that it is not easy to convert it to text, so again we used
> another program, i.e., NroffEdit. we have no problem using xml but also
> welcome the other editors that simplify this formatting.
> For converting Nroff file to txt , we used linux command and followed
> instruction of the following link http://www.rfc-editor.org/nroff.html.
> But it appears that it left some special character. Again thanks for your
> careful review. I will use your comment in next version and will take care
> of such special characters.
>
>
> RFC 6494 focused on Certification management for SEND. In our draft we are
> interested in the CGA option of SEND. The more details of this option can
> be found in RFC 3971. This is the why we referred to that rfc
>
> >"3.2.1.  Modified TSIG Record format ", first sentence. You make a hint
> that TSIG is found in RFC1035 (which it isn't)?
> The format of all DNS RRs are the same. TSIG also uses the same format as
> our modified version. This format can be found in RFC 1035.
> In the our draft in this sentence "The modified TSIG RR uses the same
> format as other RRs in use in the DNS field. This is explained in section
> 3.2.1 RFC-1035... " We wanted just to confirm the same format as the other
> DNS Resource Records. You cannot find something about TSIG or modified TSIG
> in RFC 1035. I will change "this is explained " to "the DNS RR format is
> explained..." . It might clear the case.
>
> It is Not required for the authentication of a client to a DNS server and
> it automates the whole process for them. But to have more secure
> communication between two or more DNS servers (masters and slaves or ...),
> we recommended to use one of the 3 mentioned scenarios in section 3.2.1.1
> of this draft RFC (especially a. and b.).
>
> Thank you again,
> Best Regards,
> Hosnieh
> _______________________________________________
> dnsext mailing list
> [email-masked] <javascript:;>
> https://www.ietf.org/mailman/listinfo/dnsext
>

-- 
Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [email-masked]

---

From: "Rafiee, Hosnieh" <[email-masked]>
Date: Wed, 24 Oct 2012 16:48:00 +0200

Donald, Thank you so much.
The command I used was nroff -ms myfile | specialcharRemover.pl > output
I will try this parameter "-Tascii" in the command.

Hosnieh

From: Donald Eastlake [mailto:[email-masked]]
Sent: Mittwoch, 24. Oktober 2012 15:26
To: Rafiee, Hosnieh
Cc: Miek Gieben; [email-masked]
Subject: Re: [Int-area] Last Call before IETF meeting: draft-rafiee-intarea-cga-tsig-00.txt

On getting rid of "special characters" in your output, you probably need to add a " -Tascii " or the like to your command line.

Donald

from iPhone

Thank you again,
Best Regards,
Hosnieh
_______________________________________________
dnsext mailing list
[email-masked]<javascript:;>
https://www.ietf.org/mailman/listinfo/dnsext

--
Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [email-masked]<mailto:[email-masked]>

---

From: Mohan Parthasarathy <[email-masked]>
Date: Wed, 24 Oct 2012 09:41:41 -0700

> If you are just using CGAs, what prevents any client from updating *any*
DNS server ? Any rogue client can generate a CGA and send an update to the
DNS server. What prevents this ? It looks like the latest version of your
draft has this:

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 saved manually by the
   administrator. If it is the same, step 8 is executed, otherwise, the
   message should be discarded without further action.

So, you need manual configuration.

-mohan

> [email-masked]

---

From: "Rafiee, Hosnieh" <[email-masked]>
Date: Wed, 24 Oct 2012 20:10:45 +0200

Dear Mohan,

>>It is Not required for the authentication of a client to a DNS server and it automates the whole process for them. But to have more secure communication between two or more DNS servers (masters and >>slaves or ...), we recommended to use one of the 3 mentioned scenarios in section 3.2.1.1 of this draft RFC (especially a. and b.).

>If you are just using CGAs, what prevents any client from updating *any* DNS server ? Any rogue client can generate a CGA and send an update to the DNS server. What prevents this ? It looks like the >latest version of your draft has this:

For a client and a DNS server, as I explained before, there is no need for manual settings. CGA can prove the address ownership by finding the binding between a sender's public key and its (sender's) IP address. No attackers can thus spoof other IP addresses. If an attacker wants to do that, he needs to do a brute force attack against the CGA. This means that a host can only update its own RRs in any DNS server that accepts source IP authentication, and no other hosts' RRs. This prevents IP spoofing attacks.
The second scenario is between DNS servers. Often a DNS server wants to update several RRs that are located on other DNS servers, even though he might not own those RRs. In this particular scenario, it becomes necessary to update the authorized list of that specific zone file with the IP address of this DNS server (IP address of the update requestor). but this occurs only once. If the IP address of that DNS server changes, other DNS servers will have a way of verifying the update requestor. This is done by saving the update requestor's public key when the first verification occurs. In all future requests, after generation of a new IP address, other DNS servers can use CGA for the verification process.
A benefit of this mechanism is the reduction in the number of messages necessary to establish a secure channel between two DNS servers. Moreover, the manual process is needed only once. It does not need to be repeated every time the node changes its IP address. Compared with other security mechanism, the manual intervention required in this procedure is minimal.

>7. Verify the public key
This verification step need only be done for the second scenario, as I stated in the prior answer.

---

From: Mohan Parthasarathy <[email-masked]>
Date: Wed, 24 Oct 2012 15:51:07 -0700

On Wed, Oct 24, 2012 at 11:10 AM, Rafiee, Hosnieh <[email-masked]
> wrote:

> Dear Mohan,****
> >>It is Not required for the authentication of a client to a DNS server
> and it automates the whole process for them. But to have more secure
> communication between two or more DNS servers (masters and >>slaves or
> ...), we recommended to use one of the 3 mentioned scenarios in section
> 3.2.1.1 of this draft RFC (especially a. and b.).****
>
> ** **
>
> DNS server. What prevents this ? It looks like the >latest version of your
> draft has this:****
>
> ** **
>
> For a client and a DNS server, as I explained before, there is no need for
> manual settings. CGA can prove the address ownership by finding the binding
> between a sender’s public key and its (sender’s) IP address. No attackers
> can thus spoof other IP addresses. If an attacker wants to do that, he
> needs to do a brute force attack against the CGA. This means that a host
> can only update its own RRs in any DNS server that accepts source IP
> authentication, and no other hosts’ RRs. This prevents IP spoofing attacks.
>

What do you mean by "its own RRs" ? A/AAAA and PTR records ? I doubt any
DNS server would accept update from any client just because it can verify
the CGA.  All I have to do is to generate a CGA (using random subnet prefix
if there is no ingress filtering) , send an update and keep repeating this
forever.

> ****
>
> The second scenario is between DNS servers. Often a DNS server wants to
> update several RRs that are located on other DNS servers, even though he
> might not own those RRs. In this particular scenario, it becomes necessary
> to update the authorized list of that specific zone file with the IP
> address of this DNS server (IP address of the update requestor). but this
> occurs only once. If the IP address of that DNS server changes, other DNS
> servers will have a way of verifying the update requestor. This is done by
> saving the update requestor’s public key when the first verification
> occurs. In all future requests, after generation of a new IP address, other
> DNS servers can use CGA for the verification process. ****
>
> A benefit of this mechanism is the reduction in the number of messages
> necessary to establish a secure channel between two DNS servers. Moreover,
> the manual process is needed only once. It does not need to be repeated
> every time the node changes its IP address. Compared with other security
> mechanism, the manual intervention required in this procedure is minimal.*
> ***
>
> ** **
>
> >7. Verify the public key ****
>
> This verification step need only be done for the second scenario, as I
> stated in the prior answer.****
>
> ** **
>
This is not clear in the draft. You also need it for first scenario.

-mohan

---

From: Mark Andrews <[email-masked]>
Date: Thu, 25 Oct 2012 10:03:15 +1100

> if there is no ingress filtering) , send an update and keep repeating this

I can see PTR being updated based on CGA.  Named can be configured to update
PTR if the request comes in over TCP from the matching address.  It can
also be configures to update NS and DNAME records if the request comes
in over TCP from a address within the matching /48 (and is is trivial to
extend the code to support other nibble boundaries).

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: SM <[email-masked]>
Date: Wed, 24 Oct 2012 15:44:49 -0700

Hi Hosnieh,
>The command I used was nroff -ms myfile | specialcharRemover.pl > output

See http://www.rfc-editor.org/rfc-editor/2-nroff.template.nroff  You 
can extract the fix.pl script from 2-nroff.template.nroff.

Regards,
-sm

---

From: Mohan Parthasarathy <[email-masked]>
Date: Wed, 24 Oct 2012 16:23:08 -0700

On Wed, Oct 24, 2012 at 4:03 PM, Mark Andrews <[email-masked]> wrote:

>
> In message <CACU5sDmiZcaeHUQZMtA8jH=+
> [email-masked]>, Mohan Parthasarathy writes:
> >

Yes, TCP gives you the return routability check. And this can't be used as
a general mechanism to update any record without additional configuration.

-mohan

---

From: "Rafiee, Hosnieh" <[email-masked]>
Date: Thu, 25 Oct 2012 16:52:13 +0200

Dear Mohan,

Thanks again for your review and strong comments.

From: Mohan Parthasarathy [mailto:[email-masked]]

>What do you mean by "its own RRs" ? A/AAAA and PTR records ? I doubt any DNS server would accept update from any client just because it can verify the CGA.  All I have to do is to generate a CGA (using random subnet prefix if there is no >ingress filtering) , send an update and keep repeating this forever.
If an administrator of a DNS server has enabled  secure DNS update (TSIG that supports the CGA-TSIG algorithm) on his server, then this mechanism can work on those DNS servers. Otherwise they will use a different policy that only accepts a connection from local links or .... a kind of TCP filtering as you also explained .
Because CGA-TSIG is a new algorithm in TSIG. It does the same as TSIG but does not need the first two messages for establish a secure channel. This mechanism enhances the security during the authentication mechanism. It ensures that the DNS server, the one who would like to update a RR (resource records can be PTR, AAAA, CNAME ), is the owner of that resource record. No host has the private key belonging to the other hosts, so they cannot sign the message. It CGA-TSIG verification steps, we also added the signature. This signature will assist the DNS server to double check the owner of that resource records. You as a host can generate a CGA and can generate the signature, but cannot spoof other's CGA.

I will try to improve that section and explain it in more detail.

>This is not clear in the draft. You also need it for first scenario.
When I think more about this process I am in  agreement with you to a certain extent. I agree that the DNS server should also store the  client's public key. This will allow the same client to update his own resource records after generation of the new IP address. But for communication between a client and a DNS server,  there is no need for  the administrator to intercept this process. But for two DNS servers, for the first time,  it is necessary in order to add the IP address to the authorized list. I will edit this section of the draft and try to explain this process in more detail in order to clarify it.

P.S. I am also working on the implementation of CGA-TSIG. If I can finish it before the IETF meeting, I will be able to demo it to those interested.

Thank you
Hosnieh

---

From: "Rafiee, Hosnieh" <[email-masked]>
Date: Thu, 25 Oct 2012 16:52:22 +0200

Hello,
Thank you so much!

Hosnieh

-----Original Message-----
From: SM [mailto:[email-masked]] 
Sent: Donnerstag, 25. Oktober 2012 00:45
To: Rafiee, Hosnieh
Cc: [email-masked]
Subject: Re: [dnsext] [Int-area] Last Call before IETF meeting: draft-rafiee-intarea-cga-tsig-00.txt

Hi Hosnieh,
>The command I used was nroff -ms myfile | specialcharRemover.pl > 

See http://www.rfc-editor.org/rfc-editor/2-nroff.template.nroff  You can extract the fix.pl script from 2-nroff.template.nroff.

Regards,
-sm