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

[Danny Mayer]

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