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

[Danny Mayer <[e-mail]>]

On 6/21/2016 10:51 AM, Daniel Franke wrote:
> 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.

Yes, the intention is to relegate the old MAC to existing usage and only
use EF MAC for future use. We are also planning to move to GMAC for
hashing algorithms.

Danny


_______________________________________________
ntpwg mailing list
[e-mail]
http://lists.ntp.org/listinfo/ntpwg