Re: [ntpwg] Parsing NTP packets regarding MACs and EXTs.

[Daniel Franke <[e-mail]>]

On 6/21/16, Danny Mayer <[e-mail]> wrote:
> Yes. The reference code supports the creation of better hashes than MD5
> and SHA-1, since OpenSSL supports it, but the parsing code does not and
> that's what needs to get fixed. This is not a NTP WG issue, it's a
> problem with the reference implementation that needs to get fixed. I do
> note that RFC5905 only references MD5 and that IS a WG problem.

A bigger problem than MD5 is the fact that NTP's  "HMAC" isn't HMAC;
it's the H(K||V) construction vulnerable to length-extension attacks.

However, supporting better hash functions shouldn't require any
changes to parsing. The length of a MAC tag doesn't have to be the
same as the digest size of the hash function you're using. It's
perfectly safe, e.g., to truncate HMAC-SHA256 to 128 bits.

I oppose putting the legacy MAC field to any new uses or allowing it
take on anything other than its current size. Any new crypto should be
done in extension fields. The parsing rules should be as follows:

If the packet is 48 bytes, it has no extensions and no MAC.
If the packet is between 49 and 67 bytes inclusive, it's malformed; discard it.
If the packet is 68 bytes, it has a legacy MAC and no extensions.
If the packet is more than 68 bytes, the last 20 bytes are the keyid
and MAC, the first 48 bytes are the standard fields, and everything in
between is extension fields. If the keyid field is 0, then the MAC
field is ignored, and these last 20 bytes are basically just filler to
make the packet parse correctly.

At such time as we publish a standard for NTPv5, we can get rid of the
legacy MAC fields and move their functionality into extension fields,
so that the 20 bytes of wasted filler is no longer necessary.
_______________________________________________
ntpwg mailing list
[e-mail]
http://lists.ntp.org/listinfo/ntpwg