Subject: [Ntp] draft-ietf-ntp-mac, extensions

From: Hal Murray <[email-masked]>
Date: Wed, 28 Feb 2018 23:06:36 -0800

I'm interested in the simple case of shared/symmetric key authentication.

RFC 5905 discusses MD5 but doesn't mention SHA1.

Recent code supports both.  Or actually any digest from OpenSSL with a digest 
length of 16 or 20 bytes.  The code looks like:
        EVP_DigestInit(&ctx, EVP_get_digestbynid(type));
        EVP_DigestUpdate(&ctx, key, cache_secretsize);
        EVP_DigestUpdate(&ctx, (u_char *)pkt, length);
        EVP_DigestFinal(&ctx, digest, &len);
        (copy or compare)

That code works with any key length and any digest length.

Why is AES-CMAC more interesting than one of the digests supported by OpenSSL?

The current code and extension RFCs and proposals only supports digest 
lengths of 16 and 20 bytes.  I was expecting an extension code for shared 
keys so we could handle any length, but I don't see one on the IANA list.  Is 
anybody else interested in that case?

RFC 7822 (NTP Extension Fields) grandfathers in old MACs with MAC lengths of 
24 or less.  There is a 4 byte keyID, so the digest length is 20 bytes or 
less.  The current code works with MD5 (16) and SHA1 (20).  RIPEMD160 also 
has a 20 byte digest.

Section 7.5.1.1 and   7.5.1.2 discuss the case of mixed extension fields and 
bare MACs.  Is there a reason to allow that case as compared to put the MAC 
into the last extension?  (Is it leftover Autokey?  Does anybody use 
Autokey?)  The idea I'm fishing for is that if there are any extensions, then 
the rest of the packet is all covered cleanly by extensions and maybe the 
last extension is a MAC.  Does what I want just work out if the last 
extension is a MAC?

PS: RFC 7822 says:
      While the minimum field length containing required fields is
      four words (16 octets) ...
Why?  What's wrong with a 4 byte extension?  (The info would be in the type.) 
 That's an extreme case, but 8 and 12 byte extensions seem reasonable.

-- 
These are my opinions.  I hate spam.