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

[David L. Mills]

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

Danny Mayer 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
> 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