Re: [ntpwg] The next step of draft-ietf-ntp-checksum-trailer

[Harlan Stenn <[e-mail]>]

Danny Mayer writes:
> On 3/7/2016 5:54 PM, Harlan Stenn wrote:
>> Hi Dieter,
>> 
>> [e-mail] writes:
>>> "ntpwg" <ntpwg-bounces+dieter.sibold=[e-mail]> schrieb am 
>>> 07.03.2016 14:16:25:
>>>> On Mon, Mar 07, 2016 at 12:35:56PM +0000, Harlan Stenn wrote:
>>>>> Originally, if there was an extension field there MUST be a MAC.
>>>>
>>>> Right. That requirement was not necessary and it was later removed.
>> 
>> The above claim has not yet been proven.
> 
> See RFC 5905 Section 7.3 where it was optional but 7.5 said it was
> required in the presence of an extension field. It was ambiguous and has
> been clarified in the EF draft.

Yes.  It is optional UNLESS THERE IS AN EF.  Then it is required.

If the errata does not make this clear or reinforce this, the
"clarification" in the errata is wrong.

>>>>> MAC protection is good.  NTS uses a 'single' Field Type, but the
>>>>> first few packets have no MAC protection.  Therefore, the first
>>>>> few packets of an NTS exchange arguably MUST have MAC protection
>>>>> outside the NTS packet
>>>>
>>>> With what key would that MAC be generated? Unless I misunderstood
>>>> how NTS is supposed to work, the first few packets are simply not
>>>> authenticated and can't be used for anything except initialization
>>>> of the NTS association.
>> 
>> Answered in a separate email - symmetric key is AVAILABLE for this.
>> Doing this is a MAY/SHOULD.  Not a MUST.

If the above quote came from me, it's not clear that the first few
packets of the NTS exchange MAY/SHOULD have MAC protection.  I don't
recall the context anymore.

Starting with the 7th NTS packet, the NTS EF has a MAC.

We need to see what, if any, extra protection should be applied to the
first 6 packets.

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

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

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.

>>> A client has the choice to trust or not to trust the time
>>> stamps exchanged during the association and cookie exchange.

The iburst exchange is an ideal opportunity to exchange NTS keys.  It's
also a critically important time to exchange trustable timestamps.

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.

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

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

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.

And you're assuming the sender can dictate policy to the recipient
again.

It's the recipient's choice as to whether or not it will accept
unauthenticated packets.

I'm also curious to see how NTS plays with iburst.

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