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

From: Miroslav Lichvar <[email-masked]>
Date: Thu, 1 Mar 2018 09:44:14 +0100

On Wed, Feb 28, 2018 at 11:06:36PM -0800, Hal Murray wrote:
> I'm interested in the simple case of shared/symmetric key authentication.

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

As I understand it, the main advantage is better performance (when
implemented properly). For instance, on a server configured with a
SHA256 key I'm observing a 40% drop in performance when compared to no
authentication. With AES-CMAC the impact should be much smaller. I've
not tried it yet. However, I'm not sure how much this really matters
as (public) servers typically don't handle a large number of packets
authenticated with symmetric keys.

> 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?

The trouble is with parsing the packets. The strict rules for lengths
of extension fields and MACs are needed to prevent ambiguity.
Otherwise, a long MAC could be incorrectly interpreted as an extension
field, or a short extension field could be interpreted as a MAC.

This was a frequent topic on this list, so I'd suggest to go through
the archives if you are interested in more details.

Please note that latest versions of ntp truncate long digests in MACs
to 160 bits, so the authentication should work with any hash function
supported by OpenSSL.

-- 
Miroslav Lichvar

---

From: Hal Murray <[email-masked]>
Date: Thu, 01 Mar 2018 14:36:45 -0800

Thanks.

> implemented properly). For instance, on a server configured with a SHA256
> key I'm observing a 40% drop in performance when compared to no
> authentication. With AES-CMAC the impact should be much smaller. I've not
> tried it yet.

Intel has hardware support for AES on some chips - AES-NI.  On Linux boxes, 
it will show up as an "aes" in the flags in /proc/cpuinfo
  grep aes /proc/cpuinfo

How are you measuring performance?

My measurements are that the CMAC part is 696 ns in software and 499 ns with 
AES-NI.  That was on a 2+ GHz cloud server.  (None of my handy boxes have 
AES-NI.)  SHA512 was 594 with 16 or 20 byte key and 624/614 with 24/32 byte 
keys.  That's just the crypto part to compute the digest.  X2 for transmit 
and receive and round up for getting there and deciding which key to use and 
copy or compare and such.

On a PI-2B, AES-CMAC is 10242 ns.  SHA512 digest is 13500 ns.

-- 
These are my opinions.  I hate spam.

---

From: Matthew Van Gundy <[email-masked]>
Date: Thu, 1 Mar 2018 18:40:45 -0500

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

The keyed-hash construction that NTP uses is not a secure message
authentication code, it is vulnerable to the classic length extension
attack [1] when used with common hash functions, such as MD5, SHA-1,
and the SHA-2 family of hash functions.  This allows an attacker to
append additional forged NTPv4 extension fields on to an authenticated
NTPv4 packet.  draft-ietf-ntp-mac-03 refers to this attack through its
reference to the BCK paper in section 2 [2] even though it does not
explicitly call out length extension attacks in the body of the draft.

In current usage, this rarely poses a problem.  In the NTP reference
implementation extension fields are only used by Autokey.  If you have
Autokey disabled, it does not give an attacker any additional power.
However, if NTPv4 extension fields catch on for uses other than
Autokey, this will become problematic.

AES-CMAC is a secure message authentication code and, therefore, is
not vulnerable to this kind of attack.

[1] https://en.wikipedia.org/wiki/Length_extension_attack
[2] https://tools.ietf.org/html/draft-ietf-ntp-mac-03#section-2

Cheers,
Matt

--
Matthew Van Gundy, Technical Leader
Advanced Security Initiatives Group
Cisco Systems, Inc.

---

From: Miroslav Lichvar <[email-masked]>
Date: Fri, 2 Mar 2018 10:11:45 +0100

On Thu, Mar 01, 2018 at 06:40:45PM -0500, Matthew Van Gundy wrote:
> NTPv4 packet.

Does this actually apply to NTPv4? Do you have any examples how could
an attacker append a valid extension field to an NTPv4 packet?

My understanding is that the NTPv4 packet format (with or without
RFC7822) prevents the length-extension attack as extension fields
cannot have a length of zero, which would come from the padding
(always starting with 0x80000000). Even if the length field could be
zero, there is no EF type 0x8000 assigned yet and it could be avoided
in future in case people are for some reason still using the old MAC.

-- 
Miroslav Lichvar

---

From: Miroslav Lichvar <[email-masked]>
Date: Fri, 2 Mar 2018 10:33:16 +0100

> How are you measuring performance?

I was measuring the maximum rate of requests the NTP server could
handle, so that includes all overhead of receiving and sending
packets in the OS, etc.

> keys.  That's just the crypto part to compute the digest.

Does that include the time spent in allocation of the CMAC context and
the initialization with the key? I think an optimized implementation
could avoid both. (With the old MAC the key has to be hashed with each
message).

Anyway, older versions of the ntp-mac draft included some measurements
of latency and throughput, which showed that with AES-NI the CMAC is
significantly faster than MD5, which should be significantly faster
than SHA512.

https://www.ietf.org/archive/id/draft-aanchal4-ntp-mac-03.txt

I think the only downside of AES-CMAC is that it is not widely
supported in crypto libraries yet. OpenSSL seems to be an exception.

-- 
Miroslav Lichvar

---

From: Matthew Van Gundy <[email-masked]>
Date: Fri, 2 Mar 2018 10:08:37 -0500

Hi Miroslav,

> in future in case people are for some reason still using the old MAC.

I was speaking in general terms. I have not actually proved out an
attack against an NTPv4 implementation.  I believe you are correct:
since most hash functions in common use pad the last block with a
binary string beginning with 0x80000000 or 0x00000000, an NTPv4
implementation would parse a length extended packet as an extension of
length zero, and would probably discard it (or fail to process
additional extensions in a meaningful way).

However, there is no requirement that hash functions pad the last
block with any specific value.  Though it may be unlikely, this is a
brittle assumption that could be invalidated by future hash functions.
Using secure message authentication codes such as CMAC or HMAC avoids
this potential failure case.

Cheers,
Matt

---

From: Hal Murray <[email-masked]>
Date: Tue, 06 Mar 2018 16:34:06 -0800

[email-masked] said:
> Does that include the time spent in allocation of the CMAC context and the
> initialization with the key? I think an optimized implementation could avoid
> both. (With the old MAC the key has to be hashed with each message). 

I pre allocated the context but I didn't preload the key.  I don't have any 
man pages for the CMAC routines. ??  I see CMAC_CTX_copy.  I assume  that's 
what you are referring to.  I'll add it to my list.  Thanks for the 
suggestion.

Looks like there is a EVP_MD_CTX_copy.  I assume it can be used in the same 
way for digests.

> Anyway, older versions of the ntp-mac draft included some measurements of
> latency and throughput, which showed that with AES-NI the CMAC is
> significantly faster than MD5, which should be significantly faster than
> SHA512.

Thanks.

(The link actually goes to a file that calls itself 
draft-aanchal4-ntp-mac-02, Oct 2016.  It does have lots of performance data.)