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

From: Joshua Shire <[email-masked]>
Date: Fri, 16 Nov 2012 15:00:53 -0700

Hello,

Just a few observations after reviewing this:

1) RFC3972 ("CGA") specifies that the modifier should be 64 bits and the collision count eight bits, yet I notice in Figure 2 it specifies a 16 bit modifier and a 1 bit collision count. Can you explain why you chose to implement this differently?
2) In your implementation of the protocol you call for DAD but it does not mention (or maybe I just can't find) what do re: collision count if a duplicate address is detected. Further, in 3.2.1.2 I don't see a step to verify this number as per CGA. I'm assuming you're to follow the specs from CGA but you may want to be specific regarding this.
3) In 3.1 step 5 you may want to be clear that bits seven and eight should be set to zero.
4) In 3.2.1.2, step 2, Check Time Signed, your window seems very short given typical retransmission timeouts and the like. 
5) 3.2.1.2 step 5, Verify the signature, I don't see exact method you want used in this protocol to accomplish this. 

Just an overall note, and this likely has more to do with me that you, I'm a bit confused as to how this would functionally integrate on a host using a CGA. Would you actually be running these algorithms again just for the purpose of sending a DNS update or would you be layering on top of the existing IP stack and using the existing CGA functionality?

Thanks,

Joshua Shire
Information Systems Manager
Hyduke Energy Services Inc.
ph: 780-955-0401
fax: 780-955-0368
mx: [email-masked]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Rafiee, Hosnieh
Sent: Tuesday, October 23, 2012 9:07 AM
To: [email-masked]
Cc: [email-masked]
Subject: [Int-area] Last Call before IETF meeting: draft-rafiee-intarea-cga-tsig-00.txt

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

_______________________________________________
Int-area mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/int-area

---

From: "Rafiee, Hosnieh" <[email-masked]>
Date: Sat, 17 Nov 2012 00:48:36 +0100

Dear Joshua,
Thank you so much for your comments. Please find the answer below.

>1) RFC3972 ("CGA") specifies that the modifier should be 64 bits and the collision count eight bits, yet I notice in Figure 2 it specifies a 16 bit modifier and a 1 bit collision count. Can you expl…
- No, that was a typo. It will be corrected in the updated version that I will submit this weekend

- After I implemented this draft RFC, I noticed that the values must be cached and the DNS server should not be involved in generating CGA values or be involved in addressing. So, this section is for the SEND implementation installed on a DNS server or a client. In my new draft this section will also be updated.

-I will correct it and included in my update version.

- I will examine my implemenation on a larger scale to see what the delay will be and will update the document accordingly.

- Please clarify this question. As you probably know, the signature verification function uses a minimum of 2 values; the plaintext and the signature itself.  The default algorithm here is RSA. This is what I meant when I said signature verification. The DNS server retreives all the plaintext contents (CGA parameters, time signed, DNS update) of the signature and also the signature itself and then verfies this signature using the RSA algorithm. The result is a boolean value. 
 
Joshua >Would you actually be running these algorithms again just for the purpose of sending a DNS update or 
- No, just data cached in the server. The current SEND implementation would cache this data when the server or a client wants to generate a new IP address using SEND. CGA-TSIG is an application layer protocol. 
Joshua >would you be layering on top of the existing IP stack and using the existing CGA functionality?
Yes

Best,
Hosnieh

---

From: Joshua Shire <[email-masked]>
Date: Mon, 19 Nov 2012 14:04:36 -0700

Thanks for your responses.

Speaking of typos, the modifier is actually 128 bits not 64 as I stated ;).

Regarding 4), Check Time Signed, if you look at a widely used standard like Kerberos, it calls for a rough clock sync of 5 minutes. For the purposes of anti-replay prevention (which I believe this step in your protocol is designed to thwart?) it seems to provide good security without causing too many issues (but you still do get clients with errors popping up from time to time). Lastly regarding 5), signature, that's fine, you just may want to be specific that RSASSA-PSS (or something else) should be used rather than leaving it up to interpretation or preference, which may cause interoperability issues. Just a suggestion.

Thanks,

Joshua Shire

-----Original Message-----
From: Rafiee, Hosnieh [mailto:[email-masked]] 
Sent: Friday, November 16, 2012 4:49 PM
To: Joshua Shire
Cc: [email-masked]
Subject: RE: Last Call before IETF meeting: draft-rafiee-intarea-cga-tsig-00.txt

Dear Joshua,

 

Best,
Hosnieh

---

From: "Rafiee, Hosnieh" <[email-masked]>
Date: Mon, 19 Nov 2012 22:29:47 +0100

Dear Joshua,
Thanks a lot for your suggestions.

>Speaking of typos, the modifier is actually 128 bits not 64 as I stated ;).
Yes I understand. It was a mistake. In my implementation I did not make this funny mistake but it seems in writing I did :-)
If I can update my RFC (currently having formatting issue for uploading...) then the new version will hopefully be free of these kinds of mistakes.

>Regarding 4), Check Time Signed, if you look at a widely used standard like Kerberos, it calls for a rough clock sync of 5 minutes. For the purposes of anti-replay prevention (which I believe this step in >your protocol is designed to thwart?) it seems to provide good security without causing too many issues (but you still do get clients with errors popping up from time to time). Lastly regarding 5), >signature, that's fine, you just may want to be specific that RSASSA-PSS (or something else) should be used rather than leaving it up to interpretation or preference, which may cause interoperability >issues. Just a suggestion.
I clarified this in new version.

Maybe somebody can give me a suggestion... I actually wrote a Web application that should aid in formatting RFC (maybe also later useful for others as it will be available public on my website). It works fine and generates a nice txt version with the required tags but when I want to submit this draft I receive meta-data error and it cannot retreive the authors' names. I compared the output of my application with the one that does not have any problem in different formats such as  ASCII, but I could not find any special characters or any problem that cause this failure result. 
I look forward to receiving any help I can get to make this application generate a file that is acceptable for automatic process submission. (If I knew what the IETF parser was looking for, I could add it to my application to make it work. But I could not find anything anywhere)

Best,
Hosnieh

-----Original Message-----
From: Joshua Shire [mailto:[email-masked]] 
Sent: Monday, November 19, 2012 10:05 PM
To: Rafiee, Hosnieh
Cc: [email-masked]
Subject: RE: Last Call before IETF meeting: draft-rafiee-intarea-cga-tsig-00.txt

Thanks,

Joshua Shire

-----Original Message-----
From: Rafiee, Hosnieh [mailto:[email-masked]] 
Sent: Friday, November 16, 2012 4:49 PM
To: Joshua Shire
Cc: [email-masked]
Subject: RE: Last Call before IETF meeting: draft-rafiee-intarea-cga-tsig-00.txt

Dear Joshua,

 

Best,
Hosnieh

---

From: SM <[email-masked]>
Date: Mon, 19 Nov 2012 14:37:24 -0800

At 13:29 19-11-2012, Rafiee, Hosnieh wrote:
>I look forward to receiving any help I can get to make this 
>application generate a file that is acceptable for automatic process 
>submission. (If I knew what the IETF parser was looking for, I could 
>add it to my application to make it work. But I could not find 
>anything anywhere)

The idnits source code is available at 
http://tools.ietf.org/tools/idnits/  You might try asking on 
tools-discuss ( https://www.ietf.org/mailman/listinfo/tools-discuss 
).  I am not sure whether it is off-topic for that mailing list.

Regards,
-sm