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

[Ballot comment]
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).

[Ballot comment]
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 ...

[Ballot discuss]
The Gen-ART Review by Joel Halpern reports two problems that ought to
  be corrected prior to approval.  RFC Editor notes would be fine.

  1. Two individual sentences became truncated (Section 7, first
    paragraph "was created." => "was." and section 8, third bullet
    "the server."=>"the.")

  2. Section 8 on the Sign exchange previously said that the information
    was signed using the private key.  Now it says that it is signed
    using the public key.  As I understand it, the signature is
    generated with the private key to be verified with the public key.
    I am not sure what the right words in the paragraph would be.  (I
    was happy with "private key" before since the signer used his own
    private key.)

[Ballot comment]
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.

[Ballot discuss]
In discussion with the IESG I understand that this document describes the motivations, procedures, and protocol elements for NTP Autokey as implemented in a specific implementation. As such, the work is supposed to be informative, and it is appropriate to publish it as an Informational RFC.

However, the tone of the text in the I-D gives a very different impression. When I read the document, I formed the strong opinion that it was defining protocol extensions. The mention of a "reference implementation", I thought, was only intended to provide validation of the procedures. Hence my Comment wondering why the document was not Standards Track.

I would like you to make it much clearer that the objective is to document the behavior of an implementaiton and not to define extensions to the standard protocol.

In the Abstract and in the final paragrpah of the Introduction, you could add some text such as:
  This informational document describes the NTP extensions for
  Autokey as implemented in an NTPv4 software distribution
  available from http://www.ntp.org.  This description is provided
  to offer a basis for future work and a reference for the
  software release.

  This document also describes the motivation for the extensions
  within the protocol.

It would also probably be helpful to add a section (Section 1.1?) to provide more details about the reference implementation.

[Ballot discuss]
I'd like to discuss with other ADs during the telechat what to do with
this. The document is mostly incomprehensible, and if it's secure,
it's probably because no attacker can figure out how it works either.
And it looks like it doesn't even have enough details to get
interoperable implementations.

However, considering that the goal is to document an existing
(open source) implementation (and not to improve the protocol),
I'm wondering if sending this back to the WG would really result
in big improvements either...

[Ballot comment]
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.

[Ballot comment]
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.

[Ballot discuss]
[Some parts of this discuss and comments are drawn from Carl Wallace's secdir review posted
June 15].

(1) This specification oscillates between specifying the protocol and documenting the reference
implementation.  As a consequence, the conformance requirements are unclear in a number
of cases.  The situation could be improved by the usage of 2119 language and by selecting
MUST implement features where multiple choices exist.  Alternatively, the specification could
clearly state that all the features MUST be supported).

(2) In particular, five identity schemes are supported in the reference implementation.  The TC
scheme is specified as the default. I would presume the default scheme is
mandatory-to-implement, but the expectations with regard to the PC, IFF, GQ and MV
schemes are unclear.  Given that the MV scheme is "devilishly complicated" it might
of particular interest to implementers to learn whether this scheme is required.  PC is
described as useful for testing only... was this testing restricted to the reference
implementation or is it needed when standing up a new system?  If it is only for testing
the reference implementation, perhaps we should eliminate this text or clearly note
as deprecated.

(3) Guidance on certificate lifetimes and/or revocation processing should be added to
the security considerations section.

(4) Where a server has multiple certificates, does the protocol provide any hint which to use
when interacting with dependent clients?

(5) Section 7 states  "All cryptographic values used by the protocol are time sensitive and
are regularly refreshed".  The security considerations section should probably expand on
this concept and provide guidelines for the refresh rate.

(6) Sections 11.7 and 11.8 are subsections of 11.6 Security Considerations.  I believe that
these sections should be renumbered as 12 Security Considerations, with subsections
12.1 and 12.2.

[Ballot comment]
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.

[Ballot discuss]
[Some parts of this discuss and comments are drawn from Carl Wallace's secdir review posted June 15].

(1) This specification oscillates between specifying the protocol and documenting the reference implementation.  As a consequence, the conformance requirements are unclear in a number
of cases.  The situation could be improved by the usage of 2119 language and by selecting
MUST implement features where multiple choices exist.  Alternatively, the specification could
clearly state that all the features MUST be supported).

(2) In particular, five identity schemes are supported in the reference implementation.  The TC
scheme is specified as the default. I would presume the default scheme is
mandatory-to-implement, but the expectations with regard to the PC, IFF, GQ and MV
schemes are unclear.  Given that the MV scheme is "devilishly complicated" it might
of particular interest to implementers to learn whether this scheme is required.  PC is
described as useful for testing only... was this testing restricted to the reference
implementation or is it needed when standing up a new system?  If it is only for testing
the reference implementation, perhaps we should eliminate this text or clearly note
as deprecated.

(3) Guidance on certificate lifetimes and/or revocation processing should be added to
the security considerations section.

(4) Where a server has multiple certificates, does the protocol provide any hint which to use
when interacting with dependent clients?

(5) Section 7 states  "All cryptographic values used by the protocol are time sensitive and
are regularly refreshed".  The security considerations section should probably expand on
this concept and provide guidelines for the refresh rate.

(6) Sections 11.7 and 11.8 are subsections of 11.6 Security Considerations.  I believe that
these sections should be renumbered as 12 Security Considerations, with subsections
12.1 and 12.2.

[Ballot discuss]
The Gen-ART Review by Joel Halpern on 5-June-2009 has lead to some
  discussion with the authors.  Not all of the issues have been
  resolved, but it is clear that some changes to the document are
  needed.  The following issues are still unresolved.

  The usage within Autokey of the extension field need description early
  in the document.  Paragraph 3 of Section 10 reserves seven values (1-7)
  Autokey. The "Field Type" field performs two roles: identification as
  an Autokey extension and defining the type within Autokey.

  Section 11.1 includes a 16 bit Digest / Signature NID.  There is no
  description of how this is used.

  The wording on hierarchy in section 5, paragraph 3 is the opposite of
  what is shown in the figure.  (The figure matches expectations, where
  a client of one group operates as the TH of a group operating at a
  lower stratum.)

  In Section 10, the paragraph that begins "[T]he extension field parser
  initializes a pointer..." is incorrect.  The "length" by which the
  pointer is increment is the length in the extension header, not the
  length computed by subtracting the NTP header from the packet length.

  In figure 5, it would help the reader if the groups and hosts had
  different names.  (Even just calling the groups Alice-Group and
  Carol-Group would help.)

  In section 5, in the description of "[t]he steps in hiking the
  certificate trails...", in step 1, in the second sentence, please add
  language to make it clear that the server is "exchanging host names
  and negotiating..." with is the server from whom it is getting
  information.

  Section 8 should be moved earlier in the document.  Early parts of the
  document assume an understanding of properties of the system which
  have not been described yet.

  Section 11.6 (Security Considerations) is supposed to be a top-level
  section.

IANA questions/comments:

- What are the names and/or descriptions (depending on the registry
format) of the proposed registrations?

- How should the registry be formatted? Do you want columns for
value, name, description, and reference, for example?

Please note that we have not yet received any response to our
questions about draft-ietf-ntp-ntpv4-proto, which will create the
registry in question.

(1.a) Who is the Document Shepherd for this document? Has the Document
Shepherd personally reviewed this version of the document and, in
particular, does he or she believe this version is ready for forwarding
to the IESG for publication?

Karen O'Donoghue is the document shepherd. She has reviewed this
version of the document and believes it is ready for the IESG.

(1.b) Has the document had adequate review both from key WG members and
from key non-WG members? Does the Document Shepherd have any concerns
about the depth or breadth of the reviews that have been performed?

Yes, the document has received adequate review and the document shepherd
has no concerns with those reviews.

(1.c) Does the Document Shepherd have concerns that the document needs
more review from a particular or broader perspective, e.g., security,
operational complexity, someone familiar with AAA,
internationalization or XML?

No.

(1.d) Does the Document Shepherd have any specific concerns or issues
with this document that the Responsible Area Director and/or the IESG
should be aware of? For example, perhaps he or she is uncomfortable with
certain parts of the document, or has concerns whether there really is a
need for it. In any event, if the WG has discussed those issues and has
indicated that it still wishes to advance the document, detail those
concerns here. Has an IPR disclosure related to this document been
filed? If so, please include a reference to the disclosure and summarize
the WG discussion and conclusion on this issue.

No.

(1.e) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others being
silent, or does the WG as a whole understand and agree with it?

The document shepherd believes that the WG as a whole supports this
document.

(1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is entered into the ID
Tracker.)

No.

(1.g) Has the Document Shepherd personally verified that the document
satisfies all ID nits? (See
http://www.ietf.org/ID-Checklist.html and
http://tools.ietf.org/tools/idnits/). Boilerplate checks are not
enough; this check needs to be thorough. Has the document met all formal
review criteria it needs to, such as the MIB Doctor, media type and URI
type reviews?

Yes

(1.h) Has the document split its references into normative and
informative? Are there normative references to documents that are not
ready for advancement or are otherwise in an unclear state? If such
normative references exist, what is the strategy for their completion?
Are there normative references that are downward references, as
described in [RFC3967]? If so, list these downward references to support
the Area Director in the Last Call procedure for them [RFC3967].

The references are split into normative and informative dependencies.
The one normative reference is to the NTPv4 specification
(draft-ietf-ntp-ntpv4-proto-11.txt) which has been submitted to the IESG
in a parallel submission to this document. It is expected that these
documents will progress together and not cause any issues.

(1.i) Has the Document Shepherd verified that the document IANA
consideration section exists and is consistent with the body of the
document? If the document specifies protocol extensions, are
reservations requested in appropriate IANA registries? Are the IANA
registries clearly identified? If the document creates a new registry,
does it define the proposed initial contents of the registry and an
allocation procedure for future registrations? Does it suggest a
reasonable name for the new registry? See [RFC5226]. If the document
describes an Expert Review process has Shepherd conferred with the
Responsible Area Director so that the IESG can appoint the needed Expert
during the IESG Evaluation?

The IANA Considerations section is consistent and clear.

(1.j) Has the Document Shepherd verified that sections of the document
that are written in a formal language, such as XML code, BNF rules, MIB
definitions, etc., validate correctly in an automated checker?

N/A.

(1.k) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary:

This document describes the Autokey security model for authenticating
servers to clients using the Network Time Protocol (NTP) and public key
cryptography. Its design is based on the premise that IPSEC schemes
cannot be adopted intact, since that would preclude stateless servers
and severely compromise timekeeping accuracy. In addition, PKI schemes
presume authenticated time values are always available to enforce
certificate lifetimes; however, cryptographically verified timestamps
require interaction between the timekeeping and authentication
functions.

This document includes the Autokey requirements analysis, design
principles and protocol specification. A detailed description of the
protocol states, events and transition functions is included. A
prototype of the Autokey design based on this memo has been implemented,
tested and documented in the NTP Version 4 (NTPv4) software distribution
for Unix, Windows and VMS at http://www.ntp.org.

Working Group Summary:

The NTP working group has done extensive reviews of this document, and
it reflects the consensus of the working group.

Document Quality:

This document has been reviewed by several members of the
ntpwg@lists.ntp.org mailing list and by the NTP WG chairs.