Subject: Re: [ntpwg] [ntp:hackers] Clarifications sought on v4 extensions

From: Danny Mayer <[email-masked]>
Date: Tue, 15 Jun 2010 07:58:04 -0400

Sorry about the delay. Responses inline.

Note that I am copying the ntp working group where these questions
belong rather than hackers.

On 5/6/2010 1:33 AM, Nelson B Bolyard wrote:
> After reading the recently expired draft-ietf-ntp-ntpv4-proto-13 and
> contrasting it with the current ntpd source code available from ntp.org,
> I'd like to request/suggest a number of clarifications to section 7.5
> "NTP Extension Field Format" on page 27 of that draft.
> 
> I believe it was the intent of the draft that the 16-bit length field
> in the first word of an extension would contain the number of octets in
> the extension following that first word, so that the total length of the
> extension would be the number specified in that field, plus 4.
> Can someone confirm that?  It would be good for the RFC to make that clear.
> 

The draft states:
"The Length field is a 16-bit unsigned integer which indicates the
length of the entire extension field in octets, including the Padding
field."

That means that it includes the field type field and the length field
which are the 4 bytes you are asking about. It specifically says "entire
extension field" which includes the field type and the length. Does that
help?

> Also, as presently specified, the length count in the header includes the
> number of pad bytes, so that the least significant two bits of the length
> field will always be zero.  This in turn means that they do not tell the
> recipient how many pad bytes were included.  Perhaps it would be better if
> the length field did NOT include the number of pad bytes (but the number of
> pad bytes was nonetheless sufficient to bring the total extension size to
> a multiple of 4 octets and no less than the minimum number, which I discuss
> below), so that the recipient could inexpensively tell if there were any
> pad bytes to be dropped from the extension.
> 

The reason for the length field is to tell you how large it is so that
if the recipient of the packet does not understand or want to use the
information in the extension field it can know how many bytes to jump
over to get to the next extension field (if any). Does this help? Note
that if you don't understand the extension then the rest doesn't matter
and if you do understand the extension then you know how to ignore the
padding.

I should also point out that the length field has been defined this way
for many years so it is not practical to change this even if we want to
and I'm not convinced by anything you've said that we should.

> The draft seems to acknowledge only MD5 and not SHA1 or any other hash,
> but the ntpd sources clearly implement both MD5 and SHA1 hashes, when
> built with the OpenSSL libcrypto library.
> 

I believe that SHA was a recent addition to the reference implementation
code but that does not affect the draft since it postdates the original
draft.

> The draft says "the minimum field length containing required fields is 4
> words (16 octets)" but does not explain the basis for that minimum
> requirement.  A comment in the ntpd source code strongly suggests that
> the intent was that the minimum extension length (including the 1 word
> extension header) would be equal to the maximum length MAC (including
> the one-word key identifier that acts as the MAC header).  Put another way,
> the minimum extension contents (excluding the 1 word extension header)
> must be no shorter than the maximum MAC hash size.  The comment says
> that if the length of the packet exceeds the length of the minimum NTP
> packet (12 words) by more than the maximum MAC size (including key
> identifier) this indicates that extensions are present.
> 
> Assuming that the only MAC hash is MD5, whose hash size is 16 bytes, then
> that design goal is met by requiring extension contents to be at least 4
> words, but if SHA1 hashes are also allowed, then the minimum extension
> contents (without header) must be 5 words, and with header must be 6.  This
> is consistent with the comment in the present ntpd implementation, which
> states that the test for the presence of extensions is that the packet size
> exceeds the minimum by MORE than 6 words.
> 

The MAC is not in fact a part of any extension field. The MAC protects
the entire packet, all extensions included.

This draft actually conflicts with the autokey draft which states in
Section 10:
"While the minimum field length is 8 octets, a maximum field length
remains to be established."
so while you are partly right here in that the minimum length should be
8 octets. The field type and length fields take up 4 octets so any
extension field with padding needs to be at least 4 octets since it
needs to be padded to a 4 octet boundary, none of this is related to the
MAC.

> So I ask that the next draft of the RFC be clarified about these things:
> - whether the extension's length field includes the 4 octets in the first
> word of the extension, or only the octets in words following the first.

See above.

> - whether the extension's length field really should include the number of
> pad bytes, or not.

See above.

> - whether other hashes besides MD5 are allowed.

The main issue with not using MD5 is how do you indicate the type of the
MAC. I seem to recall that the only way that the reference
implementation differentiates between MD5 and SHA1 is by the size of the
MAC and that's really not a good signaling mechanism for obvious
reasons. That issue would have to be addressed in an update to the
draft. I don't know how to solve that one.

> - the minimum number of words required in each extension (inclusive of
> the header word).

It probably should be 8 octets.

Danny
> Regards,
> /Nelson Bolyard

_______________________________________________
ntpwg mailing list
[email-masked]
http://lists.ntp.org/listinfo/ntpwg

---

From: "David L. Mills" <[email-masked]>
Date: Tue, 15 Jun 2010 17:00:22 +0100

Danny,

I''ve answered this for Nelson and the editors some time back. I wrote 
the original draft of the ID in the summer of 2005; it's been five years 
in evolution since then. The original version supported DES-CBC where 
the MAC (3 words) and MD5 (5 words) and later SHA (6 words). This means 
the minimum extension field would have to be 4 words in order to 
distinguish from DES. Subsequently, it makes no sense to support DES, as 
not only is this considered obsolete but brings with it the export 
control nonsense. NTP versions 3 and later do not support DES anyway.

So, if only 5- and 6-word MACs are supported, the minimum extension 
field length is 2 words, and that is specified for both Autokey and 
NTPv4. I haven't checked the draft, but the editors have been advised of 
the clarification.

Dave