Network Time Protocol Version 4: Autokey Specification
RFC 5906

Note: This ballot was opened for revision 08 and is now closed.

(Ralph Droms) Yes

(Ron Bonica) No Objection

(Ross Callon) No Objection

(Lisa Dusseault) No Objection

(Adrian Farrel) (was Discuss, No Objection) No Objection

Comment (2009-06-18)
No email
send info
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.

(Russ Housley) (was Discuss) No Objection

Comment (2009-08-19)
No email
send info
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 ...

Alexey Melnikov No Objection

Comment (2009-06-15 for -)
No email
send info
I know that RFC Editor can fix that, but s/RFC3280/RFC5280

(Tim Polk) (was No Record, Discuss) No Objection

Comment (2009-06-17)
No email
send info
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.

(Dan Romascanu) No Objection

(Robert Sparks) No Objection

(Pasi Eronen) (was Discuss, Abstain) Abstain

Comment (2010-02-17 for -)
No email
send info
I have two major concerns with this document.
 
First, the document is mostly incomprehensible -- I don't think anyone
can figure out how the protocol works, or determine whether it's OK or
badly flawed security-wise, based on reading this document. (Since a
potential attacker will also face this problem, I guess you could call
it security by obscurity...)

Second, it looks like the document and its normative references don't
really contain enough details to get interoperable implementations
(especially the details for secure implementation of the identity
schemes seem very sparse).

However, most of the specification is mainly of historical interest,
and it seems unlikely that anyone will ever attempt writing a new
implementation based on it. Partly because of this situation, it also
seems the energy required to re-write this document to meet the usual
IETF specification quality level does not exist.

Since the alternatives seem to be publishing roughly as-is and not
publishing at all, I'm grudgingly moving to "Abstain" (although I
would have preferred publishing this as Historic instead of
Informational).

(Cullen Jennings) Abstain

Comment (2009-06-17 for -)
No email
send info
I would like to understand a bit more about how much security review this has had.

(Lars Eggert) No Record

Comment (2009-06-16 for -)
No email
send info
I'm still reviewing this document, but have one meta-question: Why is this not on the standards track?