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

[Brian Haberman]

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


David L. Mills wrote:
> 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
> 
> 
> _______________________________________________
> ntpwg mailing list
> ntpwg at lists.ntp.org
> https://lists.ntp.org/mailman/listinfo/ntpwg