Re: [Ntp] Benjamin Kaduk's Discuss on draft-ietf-ntp-mode-6-cmds-09: (with DISCUSS and COMMENT)

[Benjamin Kaduk <[e-mail]>]

On Thu, Aug 27, 2020 at 02:00:34AM -0700, Hal Murray wrote:
> 
> Benjamin Kaduk  said:
> > The considerations of BCP 201 with respect to algorithm agility appear to be
> > quite relevant, with the 96-bit authenticator format locking us into at best
> > 64 bits of MAC, which is fairly weak for Internet use, and 32 bits of key
> > identifier.  This presents its own problems, as 32 bits is too small for a
> > value that is unilaterally assigned by many/all participants and expected to
> > be globally unique, but is rather large for a key identifier space that is
> > centrally managed for use within a single administrative domain.  (The
> > currently specified DES-CBC checksum from RFC 1305 is, of course, considered
> > insecure at this point, as with all things single-DES.) 
> 
> We are down in the weeds, but ...
> 
> The 32 bit Key-ID is not globally unique.  With existing code, it's per 
> server.  There is no reason that it couldn't be per client-server.  (That is 
> unlikely to work if the client is using DHCP.)
> 
> An additional complication is that Autokey (RFC 5906) uses the top 16 bits so that leaves only 16 bits for manual assignment.

Thanks for the extra background on the Key-ID.

> ----------
> 
> Thanks for pointing out the 64 bit MAC.  I've been working in this area for a long time and don't remember seeing any 8 byte MACs.  It would be an interesting archeology project to figure out when support for MD5 (16 bytes) and SHA-1 (20 bytes) was added to the code.
> 
> RFC 8573 added AES-128 CMACs.
> 
> RFC 7822 describes the results of a lot of discussion about how to make old MACs coexist with extension fields.   My memory is that the discussion focused on 16 and 20 byte MACs as used by MD5 and SHA-1.  I think the wording in the RFC supports 20 or shorter.  I don't think any code supports 8 byte MACs.

I would be quite happy if the spec here does not match existing
deployments!  But, we should make sure we are documenting what is actually
used, in that case.

> In practice, in addition to agreeing on the Key and Key-ID, you also have to agree on the algorithm.  There is nothing in the packet that tells you which algorithm to use.  A while ago, you could make a good guess between MD5 and SHA-1 based on the length.  But now, AES-128 is also 16 bytes.  

General crypto best practice is to only use a given key for a single usage
and with a single algorithm, so my expectation is that the algorithm would
be assigned/negotiated at the same time that the key and key-ID are.

-Ben