Subject: [ntpwg] Different security mechanisms (NTS, Autokey, Symmetric Security) and key exchange techniques

From: [email-masked]
Date: Mon, 14 Mar 2016 11:44:57 +0100

(Was "Re: [ntpwg] Fwd: Early Allocations for NTS drafts from the IETF NTP 
Working Group"
Re-labeled because the discussion has largely moved away from the early 
allocations)

(Miroslav:)
> > I'm not sure I follow here. If you have a symmetric key or another
> > authentication mechanism enabled, why would you use NTS?
> 
> How do you protect the first few packets otherwise?
> 
> I'm offering a mechanism that would permit symmetric key for the first
> few packets.  At that point one can shift to NTS.

I cannot stress enough that while we have nothing against continuing the 
use of an existing symmetric key security association, I view it as a 
severe mistake to set one of those up *just* to protect the first 3 
exchanges of an NTS-secured association!
Harlan, for associations where the participants have *not* initially set 
up a symmetric key security association and want to start using NTS, what 
would be your proposed plan?

(Kristof:)
> > If there is a way to communicate these things independently from the
> > fact that the extension field is NTS-related, then that is another
> > discussion.  But from what I understand, you are proposing values that
> > explicitly identify more than multiple different identifiers for
> > NTS-related extension fields. In which case I agree with Dieter: I do
> > not see a need to differentiate at that point (where a participant has
> > seen, but not begun to process, an extension field).
> 
> See RFC5906 for the description of the Field Types for autokey.  In
> these. the 2nd nibble describes the packet content.  NTS does not want
> to make this information public, and that's fine.
> 
> But that does not obviate the black-box need to know if any given
> extension field is expecting additional MAC protection, or if any given
> extension field provides MAC protection over the preceding packet
> contents.

I still fail to see a concrete reasoning for this being a need.
Can you name an example where a client would benefit from modifying their 
behavior as a result from having information of the kind "I contain a 
MAC"/"I require a MAC later" availabe?

(Kristof:)
> > Any kind of MAC protection requires that the participants perform some 

> > kind of key exchange beforehand. In the case of NTS, this exchange is 
> > performed over NTP packets. 
> 
> Yes, and until that time there is *no* MAC protection available.
> If that doesn't matter for you, that's your local policy choice.
> If it matters to somebody else, that's their local policy choice.
> You don't get to dictate their policy choices.
> I'm talking about mechanism, which gives people the ability to make
> local policy choices.

I strongly object to writing this off as mere policy choices. If there 
were a way to have security from the first packet on (without it causing 
costs so huge that they negate the benefits of using NTS), we would gladly 
enable that.

> [...]
> I'm telling you it won't work for others who have a different use-case,
> and I'm going to do my best to provide a robust mechanism that will
> permit folks to make local policy choices that meet their needs.

That is a valiant effort, all I am arguing is that your mechanism is just 
not as universally available as you describe it.

(Kristof:)
> > The alternative would be to do it out-of-protocol, but
> > overall: does this save any time or effort?
> 
> That's a local policy choice.

The answer to the question whether an out-of-protocol key exchange saves 
time or effort is not a policy choice. There are objective criteria and 
calculations involved. If anything, the question whether a participant is 
willing to accept any additional time or effort necessary is up to policy 
choices.

> What I describe permits this *now* with the existing symmetric key 
mechanism.

Like every other MAC-based security mechanism, the symmetric key approach 
needs to exchange a key. Overall, it therefore provides just as little 
instant availability as NTS, or Autokey (arguably the availability of the 
symmetric key approach is even less instant than that of its 
alternatives).

(Kristof:)
> > Instead of the time that passes between the first NTP packet sent and
> > the first authenticated timestamp available to the client, consider
> > the time that passes between the decision to obtain authenticated time
> > and the first authenticated timestamp being available. This will in
> > fact take more time and effort if the client needs to do some
> > out-of-protocol key exchange first (as in the case of e.g. symmetric
> > key MAC protection).
> 
> If an ntp.keys file exists already then it takes no time at all to offer
> traditional MAC protection, as good or bad as that is. 

Isn't this a really big IF?

(Kristof:)
> > That's a point I've been meaning to bring up, but somehow didn't get 
around to: 
> > this "issue" is not new, or unique to NTS.
> > One could even have the association done in fewer excahnges, but at a 
> > significant security cost (and I would therefore absolutley not 
recommend it): 1 
> > exchange could be saved if we cut algorithm negotiation, another 1 
echange could 
> > be cut if we disabled the defense mechanism against crypto DoS.
> 
> That doesn't seem to be a useful solution.
> 
> But as I mentioned earlier, autokey packets are already *always*
> MAC-protected.  That's all we need here.

No. The early autokey packets do carry a MAC, but such MAC does not in 
fact protect the packet, as Dieter explained (see below).

(Dieter:)
> > Autokey adds an extension field to each packet only because of the
> > requirement that there has to be a MAC field after an extension
> > field. But the MAC during the initial phase of autokey, in which the
> > challenge-response scheme and then the cookie exchange runs, are
> > without any information, because the underlying cookie, which is the
> > base for the =A0autokeys, which are used to calculate the MAC has the
> > public value zero. You can read this in RFC5906, Page 10.
> 
> I'm not digging in to the reasoning underneath.  I'm just saying the
> reality is that until *very* recently, the presence of an extension
> field REQUIRED a MAC.
> 
> That the initial algorithm for autokey is NULL is, I believe, a
> shortcoming.

Arguably maybe, but the whole point here is that it is also a necessity 
(i.e. it is not possible to work around it without serious detriments).

> It could be easily fixed, if anybody cared enough to fix it.

The above statement is absolutely not true.
If you have no data exchanged initially (which is the only solid basis to 
work from for any security specification), then you need to exchange key 
data before you can start using MAC-based security (or most other 
security, for that matter). Again, this holds true for NTS, for Autokey, 
and for the symmetric key approach.

-------------
Best regards,
Kristof

_______________________________________________
ntpwg mailing list
[email-masked]
http://lists.ntp.org/listinfo/ntpwg

---

From: Harlan Stenn <[email-masked]>
Date: Tue, 15 Mar 2016 00:47:12 +0000

[email-masked] writes:
> Dies ist eine mehrteilige Nachricht im MIME-Format.
> --===============1313932938896456893==
> Content-Type: multipart/alternative; boundary="=_alternative 003B0C5CC1257F76
> _="
> 
> (Miroslav:)
> I cannot stress enough that while we have nothing against continuing
> the use of an existing symmetric key security association, I view it
> as a severe mistake to set one of those up *just* to protect the first
> 3 exchanges of an NTS-secured association!

Please say more about how this is a "severe mistake".

Talking only about the iburst case for now, are you saying *no*
protection is better than *some* protection during this inital volley?

> would be your proposed plan?

If they want these initial packets protected, they must set up a
framework for that effort.  Right now the easiest thing to set up is
symmetric key.

If they dont want these initial packets protected then it doesn't
matter.

I still haven't heard an answer to my question about "how long does it
take to do whatever work needs to be done upon receipt of one of these
initial packets.  Specifically, how much time is spent processing each
of the first 6 packets?  I'm curious how many of these steps are
expected to take 1.75 seconds or longer.

> MAC"/"I require a MAC later" available?

I'm about to publish a number of proposals.

Old clients will do whatever old clients will do - they don't know about
any of these things so they will gain nothing, and if those systems are
designed to drop packets with unknown extension fields they will lose.
But these old systems will not be asking for NTS connections, so there
is less likely to be a chance that "I'm dropping a packet because it has
an unknown extension field" will happen.

New clients will have this information, and they may use it in the case
where they get an unknown extension field.  If they understand all the
extensions except "MAC in and Extension Field" but they see the EF they
don't understand is "I contain a MAC and a subsquent MAC is OPTIONAL for
me" then the client can make a "better" choice about how to proceed.

It's a *help*.  That's all.

Why are you so opposed to providing this help?

> costs so huge that they negate the benefits of using NTS), we would gladly 

Symmetric key MAC protection is a way to have security from the first
packet without incurring any new costs. 

I'm not saying it MUST be done, my proposal says doing this is
OPTIONAL.  But if you as a server send a Field Type of 0x0004 that means
"NTS, MAC SHOULD (or MAC MUST)", and if you send 0x2004 that means "NTS,
MAC MAY".  Once the NTS exchange has progressed to the point where they
include a MAC, the would use a Field Tupe of 0x3004, "NTS, MAC Included,
MAC MAY follow".

> not as universally available as you describe it.

None of this is available now.  I'm not sure what you mean.

> willing to accept any additional time or effort necessary is up to policy 

How is the evaluation of objective criteria and calculations *not* a
local policy decision?  It's certainly not a mechanism decision.

But still we arrive at the same point, where we seem to agree: is one
side willing to put forth the effort to allow the use of a symmetric key
to protect the initial packet.

If somebody wants this protection but via some other mechanism, they can
do that too, if they prefer.

> symmetric key approach is even less instant than that of its 

Once symmetric keys are distributed there is *no* startup time required
to use them.

You are taking the position that at least 3 poll exchanges is just as
good as having it immediately.  That's a local policy evaluation.

I promise you others do not hold that belief, they want that initial
time sync to be faster, even for cold-start.

> Isn't this a really big IF?

Not at all.  If one wants this, one propagates an ntp.keys file.

If one doesn't want this protection, one doesn't bother.

Distributing something in a file within an organization is a well-solved
problem, that is in wide deployment.

Doing it between organizations was solved long ago, and requires minimum
to little effort.  Not counting political issues, of course.

>>> around to: this "issue" is not new, or unique to NTS.  One could
>>> even have the association done in fewer excahnges, but at a
>>> recommend it): 1 exchange could be saved if we cut algorithm
>>> negotiation, another 1 exchange could be cut if we disabled the
>>> defense mechanism against crypto DoS.
>> 

Yes.  And this is an easily solvable shortcoming, if anybody wanted to
fix it.

> (i.e. it is not possible to work around it without serious detriments).

I'm not sure what you mean.  It would be trivial to use the symmetric
key until autokey was up and running, then switch to that session key.

> The above statement is absolutely not true.  If you have no data
> exchanged initially (which is the only solid basis to work from for
> any security specification), then you need to exchange key data before
> you can start using MAC-based security (or most other security, for
> that matter). Again, this holds true for NTS, for Autokey, and for the
> symmetric key approach.

I disagree completely.  Symmemtrc key works just fine for this, to the
extent one is willing to use symmetric keys.

H

---

From: Hal Murray <[email-masked]>
Date: Tue, 15 Mar 2016 00:47:49 -0700

[email-masked] said:
> Specifically, how much time is spent processing each of the first 6 packets?
>  I'm curious how many of these steps are expected to take 1.75 seconds or
> longer. 

Where did the magic number of 1.75 come from?

There is a big difference between "expected" for the normal case and 
something like "happens often enough" so we shouldn't rule it out.

Are you asking about CPU time for client or server to process a packet or are 
you including network transit time?  In either case, it's not hard to come up 
with nasty cases that take a long time.

Bufferbloat can easily get over 2 seconds.  My DSL line is close to 4.

I leave it to your imagination as to how a CPU can take that long.  My straw 
man would be a busy system without enough memory so it's swapping.  Logging 
to a stuck NFS server is another good choice.

-- 
These are my opinions.  I hate spam.

---

From: [email-masked]
Date: Tue, 15 Mar 2016 17:31:37 +0100

>Please say more about how this is a "severe mistake".

Scalability:

NTS is designed to scale nicely with large numbers of participants, especially in the area of necessary preparations. The symmetric key approach is not.

Let's look at a case where a larger number of participants (say 5000) are setting up a new network, and for some reason they require secure time synchronization. Let's take a look at the preparations (before any secured NTP communication is started) for two scenarios, the first being them using NTS, the second being them using the symmetric key approach. We assume that it is necessary to perform all preparations so that every participant can perform secured NTP communication with every other participant (the situation which you seem to assume as given when you describe how the symmetric key approach can be used at any time to secure those NTS messages which don't offer MAC protection by themselves).

NTS:

- Each participant needs to have one secure exchange with one trust anchor, where they obtain up to two certificates (one for each role, client and server) with the associated public/private key pairs. This means that overall, 5000 secured exchanges need to happen.

- Each participant needs to memorize its own certificates and keys (1 overall set of key data) and have them available.

Now any of those participants can have NTS-secured NTP communication with any other of those participants.

This comes at the cost of having the three initial exchanges we've been talking about for a long time now (where the NTP header is not MAC-protected by NTS, and during which the actual key data is exchanged). The benefit is that these initial exchanges will only be performed on demand (if and when two participants actually set up an association).

Symmetric Key Approach:

- Each participant needs to exchange a symmetric key with each of the other participants. This needs to happen over a secured channel. For the randomly chosen number of 5000 participants, that means that roughly 12.5 million secured exchanges need to happen.

- Each participant needs to memorize the key data for each of the potential associations it could have. That means roughly 5000 sets of key data per participant.

Only with these preparations is every participant ready to instantly perform symmetric-key secured NTP communication with any other participant.

In a general situation with n participants, the numbers scale as follows:

For NTS, the number of secured exchanges performed before any secured NTP communication can happen scales proportionally to n. For the symmetric key approach, it scales proportionally to n^2.

For NTS, the number of key data sets that need to be memorized per participant in order to enable secured NTP communication with all potential partners scales proportionally to 1 (i.e. it is a constant). For the symmetric key approach, it scales proportionally to n.

As you can see, this constitutes a huge advantage of NTS over the symmetric key approach, as far as necessary preparation effort goes.

For low numbers of participants, this advantage of NTS over the symmetric key approach can be ignored. For high numbers of participants, it really shouldn't.

Requiring every NTS association to also require a symmetric-key secured association negates this advantage of NTS completely (because in that case, all preparations necessary for symmetric key approach would be necessary for NTS as well).

Just recommending it as a general rule still negates the advantage to a degree, which is dependent on the number of people who adhere to the recommendation. I am therefore in favor of not giving said recommendation at all.

---------------

Best regards,

Kristof

P.S.: Of course, the discussion above is applicable to most discussions of the type "asymmetric keys vs. symmetric keys". In particular, Autokey for example has about the same scaling properties as NTS.

---

From: Harlan Stenn <[email-masked]>
Date: Tue, 15 Mar 2016 20:59:11 +0000

> Where did the magic number of 1.75 come from?

It's less than 2, and leaves some room before it becomes 2.

iburst packets are sent at 2 second intervals.

H
--

---

From: Harlan Stenn <[email-masked]>
Date: Tue, 15 Mar 2016 19:52:25 -0700

Hi Kristof,

On 3/15/16 9:31 AM, [email-masked] wrote:
> NTS is designed to scale nicely with large numbers of participants, especially 
> in the area of necessary preparations. The symmetric key approach is not.
> Let's look at a case where a larger number of participants(say 5000) are setting 
> up a new network, and for some reason they require secure time synchronization. 
> Let's take a look at the preparations (before any secured NTP communication is 
> started) for two scenarios, the first being them using NTS, the second being 
> them using the symmetric key approach. We assume that it is necessary to perform 
> all preparations so that every participant can perform secured NTP communication 
> with every other participant (the situation which you seem to assume as given 
> when you describe how the symmetric key approach can be used at any time to 
> secure those NTS messages which don't offer MAC protection by themselves).
> 
> 
> NTS:
> - Each participant needs to have one secure exchange with one trust anchor, 
> where they obtain up to two certificates (one for each role, client and server) 
> with the associated public/private key pairs. This means that overall, 5000 
> secured exchanges need to happen.
> - Each participant needs to memorize its own certificates and keys (1 overall 
> set of key data) and have them available.
> 
> This comes at the cost of having the three initial exchanges we've been talking 
> about for a long time now (where the NTP header is not MAC-protected by NTS, and 
> during which the actual key data is exchanged). The benefit is that these 
> initial exchanges will only be performed on demand (if and when two participants 
> actually set up an association).

Yes, and that's at the end of three NTS exchanges.  If the communication
with the trust anchor and the subsequent validation/setup work almost
certainly will not happen quickly when B receives the 3rd NTS packet
(the beginning of exchange #2) from A, so it will quickly reply to the
time request and process the NTS validation stuff separately.  If that
takes more than 2 seconds (the time until A sends its next iburst
packet) then NTS packet #4 will be sent as soon as it's practical.
Likewise, if A is still sending iburst exchanges when it receives NTS
packet #4, if that processing does not complete before it's time for A
to send the next iburst exchange 2 seconds' later, NTS exchange #5 will
be delayed until the next time A sends a packet to B.

This is compounded by the fact that the initial time sync is of CRITICAL
importance in many situations.  It doesn't do much good to quickly set
the time incorrectly.  Quickly setting incorrect time causes HARM.

> Symmetric Key Approach:
> - Each participant needs to exchange a symmetric key with each of the other 
> participants. This needs to happen over a secured channel. For the randomly 
> chosen number of 5000 participants, that means that roughly 12.5 million secured 
> exchanges need to happen.
> - Each participant needs to memorize the key data for each of the potential 
> associations it could have. That means roughly 5000 sets of key data per 
> participant.
> 
> Only with these preparations is every participant ready to instantly perform 
> symmetric-key secured NTP communication with any other participant.

I'm not buying that scenario.  But even if it is a valid case, it's one
where using symmetric keys is not useful.  That in no way means
symmetric keys are not useful in other scenarios.

In the case you describe, it's probably better to use PHK's https scheme
and get the time confidently known to within a few seconds and use that
time as a "sanity check".

Or you decide to not worry about the first few packets and you delay
getting trustable time until after you've finished the 3 NTS exchanges.

There are still other deployment mechanisms that can get a symmetric key
securely transmitted to a client.  It's no worse than opening an https
session and doing a short exchange of data, is it?

This method would work well even for a National Time Lab, where the
clients are all different.

For an enterprise setup, there is almost certainly some other already
existing way to deploy configuration files to clients.  This would add a
small incremental cost to that process.

Finally, the symmetric key space will hold 65k unique entries.
Supporting 5000 clients is under 10% of that space.

If one needs "lots more" keys than that, I submit that a business case
has been made and approved, and I'm highly doubt that one would need
more than 65k keys per IP.  I know how to implement this easily, for
example.

> For NTS, the number of secured exchanges performed before any secured NTP 
> communication can happen scales proportionally to n. For the symmetric key 
> approach, it scales proportionally to n^2.

I'll take you at your word.  In the situation you describe, symmetric
keys would not have been useful before, and they are still not useful.
But you are describing a *new* use-case, and I'm not talking about that one.

You are saying that you do not want to allow the use-case I am
describing and trying to satisfy.

> For NTS, the number of key data sets that need to be memorized per participant 
> in order to enable secured NTP communication with all potential partners scales 
> proportionally to 1 (i.e. it is a constant). For the symmetric key approach, it 
> scales proportionally to n.
> As you can see, this constitutes a huge advantage of NTS over the symmetric key 
> approach, as far as necessary preparation effort goes.
> 
> 
> For low numbers of participants, this advantage of NTS over the symmetric key 
> approach can be ignored. For high numbers of participants, it really shouldn't.
> Requiring every NTS association to also require a symmetric-key secured 
> association negates this advantage of NTS completely (because in that case, all 
> preparations necessary for symmetric key approach would be necessary for NTS as 
> well).
> Just recommending it as a general rule still negates the advantage to a degree, 
> which is dependent on the number of people who adhere to the recommendation. I 
> am therefore in favor of not giving said recommendation at all.

You seem to be ignoring the issue of "Is it important that the initial
volley have protected packet timestamps?"

If the answer is "no", then my description about using symmetric keys
doesn't matter.

Another question that must be asked is "how soon must the local time be
synchronized to a trusted source?"

If the answer is "No rush" then, again, there's no need to protect the
initial volley.

If the answers include:

- trusted time is important
- setting the clock quickly is important

then what do you suggest?

> ---------------
> Best regards,
> Kristof
> 
> 
> P.S.: Of course, the discussion above is applicable to most discussions of the 
> type "asymmetric keys vs. symmetric keys". In particular, Autokey for example 
> has about the same scaling properties as NTS.

Yes.

-- 
Harlan Stenn <[email-masked]>
http://networktimefoundation.org - be a member!