Subject: Re: [ntpwg] NTP WG Last Call:draft-ietf-ntp-autokey-03.txt

From: Danny Mayer <[email-masked]>
Date: Fri, 08 Aug 2008 08:27:18 -0400

Here is my review of the document. I have read the document and except 
for the minors issues detailed below, I believe that it is ready to be 
moved forward.

P1. Header
Obsoletes RFC1305. Autokey is not described in RFC 1305 and in any case 
this is an Informational RFC rather than standards track and should not 
be able to obsolete any standards track RFC. That would require another 
standards track RFC. I am however supportive of making this a standards 
track RFC.

P7 Section 3
Change "with exceptions as noted in the NTP software documentation" to 
"with exceptions as noted in the NTPv4 RFC [Reference here]."

P7 Section 3 Item 1
change the reference of [RFC1305] to [NTPv4 RFC].

P12 Section 5
Change "posts the client keys on a public web site" to "delivers the 
client keys by secure means"

P14 Item 1
Change "The girls" to "The servers"

P17 at top of page
The sentence "In order to foil such attacks, every Autokey message 
carries a timestamp in the form of the NTP seconds when it was. "
is missing a word or two at the end. Please complete the sentence. Is 
this just missing the word "created"?

P18 Last item: Cookie exchange
"The request includes the public key of the." is missing a word. Is this 
meant to be "server"?

P19 Second item: Sign exchange
      "It
       extracts the subject, issuer, and extension fields, builds a new
       certificate with these data along with its own serial number and
       expiration time, then signs it using its own public key and
       includes it in the response."

I would have expected it to use its private key to sign the response not 
its public key or am I misunderstanding the design?

P22 Bottom of page
Change "remaining data are the MAC" to "remaining data is the MAC" 
(singular, not plural, there's only one MAC).
Change "lengthuses uses" to "length uses"

P21 Section 10 Autokey Protocol Messages
Add a separate paragraph after the first paragraph that states the 
following:
"The following terms: light, lit, etc. means that the bit value is set 
to 1, while the terms dark, dim, etc. means that the bit value is set to 
0".
This is necessary since the terms are used liberally throughout this 
section without assigning a specific meaning to them.

P27 Section 11.1
The term livelock is used without being defined as to its meaning.

P30 Section 11.4.1 Last sentence
Change "This example and others assumes the IFF identity scheme has been 
selected in the parameter exchange.." to
"The following example and others assumes the IFF identity scheme has 
been selected in the parameter exchange."

P34 second paragraph from bottom
   "In order to reduce
    the vulnerability in such cases, the crypto-NAK, as well as all
    responses, is believed only if the result of a previous packet sent
    by the client and not a replay, as confirmed by the NTP on-wire
    protocol."
to
   "In order to reduce
    the vulnerability in such cases, the crypto-NAK, as well as all
    responses, is believed only if the result of a previous packet sent
    by the client is not a replay, as confirmed by the NTP on-wire
    protocol."
I'm changing "and not a replay" to "is not a replay" which is what I 
believe is the intent of the sentence.

P35 Section 11.7
Change "tempoerarily revers" to "temporarily reverts"

P37 Section 12
"Any IANA registries needed?" to
"IANA is requested to add to the Extension Field Types associated with 
the NTP protocol (see NTPv4 RFC section 16), the values 1 through 7 for 
the autokey protocol."

Please let me know if you need additional clarification on these items.

Danny
_______________________________________________
ntpwg mailing list
[email-masked]
https://lists.ntp.org/mailman/listinfo/ntpwg

---

From: "David L. Mills" <[email-masked]>
Date: Fri, 08 Aug 2008 17:59:21 +0000

Brian,

I don't have the XML for the current version 10. Can you make the changes?

Dave

Danny Mayer wrote:

> Obsoletes RFC1305. Autokey is not described in RFC 1305 and in any 
> case this is an Informational RFC rather than standards track and 
> should not be able to obsolete any standards track RFC. That would 
> require another standards track RFC. I am however supportive of making 
> this a standards track RFC.
>
> P7 Section 3
> "The request includes the public key of the." is missing a word. Is 
> this meant to be "server"?
>
> I would have expected it to use its private key to sign the response 
> not its public key or am I misunderstanding the design?
>
> P22 Bottom of page
> to 1, while the terms dark, dim, etc. means that the bit value is set 
> to 0".
> Change "This example and others assumes the IFF identity scheme has 
> been selected in the parameter exchange.." to
> the NTP protocol (see NTPv4 RFC section 16), the values 1 through 7 
> for the autokey protocol."
>

---

From: "David L. Mills" <[email-masked]>
Date: Fri, 08 Aug 2008 18:08:50 +0000

Guys,

Oop; Danny speaks of the autokey last call, not the NTPv4. I can take 
care of this.

Dave

---

From: Brian Haberman <[email-masked]>
Date: Fri, 08 Aug 2008 14:09:36 -0400

Hi Dave,
      Yes, I will make these changes and submit a new version.

Regards,
Brian

---

From: "David L. Mills" <[email-masked]>
Date: Fri, 08 Aug 2008 18:16:14 +0000

Danny,

I have a serious problem. According to your message, you refer to 
version 3, but the current markup version resulting from the last batch 
of changes that I sent to Brian is version 5.

Dave

---

From: "David L. Mills" <[email-masked]>
Date: Fri, 08 Aug 2008 18:18:20 +0000

Brian,

Thanks for that.

Dave

Brian Haberman wrote:

>>> Here is my review of the document. I have read the document and 
>>> except for the minors issues detailed below, I believe that it is 
>>> ready to be moved forward.
>>>
>>> P1. Header
>>> require another standards track RFC. I am however supportive of 
>>> making this a standards track RFC.
>>>
>>> P7 Section 3
>>> Change "with exceptions as noted in the NTP software documentation" 
>>> to "with exceptions as noted in the NTPv4 RFC [Reference here]."
>>>
>>> P7 Section 3 Item 1
>>> is missing a word or two at the end. Please complete the sentence. 
>>> Is this just missing the word "created"?
>>>
>>> "The following terms: light, lit, etc. means that the bit value is 
>>> set to 1, while the terms dark, dim, etc. means that the bit value 
>>> is set to 0".
>>> "The following example and others assumes the IFF identity scheme 
>>> has been selected in the parameter exchange."
>>>
>>> "IANA is requested to add to the Extension Field Types associated 
>>> with the NTP protocol (see NTPv4 RFC section 16), the values 1 
>>> through 7 for the autokey protocol."
>>>

---

From: "TS Glassey" <[email-masked]>
Date: Fri, 8 Aug 2008 11:54:18 -0700

Can we postpone Last call for a week then to verify that the updated version 
is what is advanced?

Todd

---

From: Brian Haberman <[email-masked]>
Date: Fri, 08 Aug 2008 16:51:37 -0400

Dave,
      Danny reviewed the right version based on the IETF draft 
numbering.  The latest version you sent me incorporated someone else's 
comments and has not been submitted as an IETF draft yet.

Regards,
Brian