[ntpwg] WG: Some clarification on NTS topics in the context of overall MAC protection (Was: Re: The next step of draft-ietf-ntp-checksum-trailer)

[[e-mail]]

(Re-labeled because the content of this mail has next to nothing to do 
with the checksum trailer draft)

> >>> Harlan, I do not agree that you need to protect the association and
> >>> key exchange of NTS. The goal of the first exchanged messages of NTS
> >>> is to securely authenticate the server and exchange the cookie.
> 
> Please 'splain to me how you can "securely authenticate the server and
> exchange the cookie" with no MAC on the first exchanged message.

In one message exchange (association exchange), the client Alice receives 
a certificate (possibly a chain of certificates) from the server Bob, 
which links trust back to a trust anchor Trent.
Alice checks these certificates to obtain a guarantee of the pattern "I 
trust that Bob owns the private key X^-1 with which he can generate 
signatures that everyone can verify with the matching public key X. I 
trust that this is true because Trent says that it is."

In the following message exchange (cookie exchange), the client Alice 
supplies to Bob a certificate and a public key Y of her own, to which only 
she possesses the matching private key Y^-1. Bob generates the cookie C 
(from two input values: a secret seed Value S known only to him, and the 
hash value of Alice's certificate) which is to be used for the Alice-Bob 
association, he encrypts it with Alice's public key Y, signs the result 
with his own private key X^-1 and sends the whole resulting construct back 
to her.
Alice verifies the signature with Bob's public key X, and decrypts the 
cookie with her private key Y^-1. From this she obtains a guarantee of the 
pattern "I trust that the cookie C that I received is known only to me, 
because it was encrypted so that only I, the owner of Y, can read it. I 
further trust that C was intended for me by Bob, because the encrypted 
data was signed with X^-1, which Bob is the owner of."

From there on out, Alice sends the hash of her certificate in every time 
request. If the answering participant is able to generate a MAC which uses 
the cookie C as key, then he must be Bob, since only Alice and Bob are 
able to know C.

This is roughly how we securely authenticate the server and exchange the 
cookie without a MAC.



> >>> And yes, tough these messages are piggybacked on NTP messages, they
> >>> do not protect NTP's time stamps. However the NTS messages in itself
> >>> and especially the cookie exchange message are cryptographically
> >>> protected.
> 
> So the first 6 messages are cryptographically protected but the
> timestamps are not protected?

Yes: during the initial 3 exchanges, the actual NTS-related security data 
is protected, but the timestamps are not.

> 
> I have not dug in to the NTS protocol dance.  I am curious how the
> initial cookie exchange can be trusted if the timestamps are not
> protected.

I hope the text above serves to answer this?


 
> So the first 3 of 8 exchanges SHOULD be protected with a MAC until NTS
> is protecting the timestamps, as that's the startup period where we're
> trying to quickly and safely get enough samples to get the filter primed
> and see if the loop is stable.
> 
> >>> After the cookie is being exchanged all following time requests and
> >>> responses are of course protected by a MAC. So, a client always has
> >>> the option only to trust the authenticated time stamps. I don't see
> >>> that anyone want to distribute manually symmetric keys only for the
> >>> purpose to protect the first three message exchanges of NTS.
> 
> iburst.  Folks want ntpd stabilized in the first 11 seconds' time.  If
> that takes 15 or 17 seconds' time because we have to ignore the first
> few packets that will cause complaints, but these folks can set up
> symmetric keys or make other changes to mitigate this problem.

I fail to see how setting up a symmetric key in order to save 4 to 6 
seconds of time during an initial exchange is a good trade-off: I imagine 
that setting a symmetric key up is going to take more time than what is 
saved. Am I wrong here?

This also leads to the next point: one huge benefit of NTS based security 
over symmetric-key based security is that a server does not have to 
memorize data for each secure client association. On the one hand, this is 
an additional cost that needs to be considered in the trade-off discussed 
above. On the other hand, it illustrates my answer to the following 
question: 

> We're expecting NTS to be of more value in a WAN setting than in a LAN
> setting, right?

I wouldn't differentiate WAN vs. LAN so much as I would differentiate 
"many clients per server" vs. "few clients per server". We are expecting 
that NTS gives more value the more clients a single server wants to supply 
with time.



Let me try and sort out a piece of conversation.
Dieter:
> >>> And if you are in a situation in which you can exchange symmetric
> >>> keys with your customers you don't need to apply NTS. But in most
> >>> cases, distribution of symmetric keys are realistically not an
> >>> option.

Harlan: 
> >> Correct.  I am not saying MUST.
> >> 
> >> Are you saying that each of these 6 initial packets MUST NOT be
> >> protected by any sort of MAC?

Danny:
> > What he's saying is that the NTS exchange does not need to be 
protected
> > by a MAC. The Timestamps may need it if you want to use them or you 
wait
> > for NTS to complete its protocol exchange before trusting the packets.

Harlan:
> I asked what YOU were saying, Danny, not what Dieter was saying.
> Somebody removed a response in there.
> 
> Let's get clarification from Dieter, et al on this point.

As discussed above, we do not require MACs to protect the security data in 
the initial NTS exchanges.
To clarify: we are not saying that the initial packets MUST NOT be 
protected by any kind of MAC. If there already is other security stuff 
going on when NTS is set up, I suppose it might make sense to continue 
with it, to protect the time data in the exchanges where NTS does not 
protect them or simply in addition to NTS.
What we are saying is that we would absolutely NOT RECOMMEND setting up 
any other kind of security association solely for the initial 3 exchanges, 
simply because this setup process is more than likely to cause more effort 
than waiting until those initial exchanges are over.


Best regards,
Kristof

_______________________________________________
ntpwg mailing list
[e-mail]
http://lists.ntp.org/listinfo/ntpwg