[ntpwg] Autokey Specification Review

[Danny Mayer]

I have reviewed the autokey draft:
http://www.ietf.org/internet-drafts/draft-ietf-ntp-autokey-00.txt

and I have a number of issues and changes to recommend. Unfortunately I
don't think this document is ready. I have not yet read the Appendices
yet, but that can follow later. Apart from that here is my feedback on
the document. Dave, if you can provide the layouts needed of the bits
highlighted below, this can be speedily moved along.

Thanks,
Danny

Important Issues
1) There are missing figures that shows the layout of the bits of the
autokey information described in 10.5. There's nothing wrong with the
description per se but there are code fields, version fields, error
flags, etc. which are not laid out anywhere nor does it show or say
where it goes in the extension field. It would, therefore be impossible
to implement based on the draft. This is a showstopper and must be fixed
before we proceed. It's not a big effort but must be done. All fields
must be laid out and specified. It should also be noted that the value
in the field MUST be 0 if not used. This will help with future
extensions being compatible with earlier implementations.

2) The discussion of NAT on P10 should be removed since this would not
be implementable with the described protocol since both sides need to
make use of a previously agreed upon set of values to be used to create
queries and responses. A different set *requires* a different ID of some
kind which would indicate what set of values to use, provided of course
that both sides support that variant of autokey.

3) P14 Item 4
It is not clear from the text what server is being used to retrieve the
certificates. Does the client follow the chain and query each server
issuing the certificate on the list and going up the chain. If it comes
from the same server doing the authentication and therefore is
selfserving in effect, rendering the certificate suspect or does it
query each server listed in the certificate. If it queries a different
server what's the process for sending and receiving packets from that
server?

4) P19
The second paragraph talks about certificate trails. It also talks about
a vunerability "In this scheme keys, parameters and certificates can be
refreshed at any time, but a masquerade vulnerability remains unless a
request to sign a client certificate is validated by some means such as
reverse-DNS."

I have no idea what this means nor how doing reverse DNS (looking for
the PTR record) will help. Note that most of the time only the first PTR
record is looked at by common usage. If this is the case, it needs to be
remembered that systems that use self-registration of their name and IP
address (mainly Windows) are likely to leave additional PTR records in
the DNS so that other hosts will then be listed and can thereby be used
as a mode of attack. The necessity of registration here needs to be
highlighted if it is to be used since the DNS administrator will need to
ensure that the requisite PTR records are there. In addition *all* PTR
records returned would need to be examined.

5) P24 top of page
Mention is made of NTP filestamps. However there is no discussion of
what the NTP filestamp is how it is created or why it is used.

6) P25 Top
The sentence "The signature covers the entire extension field, including
the timestamp and filestamp, where applicable." needs to make clear that
it *only* covers the extension field itself and not any other extension
field nor the rest of the NTP packet itself.

7) P27  IFF (0x0200)
This status bit should be renamed as it gets confused with the IFF
autokey scheme which is unrelated to this. I recommend using ICC
(identity credentials confirmed) instead. If so IFF needs to replaced
where appropriate in the document with ICC.

8) P32 Figure 9
One of the fields is specified as a filestamp. However there is no
discussion of what it is how it is used or where it came from. This
makes an independent implementation impossible without clarification.
The Timestamp needs to be similarly specified.

9) P33 Section 10.5 First paragraph on that page.
It is not clear what are the conditions for lighting the error bits. All
situations which light any of the error bits should be described.

10) P33-34 Section 10.5.2
When talking about the string returned by gethostname() and assumption
of a minimum of 4 characters is made. However a common name is "www"
which is only 3 characters. The name (aka label) in DNS is limited to 63
octets so the limit here should be 63 rather than 256. Note that usage
of the host name is not specified in the document and needs to be. See
RFC 1034 Section 3.1.

11) P34 Section 10.5.3
Does the CERT message only occur between the client and the one server
or does the client make subsequent request for CERT from the server
named in the certificate? If the former, how does the client tell that
this is a valid signature since the server is self-serving on the
validity of the certificate?

12) P35 Section 10.5.6
The Leapseconds table message format needs to be laid out

13) P42 Section 12
The sentence "One of the reasons for this is the need for
compatibility with previous NTP versions;" makes me think that an
autokey version field should be bumped to differentiate between
versions. However it is not clear from this whether it's really NTP
versions that is being discussed here or autokey. Note that the NTP
packet already has the NTP version number so it is clear what version of
NTP is being used.

14) P45 Section 13
IANA Registry:
a) Autokey scheme types: GQ, IFF,MV, etc.
b) Autokey Message Types: CERT, COOKIE, AUTO, etc.

Since this is an Informational RFC can these be registered with IANA?


Nits
1) P4 Section 1 Para 1i
The sentence "Ubiquity requires that any client can verify the
authenticity of any server using only public information."
is incorrect since it also uses private information as also stated later
on in the next paragraph: "involving both public and private components"

2) Replace all references to report with RFC (or draft) since that's
what this is. There are numerous references to the draft as a report.

3) P7 Item 2.
replace "regenerated" with "regenerate"

4) P7 Item 6.
What does "errored packets" mean?

5) P7 Item 4.
"A special trusted agent (TA)" does not seem to be discussed anywhere.

6) P8 Top line
Replace "authenticate client" with "authenticate server".

7) P8 Sentences before Section 3.
The sentences discussing the hostname (starting with "In the NTP design"
it is not clear why this is necessary nor how it is used.

8) P8 Item 1
This references [8] which is RFC1305. However that is being obsoleted by
the NTPv4 draft, but I don't believe that there is a symmetric key
scheme described there.

9) P10 Middle of Page
The discussion of cookies. Shouldn't we require that the cookie MUST be
0 if there are extension fields or is it possible that it is meant for
other potential purposes?

10) P20 Section 7
The server dance sentence suggested by Steve Kent should be moved to a
reference since this has nothing to do with the protocol. By putting it
into a reference it will also make it much more visible.

11) P24 Section 9
This section needs to make clear that the autokey protocol is
implemented by an extension field in the NTP protocol packets.

12) P32 Figure 9
This figure needs to be relabeled "NTP4 Autokey Extension Field Format"

13) P32 First paragraph under Figure 9.
Add a Note that UDP imposes its own restriction of 65535 including the
IP headers and UDP headers. In practice firewalls also restrict the size
of various UDP packets.

14) P36, P37, P39 pseudocode
Replace:
else if (IDN & IFF && !IFF)
with:
else if (IDN & IFF && !ICC)

Also the MV scheme is altogether missing in these psuedocodes. Add

else if (IDN & MV && !IFF)
        /* MV identity exchange */
        MV_challenge;
and replace !IFF elsewhere with !ICC.

15) P41 Paragraph before the end of page
The sentence: "This is done using the NTPv4 on-wire protocol, which
requites the crypto-NAK, as well as all responses, to be believed only
if the result of a previous packet sent by the host and not a replay, as
confirmed by the LBK and DUP status bits described above."
needs clarification. It does not look like a complete sentence and is
unclear.