C2S/S2C lifetime

Sun Feb 3 04:48:17 UTC 2019

On 2/2/19 9:09 PM, Gary E. Miller via devel wrote:
>> In the context of
>> attacks on C2S/S2C, if the client willingly shares C2S/S2C in
>> plaintext with someone else (other than the server), the client has
>> already compromised C2S/S2C by its own actions. There is nothing in
>> the protocol which does this.
> 
> Yup.  The protocol allows this class of attack.

Sure, a client could take the keys (C2S/S2C) it has in plaintext and
give them (C2S/S2C) away, and then its keys (C2S/S2C) are compromised.
It is impossible for any protocol to prevent the client from separately
choosing to give away its keys. If Firefox opens a socket to nsa.gov and
gives them your TLS session keys, that's not a flaw in TLS! Likewise, a
client giving away its own keys out of band is not a flaw in NTS.

>> The limit is on how many messages should be encrypted by a single key.
> 
> Yup.  Except there is NO limit.

The "limit" is how many messages per key is considered safe for a
specified algorithm by crypto experts. That is the "limit" we are trying
to stay under by verifying our assumptions and/or setting time-based or
count-based key rollover configuration options. For AES-GCM, we were
told that limit is 2^32. For AES-SIV (-CMAC), we were told that is 2^48.
You can verify that 2^48 in RFC 5297, page 15.

>> For C2S/S2C, the limit is applicable to a normally functioning client
>> (and server).
> 
> I'm not talking about normal.  I'm talking about enemy action.
> 
>> Even with the worst case assumptions of AES-GCM and minpoll 4, that
>> limit is 2,176 years. C2S/S2C are re-keyed at least on client
>> restart. I believe 2,176 years is "very conservative[]" relative to
>> client ntpd restarts. Do you disagree?
> 
> If I agree to your assumptions, then I agree to your conclusion.
> 
> Except, I do not agree with your assumptions.  Nothing enforces
> minpoll 4.  Nothing prevents cookie sharing.

Cookies are a client's C2S/S2C (and some other data) encrypted to key K.
Because they are encrypted, they are only readable by the server which
has key K. So sharing them in encrypted form (cookie form) does not by
itself give away C2S/S2C or K.

The client does have the important part of the cookie, the keys inside
the cookie (C2S/S2C). If it gives away its own keys, well, I covered
that above.

You said, "I'm not talking about normal. I'm talking about enemy
action." So the client is trying to attack something.

It's not attacking itself to get its own C2S/S2C, because it has its own
C2S/S2C in plaintext already.

The security of _another_ client's C2S/S2C, if the attacker can
eavesdrop on its client-server NTP communications to get the cookie
(which is the encrypted form of C2S/S2C), is protected by those cookies
being encrypted to key K.

There are two ways to attack the other client's C2S/S2C:

1) Attacking C2S/S2C here refers to disclosure of the other client's
C2S/S2C by way of the other, normal, victim client encrypting too many
NTP communications (to the server) to C2S, or the server encrypting too
many NTP communications (to that client) to S2C.

The number of communications that the other, normal, victim client sends
to the server and the server sends to the other, normal, victim client
is bounded by normal behavior. We're not going to be anywhere near even
the AES-GCM limit. So Daniel's/Hal's/my point is that we do not need
expiration for C2S/S2C, because it will naturally stop being used due to
client ntpd restarts many orders of magnitude sooner than is a risk for
the underlying encryption.

So the "enemy action" scenario is the second one:

2) Attacking K here refers to disclosure of K by way of the server
encrypting too many cookies to K.

So the malicious client is trying, possibly with coordinating machines,
to attack K because once it has K, it can decrypt other client's cookies
to get those other client's C2S/S2C. Once it has those other client's
C2S/S2C, it can do bad things. The easiest example is that it can then
impersonate the server and give the client bad time, which the client
believes is correct.

>> However, as above, maybe we want some crypto
>> diversity, just in case a future problem is found with AES-SIV.
> 
> Or, because the Proposed RFC insists on it.

For the cookie encryption, it does not require any particular algorithm
nor a choice of algorithms. The cookie format, which is what is
encrypted to key K with some algorithm, is entirely implementation
defined. If you disagree, please cite the appropriate section.

>> So
>> maybe we do allow AES-GCM too, and thus need to consider that case,
>> so we're at 2^32 messages.
> 
> Or less, a lot less.  Remember BEAST?
How much safety factor is built into that 2^32 recommendation? If it
already has "enough" safety factor, then no, it's not "a lot less". If
the safety factor is not already "enough", then yes, we need to reduce
it. What constitutes "enough" is obviously debatable, but we agree that
we should be conservative in that.

In the attacking C2S/S2C scenario, the current worst case (ntpcipher of
AES-GCM + a client doing maxpoll 4) is 2,137 years between ntpd client
restarts, which has plenty of safety factor for me. My servers get
reboots every month or two for some security patch or another. If I went
a whole year, then I might be considered reckless on that basis alone.
And yearly reboots is a 2^11 safety factor compared to 2,137 years
(AES-GCM + maxpoll 4) or a 2^27 safety factor on AES-SIV + maxpoll 4, or
a 2^33 safety factor on the default case of AES-SIV + maxpoll 10. And
that assumes the initial 2^32 for AES-GCM and 2^48 for AES-SIV have zero
safety factor already.

In the attacking K scenario, the worst case (cookiecipher of AES-GCM +
NIST levels of server traffic) _is_ a problem.

Note that the ciphers are different. The C2S/S2C attack scenario is
about the negotiated AEAD cipher, of which the server is only required
to support AES-SIV, but it may wish to support others for crypto
diversity. The K scenario is about the cipher used for cookies, which is
entirely up to the server and thus can be changed more easily (because
it does not involve coordination with an installed base of clients).

Note that the message counts are different. The C2S/S2C attack scenario
is about how many legitimate messages are generated for a single
C2S/S2C, which is maxpoll 4. This attack is against an unknown C2S/S2C
(because if it's known, it's not an attack), so it is for another
client's C2S/S2C. You can publicly share your cookies and your C2S/S2C
keys and it won't make a different in attacking someone else's C2S/S2C.
The K attack scenario is about how cookies are generated by the server
per K, including when it is under attack by multiple coordinating
clients requesting cookies.

>> If we assume the recommended rotation of daily,
> 
> Wrong again.  It is not a rotation, it is a ratchet!

As I stated, I'm assuming we, the implementation, choose random
generation of K instead of choosing to do ratcheting. I said we'd
address ratcheting separately.

>> So I conclude that using AES-GCM to protect K is a real problem at
>> NIST scale, even if they don't share K across servers, with a daily
>> rotation schedule (assuming a world where everyone implemented NTS).
> 
> Well, good.  Now extrapolate to other ciphers.

I did give both:

"If we assume the recommended rotation of daily, keeping one old K,
2^32/2/24/60/60 = 24,855 requests/sec per K with AES-GCM. In comparison,
1628906115 request/sec per K with AES-SIV."

This is a difference of 2^16, because AES-SIV's 2^48 - AES-GCM's 2^32 =
2^16.

>> Rotating more frequently is one possible solution. However, they
>> almost certainly need to keep a client's cookie valid for at least
>> 1024 seconds (17 hours), as that is a common polling window. So K
>> needs to be valid at least that long (i.e. rotate K every 9 hours
>> keeping one old K). Trying to support a maxpoll of 17 (36.4 hours) is
>> really pushing the boundaries of an AES-GCM protected K at NIST load,
>> even if K is per server, unless they deploy more servers (to get more
>> Ks) than they used in 2016.
> 
> Or, just expire the C2S/S2S a bit more frequently.

Again, this is about protecting K from disclosure due to encrypting too
many plaintexts with the same K. Changing what those plaintexts are
(rotating C2S/S2C) does not affect in any way how many plaintexts are
encrypted to a given K, and thus rotating C2S/S2C doesn't help at all in
the attacks against K.

> Until AES-SIV is broken.  Alternative solution, as James proposed, like
> all other good crypto programs I know: just expire the C2s/S2C after some
> reasonable time.

I believe the weakest AEAD algorithm being considered is AES-GCM. With
maxpoll 4, the client need only re-key every 2,137 years. The point is
that "some reasonable time" for expiration is 2,137 or 9 million years
depending on algorithm, the lower of which is still much longer than the
client ntpd is ever going to run.

>> If each K is randomly generated (let's address ratcheting separately),
> 
> Once again, flawed assumption.  Please reread section 6.  NOT randomly
> generated.

I'm saying we, the implementation, can make the decision to only
randomly generate K.

>> do you agree that the window for attack is however long K is valid,
>> which by the recommendation is two days?
> 
> Yeah, if assume what we are not going to do, then it works.

Okay, good, so we agree things are okay if we decide to randomly
generate K instead of ratchet it.

> My preference.  Except it opens up a new can of worms.  How does the
> NTPD server tell the NTS-KE what the new K is?

If the NTS-KE and NTP daemons are the same process, that's obviously
easy: a global variable.

If the daemons are separate processes, either shared memory, a local
socket, or a local file.

If the daemons are on separate hosts... a network socket, protected by
TLS, with an implementation-defined protocol. I'm not actually sure it
is necessary to support these being on separate hosts, but if it is,
that's how you do it.

Either ntpked or ntpd can be responsible for generating K.

-- 
Richard

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ntpsec.org/pipermail/devel/attachments/20190202/50c070a1/attachment.bin>