Network Time Protocol Version 4: Autokey Specification
draft-ietf-ntp-autokey-08

Throughout
s/IPSEC/IPsec/

---

Section 13.2
s/Compouter/Computer/

---

Section 10 has 

   field is present.  If the length is less than 4 or not a multiple of
   4, a format error has occurred and the packet is discarded;
   otherwise, the parser increments the pointer by the length and then
   uses the same rules as above to determine whether a MAC is present or
   another extension field.

It took me several readings of this to parse correctly (admitedly after 
being up for 36 hours and flying in from Asia). Could you consider...

s/length/value of the length field of the extension field that has been 
found/

---

Again in Section 10
   In such cases the Timestamp and Signature Length fields are 0
   and the Signature field is empty.
 
s/empty/absent/

---

Also Section 10

It may be helpful to highlight that the contents of the NTPv4 Extension
Field Format are not word-aligned. That is, the two length fields (Value
Length and Signature Length, which, incidentally, you haven't described) 
can take values that are not multiples of 4, and that padding is only
present at the end of the Extension Field. 

---

A little odd to have the Security Section embedded at 11.6.

---

Section 12
s/PRotocol/Protocol/

--

Like Lars, I am surprised that the protocol parts of this specitication
are not Standards Track. But if the authors and working group are happy
that their protocol extensions will not be implemented or form part of
a standard, then that is fine.

I know that RFC Editor can fix that, but s/RFC3280/RFC5280

In the paragraph on the extension field parser length calculation, says:
>
> If greater than 22 an extension field is present.  If the length is ..
>
It would be clearer to say:
>
> If the remaining length is greater than 22, then an extension field is
> present.  If the remaining length is ...

suggest the following global change:

s/middleman/man-in-the-middle/

In section 6, last sentence in paragraph 3:
s/details are given in Appendix B/details are given in Appendices B through G./

Additional specific comments extracted from the secdir review: 

- In section 8 where the Sign Exchange is described, the server is to
extract "the subject, issuer and extensions fields" then build a new
certificate with that data along with "its own serial number and
expiration time" and signed using its private key.  There are several
potential problems with this, including: the issuer name may be
inappropriate, extraction of the public key is not mentioned, revocation
is not mentioned (should the certificates have short life times to
compensate), the extensions field may have inappropriate values.

- In 11.4.1, I'm guessing PREV should be PROV.  Also, ENB is not
expanded anywhere in the draft (elsewhere ENAB is used but also not
expanded).

- In 11.7, a middleman is said to be unable to produce a valid
signature.  Why is this the case given the trusted certificate is
returned by the server?  There are no trusted public keys listed in the
client state in section 11.3 and the CERT exchange seems to end only
when the server sends a self-signed certificate.  Assuming the client
has a set of trusted public keys (trust anchors), the CERT exchange may
work better if the name sent by the client was the name of a trust
anchor and the server sent down the full path in one shot. 

- H.2 states that the semantics of certificate fields "generally
conforms with conventional usage, there are subtle variations".  Some of
these variations are problematic.  The description of the
ExtendedKeyUsage extension refers to populating it with string values.
The extension is a sequence of OIDs.  Similarly it refers to a string
values in basic constraints and keyUsage extensions. 

- The Name example in H.2 should have a SET as the outermost layer
(containing the current SEQUENCE).  Similarly, the validity example
seems to require UTCTime. 

- There are several references to RFC 2510 that should probably be
changed to refer to RFC 5280.  References to RFC 3280 should be changed
to RFC 5280.