Last Call Review of draft-ietf-ntp-autokey-
review-ietf-ntp-autokey-secdir-lc-wallace-2009-06-16-00

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the IESG.
These comments were written primarily for the benefit of the security
area directors.  Document editors and WG chairs should treat these
comments just like any other last call comments.

This draft describes a protocol for authenticating Network Time Protocol
(NTPv4) servers to clients.

General comments
- I think the draft would benefit from the usage of 2119 language.  At
present, it often seemed to be describing the reference implementation
instead of providing a protocol specification that would enable
interoperability.  For example, the following appears in section 11:
"while the high order 16 bits specify the message digest/signature
encryption scheme as encoded in the OpenSSL library".  

- I don't follow why it was necessary to invent new words for this draft
(i.e., proventic) and found myself simply substituting existing words
for the new words.  

- Is the Informational the correct status for this?

Specific comments
- Why use a self-signed certificate as a means of requesting
certificates instead of P10 (or CMC or CMP)?  The draft makes no mention
of checking the signature on this request or checking the contents of
the request in any way.    

- 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.

- The diagrams in section 5 appear to indicate that a server may be
issued a certificate from multiple superiors.  Section 8 doesn't
indicate how a server should select which of the certificates issueed to
it should be used when interacting with its dependent clients.  

- 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).

- Section 7 states "All cryptographic values used by the protocol are
time sensitive and are regularly refreshed."  The security
considerations section should expand on this.

- I think sections 11.7 and 11.8 should be renamed as 11.6.1 and 11.6.2.

- 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.

- I focused on the "trusted certificate" scheme and have not yet
reviewed the other identity schemes and was fairly quick in reading some
other sections.