[ntpwg] Forward of NTS discussion #2

[[e-mail]]

Hi all,

enclosed you will find further follow-ups on the NTS discussion.


----------------------------------
Physikalisch-Technische Bundesanstalt
Dr. Dieter Sibold
Q.42 - Serversysteme und Datenhaltung
QM-Verantwortlicher der Stelle IT-Infrastruktur
Bundesallee 100
D-38116 Braunschweig
Tel: [phone]
E-Mail: [e-mail]
----- Weitergeleitet von Dieter Sibold/PTB am 10.03.2014 16:27 -----

Von:	Stephen Röttger <[e-mail]>
An:	"Steven M. Bellovin" <[e-mail]>
Kopie:	Dieter Sibold <[e-mail]>, Harlan Stenn
            <[e-mail]>, "kristof.teichel" <[e-mail]>
Datum:	05.03.2014 21:51
Betreff:	Re: IETF draft



The key is used in the interval before its disclosure.
In time interval t, the clients will receive a packet with a MAC calculated
with a still unknown key k.
The clients will buffer this packet in order to verify it later.
In t+1, the key for t will be made public and the clients can verify the
MAC for the buffered packet.

Also, since the keys are calculated as a one-way function chain, e.g. k_i =
H(k_{i+1}), the client can verify to which time interval the disclosed key
belongs and that it wasn't disclosed yet when the packet was received.


On Wed, Mar 5, 2014 at 9:44 PM, Steven M. Bellovin <[e-mail]>
wrote:
      Then what is the point of the key?

      On Mar 5, 2014, at 3:42 PM, Stephen Röttger <
      [e-mail]> wrote:

      > But the client will know that the key was already disclosed without
      receiving any packets from the server.
      > This is due to the loose time synchronization and the fixed
      disclosing intervals.
      >
      >
      > On Wed, Mar 5, 2014 at 9:38 PM, Steven M. Bellovin <
      [e-mail]> wrote:
      >
      > >
      > > There is a slightly-convoluted attack scenario against the
      broadcast
      > > mode.  Assume a tree of switches, where the attacker is attached
      > > to some switch that is on-path to the victim.  The attacker DOSes
      > > the link towards the victim, waits for the next broadcast time
      > > message (with the accompanying key disclosure), then lifts the
      DOS
      > > and sends a bogus time message authenticated with that key to the
      > > victim.
      > >
      > > I don't see how this attack scenario will work. The client will
      not accept any broadcast messages he receives, if the corresponding
      key has already been disclosed. He can verify that since he is
      loosely time synchronized to the server, i.e. the maximum time
      difference is bounded.
      >
      > That’s the point of the DoS attack — it keeps the client from
      receiving the broadcast with that key.
      >


----- Weitergeleitet von Dieter Sibold/PTB am 10.03.2014 16:27 -----

Von:	"Steven M. Bellovin" <[e-mail]>
An:	Stephen Röttger <[e-mail]>
Kopie:	Dieter Sibold <[e-mail]>, Harlan Stenn
            <[e-mail]>, "kristof.teichel" <[e-mail]>
Datum:	05.03.2014 21:55
Betreff:	Re: IETF draft



OK, let me think about that.  I was reading quickly so I could get the
message out before boarding my flight....

You can think about other scenarios along those lines.

On Mar 5, 2014, at 3:51 PM, Stephen Röttger <[e-mail]>
wrote:

> The key is used in the interval before its disclosure.
> In time interval t, the clients will receive a packet with a MAC
calculated with a still unknown key k.
> The clients will buffer this packet in order to verify it later.
> In t+1, the key for t will be made public and the clients can verify the
MAC for the buffered packet.
>
> Also, since the keys are calculated as a one-way function chain, e.g. k_i
= H(k_{i+1}), the client can verify to which time interval the disclosed
key belongs and that it wasn't disclosed yet when the packet was received.
>
>
> On Wed, Mar 5, 2014 at 9:44 PM, Steven M. Bellovin <[e-mail]>
wrote:
> Then what is the point of the key?
>
> On Mar 5, 2014, at 3:42 PM, Stephen Röttger <[e-mail]>
wrote:
>
> > But the client will know that the key was already disclosed without
receiving any packets from the server.
> > This is due to the loose time synchronization and the fixed disclosing
intervals.
> >
> >
> > On Wed, Mar 5, 2014 at 9:38 PM, Steven M. Bellovin
<[e-mail]> wrote:
> >
> > >
> > > There is a slightly-convoluted attack scenario against the broadcast
> > > mode.  Assume a tree of switches, where the attacker is attached
> > > to some switch that is on-path to the victim.  The attacker DOSes
> > > the link towards the victim, waits for the next broadcast time
> > > message (with the accompanying key disclosure), then lifts the DOS
> > > and sends a bogus time message authenticated with that key to the
> > > victim.
> > >
> > > I don't see how this attack scenario will work. The client will not
accept any broadcast messages he receives, if the corresponding key has
already been disclosed. He can verify that since he is loosely time
synchronized to the server, i.e. the maximum time difference is bounded.
> >
> > That’s the point of the DoS attack — it keeps the client from receiving
the broadcast with that key.
> >
>
>


		 		 --Steve Bellovin, https://www.cs.columbia.edu/~smb






----- Weitergeleitet von Dieter Sibold/PTB am 10.03.2014 16:27 -----

Von:	Harlan Stenn <[e-mail]>
An:	[e-mail]
Kopie:	"Steven M. Bellovin" <[e-mail]>, Stephen
            <[e-mail]>, [e-mail], "Harlan
            Stenn" <[e-mail]>, "Harlan Stenn" <[e-mail]>
Datum:	06.03.2014 12:15
Betreff:	Re: IETF draft



I'd love to see the discussion on the ntpwg@ mailing list, and if we
move the discussion there I'm fine posting an announcement on hackers@
to let folks know where the discussion is being held.

I'm about to fall asleep, so if there is more for me to do I can do it
in about 8 hours' time.

H

----- Weitergeleitet von Dieter Sibold/PTB am 10.03.2014 16:27 -----

Von:	Kristof Teichel/PTB
An:	Dieter Sibold/PTB@PTB
Kopie:	"Steven M. Bellovin" <[e-mail]>, "Harlan Stenn"
            <[e-mail]>, "Harlan Stenn" <[e-mail]>, Stephen
            <[e-mail]>
Datum:	06.03.2014 12:26
Betreff:	Re: IETF draft



Hi all,

including the mailing list would be okay with me.

Greetings


-----Dieter Sibold/PTB schrieb: -----
An: "Steven M. Bellovin" <[e-mail]>, Stephen
<[e-mail]>, Kristof Teichel/PTB@PTB, "Harlan Stenn"
<[e-mail]>, "Harlan Stenn" <[e-mail]>
Von: Dieter Sibold/PTB
Datum: 06.03.2014 10:40
Betreff: Re: IETF draft

Hello all,

thanks for the current discussion. Steven, also note that in the broadcast
mode we use the mode "Not Re-using Keys" (sec. 3.7.2 of RFC 4082) of TESLA
which explicitly is designed to provide some protection against DoS
attacks. Nevertheless, as you already mentioned, these kind of
consideration should be added to the security considerations. We will put
this on the TODO list.

Sorry for the error in the draft regarding the calculation of the cookie.
Our intention was and is to calculate it just as you recommended (just as
Stephen already mentioned) with the only difference, that you recommend to
use the certificate and not the public key. Your arguments are convincing,
especially in the context of authorized time service. So, I think we will
change the draft accordingly.

We will also re-draft the minium requirements for the applied hash
algorithm. Also thanks for the suggestion of using CMS. This certainly has
to be done.

There is currently a discussion of using DANE as an additional alternative
approach to exchange certificates. During the last NTP WG session in
London, Brian Habermann strongly encouraged to evaluate this. What's your
impression?

Does anybody mind if we include the NTP mailing list in the discussion?

Greetings


----------------------------------
Physikalisch-Technische Bundesanstalt
Dr. Dieter Sibold
Q.42 - Serversysteme und Datenhaltung
QM-Verantwortlicher der Stelle IT-Infrastruktur
Bundesallee 100
D-38116 Braunschweig
Tel: [phone]
E-Mail: [e-mail]

"Steven M. Bellovin" ---05.03.2014 20:55:11---OK, let me think about that.
I was reading quickly so I could get the message out before boarding m

Von: "Steven M. Bellovin" <[e-mail]>
An: Stephen Röttger <[e-mail]>
Kopie: Dieter Sibold <[e-mail]>, Harlan Stenn
<[e-mail]>, "kristof.teichel" <[e-mail]>
Datum: 05.03.2014 20:55
Betreff: Re: IETF draft



OK, let me think about that.  I was reading quickly so I could get the
message out before boarding my flight....

You can think about other scenarios along those lines.

On Mar 5, 2014, at 3:51 PM, Stephen Röttger <[e-mail]>
wrote:

> The key is used in the interval before its disclosure.
> In time interval t, the clients will receive a packet with a MAC
calculated with a still unknown key k.
> The clients will buffer this packet in order to verify it later.
> In t+1, the key for t will be made public and the clients can verify the
MAC for the buffered packet.
>
> Also, since the keys are calculated as a one-way function chain, e.g. k_i
= H(k_{i+1}), the client can verify to which time interval the disclosed
key belongs and that it wasn't disclosed yet when the packet was received.
>
>
> On Wed, Mar 5, 2014 at 9:44 PM, Steven M. Bellovin <[e-mail]>
wrote:
> Then what is the point of the key?
>
> On Mar 5, 2014, at 3:42 PM, Stephen Röttger <[e-mail]>
wrote:
>
> > But the client will know that the key was already disclosed without
receiving any packets from the server.
> > This is due to the loose time synchronization and the fixed disclosing
intervals.
> >
> >
> > On Wed, Mar 5, 2014 at 9:38 PM, Steven M. Bellovin
<[e-mail]> wrote:
> >
> > >
> > > There is a slightly-convoluted attack scenario against the broadcast
> > > mode.  Assume a tree of switches, where the attacker is attached
> > > to some switch that is on-path to the victim.  The attacker DOSes
> > > the link towards the victim, waits for the next broadcast time
> > > message (with the accompanying key disclosure), then lifts the DOS
> > > and sends a bogus time message authenticated with that key to the
> > > victim.
> > >
> > > I don't see how this attack scenario will work. The client will not
accept any broadcast messages he receives, if the corresponding key has
already been disclosed. He can verify that since he is loosely time
synchronized to the server, i.e. the maximum time difference is bounded.
> >
> > That’s the point of the DoS attack — it keeps the client from receiving
the broadcast with that key.
> >
>
>


--Steve Bellovin, https://www.cs.columbia.edu/~smb





----- Weitergeleitet von Dieter Sibold/PTB am 10.03.2014 16:27 -----

Von:	Kristof Teichel/PTB
An:	"Steven M. Bellovin" <[e-mail]>
Kopie:	Dieter Sibold/PTB@PTB, Harlan Stenn <[e-mail]>, Stephen
            Röttger <[e-mail]>
Datum:	06.03.2014 14:17
Betreff:	Re: IETF draft



Hello all,

I wanted to reinforce what Stephen said: TESLA works with timed disclosure
of the keys. Therefore it should be impossible to make the client accept a
bogus packet authenticated with an "old" key, because by the schedule it
knows that this key was already disclosed and as such gives no proof of
origin.

There is a slight detail that Dieter and I spoke about but did not
communicate further: it might be better to have not only one interval step
between usage and disclosure of a key, but at least two. This is because
the client can not be perfectly sure that the server's clock is not one
interval ahead, but it can be certain that the server's clock is *at most*
one interval ahead.
Note that using a delay of only one interval can only make the client
discard a "good" packet, though, it can not make the client accept a bogus
packet. So this is more a general comment for understanding about TESLA,
and should not be relevant to the above discussion.

Regards,
Kristof Teichel


-----"Steven M. Bellovin" <[e-mail]> schrieb: -----
An: Stephen Röttger <[e-mail]>
Von: "Steven M. Bellovin" <[e-mail]>
Datum: 05.03.2014 20:55
Kopie: Dieter Sibold <[e-mail]>, Harlan Stenn
<[e-mail]>, "kristof.teichel" <[e-mail]>
Betreff: Re: IETF draft

OK, let me think about that.  I was reading quickly so I could get the
message out before boarding my flight....

You can think about other scenarios along those lines.

On Mar 5, 2014, at 3:51 PM, Stephen Röttger <[e-mail]>
wrote:

> The key is used in the interval before its disclosure.
> In time interval t, the clients will receive a packet with a MAC
calculated with a still unknown key k.
> The clients will buffer this packet in order to verify it later.
> In t+1, the key for t will be made public and the clients can verify the
MAC for the buffered packet.
>
> Also, since the keys are calculated as a one-way function chain, e.g. k_i
= H(k_{i+1}), the client can verify to which time interval the disclosed
key belongs and that it wasn't disclosed yet when the packet was received.
>
>
> On Wed, Mar 5, 2014 at 9:44 PM, Steven M. Bellovin <[e-mail]>
wrote:
> Then what is the point of the key?
>
> On Mar 5, 2014, at 3:42 PM, Stephen Röttger <[e-mail]>
wrote:
>
> > But the client will know that the key was already disclosed without
receiving any packets from the server.
> > This is due to the loose time synchronization and the fixed disclosing
intervals.
> >
> >
> > On Wed, Mar 5, 2014 at 9:38 PM, Steven M. Bellovin
<[e-mail]> wrote:
> >
> > >
> > > There is a slightly-convoluted attack scenario against the broadcast
> > > mode.  Assume a tree of switches, where the attacker is attached
> > > to some switch that is on-path to the victim.  The attacker DOSes
> > > the link towards the victim, waits for the next broadcast time
> > > message (with the accompanying key disclosure), then lifts the DOS
> > > and sends a bogus time message authenticated with that key to the
> > > victim.
> > >
> > > I don't see how this attack scenario will work. The client will not
accept any broadcast messages he receives, if the corresponding key has
already been disclosed. He can verify that since he is loosely time
synchronized to the server, i.e. the maximum time difference is bounded.
> >
> > That’s the point of the DoS attack — it keeps the client from receiving
the broadcast with that key.
> >
>
>


--Steve Bellovin, https://www.cs.columbia.edu/~smb





----- Weitergeleitet von Dieter Sibold/PTB am 10.03.2014 16:27 -----

Von:	"Steven M. Bellovin" <[e-mail]>
An:	[e-mail]
Kopie:	[e-mail], Harlan Stenn <[e-mail]>, Stephen
            Röttger <[e-mail]>
Datum:	07.03.2014 04:46
Betreff:	Re: IETF draft




On Mar 6, 2014, at 8:17 53AM, [e-mail] wrote:

> Hello all,
>
> I wanted to reinforce what Stephen said: TESLA works with timed
disclosure of the keys. Therefore it should be impossible to make the
client accept a bogus packet authenticated with an "old" key, because by
the schedule it knows that this key was already disclosed and as such gives
no proof of origin.
>
> There is a slight detail that Dieter and I spoke about but did not
communicate further: it might be better to have not only one interval step
between usage and disclosure of a key, but at least two. This is because
the client can not be perfectly sure that the server's clock is not one
interval ahead, but it can be certain that the server's clock is *at most*
one interval ahead.
> Note that using a delay of only one interval can only make the client
discard a "good" packet, though, it can not make the client accept a bogus
packet. So this is more a general comment for understanding about TESLA,
and should not be relevant to the above discussion.

Sounds good.  The fact that you do by definition have pretty good time sync
at this point gives much more assurance than one normally has when using
timestamps in security protocols.

Correct me if I'm wrong, though: aren't there some control functions, such
as indicating an impending leap-second?


>
> Regards,
> Kristof Teichel
>
>
> -----"Steven M. Bellovin" <[e-mail]> schrieb: -----
> An: Stephen Röttger <[e-mail]>
> Von: "Steven M. Bellovin" <[e-mail]>
> Datum: 05.03.2014 20:55
> Kopie: Dieter Sibold <[e-mail]>, Harlan Stenn
<[e-mail]>, "kristof.teichel" <[e-mail]>
> Betreff: Re: IETF draft
>
> OK, let me think about that.  I was reading quickly so I could get the
message out before boarding my flight....
>
> You can think about other scenarios along those lines.
>
> On Mar 5, 2014, at 3:51 PM, Stephen Röttger <[e-mail]>
wrote:
>
> > The key is used in the interval before its disclosure.
> > In time interval t, the clients will receive a packet with a MAC
calculated with a still unknown key k.
> > The clients will buffer this packet in order to verify it later.
> > In t+1, the key for t will be made public and the clients can verify
the MAC for the buffered packet.
> >
> > Also, since the keys are calculated as a one-way function chain, e.g.
k_i = H(k_{i+1}), the client can verify to which time interval the
disclosed key belongs and that it wasn't disclosed yet when the packet was
received.
> >
> >
> > On Wed, Mar 5, 2014 at 9:44 PM, Steven M. Bellovin
<[e-mail]> wrote:
> > Then what is the point of the key?
> >
> > On Mar 5, 2014, at 3:42 PM, Stephen Röttger
<[e-mail]> wrote:
> >
> > > But the client will know that the key was already disclosed without
receiving any packets from the server.
> > > This is due to the loose time synchronization and the fixed
disclosing intervals.
> > >
> > >
> > > On Wed, Mar 5, 2014 at 9:38 PM, Steven M. Bellovin
<[e-mail]> wrote:
> > >
> > > >
> > > > There is a slightly-convoluted attack scenario against the
broadcast
> > > > mode.  Assume a tree of switches, where the attacker is attached
> > > > to some switch that is on-path to the victim.  The attacker DOSes
> > > > the link towards the victim, waits for the next broadcast time
> > > > message (with the accompanying key disclosure), then lifts the DOS
> > > > and sends a bogus time message authenticated with that key to the
> > > > victim.
> > > >
> > > > I don't see how this attack scenario will work. The client will not
accept any broadcast messages he receives, if the corresponding key has
already been disclosed. He can verify that since he is loosely time
synchronized to the server, i.e. the maximum time difference is bounded.
> > >
> > > That’s the point of the DoS attack — it keeps the client from
receiving the broadcast with that key.
> > >
> >
> >
>
>
> --Steve Bellovin, https://www.cs.columbia.edu/~smb
>
>
>
>
>


		 		 --Steve Bellovin, https://www.cs.columbia.edu/~smb


----- Weitergeleitet von Dieter Sibold/PTB am 10.03.2014 16:27 -----

Von:	"Steven M. Bellovin" <[e-mail]>
An:	[e-mail]
Kopie:	Stephen <[e-mail]>, [e-mail],
            Harlan Stenn <[e-mail]>, Harlan Stenn <[e-mail]>
Datum:	07.03.2014 04:54
Betreff:	Re: IETF draft




On Mar 6, 2014, at 5:40 50AM, [e-mail] wrote:

> There is currently a discussion of using DANE as an additional
alternative
> approach to exchange certificates. During the last NTP WG session in
> London, Brian Habermann strongly encouraged to evaluate this. What's your
> impression?

I like DANE, but there are two things to think about here.

First, DANE is a lot slower than just a certificate chain, because you have
to go out to the DNS a lot.  I don't think that's a big issue, but it is a
number of request/respond cycles to work your way up the tree; during this
point, someone or something has got to keep state.  Bear this in mind
especially when the server (per my suggestion) is validating a client
certificate.

The other point is that it's unclear if the registrars are good enough at
security to really trust their DNSSEC-authenticated records.  There have
been any number of name hijackings from them.  By contrast, the CAs are in
the security business.

My own personal guess is that for NTP, it's fine.  NTP is intended to work
with a diversity of sources; even if one is the victim of an bad DNS
registrar and the attacker launches the proper sort of active attack to
intercept the traffic and respond with bad time info -- it's still just one
source; NTP has always been able to work with a single falseticker per
Mills' early papers.  Mention the issue in the security considerations --
i.e., that a cautious site relying on DANE should pick time servers that
rely on an assortment of DNS registrars -- if they're concerned about this
attack.
>
> Does anybody mind if we include the NTP mailing list in the discussion?

I have no objection, but please add me to the authorized posters list.
>
> Greetings
>
>
> ----------------------------------
> Physikalisch-Technische Bundesanstalt
> Dr. Dieter Sibold
> Q.42 - Serversysteme und Datenhaltung
> QM-Verantwortlicher der Stelle IT-Infrastruktur
> Bundesallee 100
> D-38116 Braunschweig
> Tel: [phone]
> E-Mail: [e-mail]
>
>
>
> Von:		 "Steven M. Bellovin" <[e-mail]>
> An:		 Stephen Röttger <[e-mail]>
> Kopie:		 Dieter Sibold <[e-mail]>, Harlan Stenn
>            <[e-mail]>, "kristof.teichel" <[e-mail]>
> Datum:		 05.03.2014 20:55
> Betreff:		 Re: IETF draft
>
>
>
> OK, let me think about that.  I was reading quickly so I could get the
> message out before boarding my flight....
>
> You can think about other scenarios along those lines.
>
> On Mar 5, 2014, at 3:51 PM, Stephen Röttger <[e-mail]>
> wrote:
>
>> The key is used in the interval before its disclosure.
>> In time interval t, the clients will receive a packet with a MAC
> calculated with a still unknown key k.
>> The clients will buffer this packet in order to verify it later.
>> In t+1, the key for t will be made public and the clients can verify the
> MAC for the buffered packet.
>>
>> Also, since the keys are calculated as a one-way function chain, e.g.
k_i
> = H(k_{i+1}), the client can verify to which time interval the disclosed
> key belongs and that it wasn't disclosed yet when the packet was
received.
>>
>>
>> On Wed, Mar 5, 2014 at 9:44 PM, Steven M. Bellovin <[e-mail]>
> wrote:
>> Then what is the point of the key?
>>
>> On Mar 5, 2014, at 3:42 PM, Stephen Röttger <[e-mail]>
> wrote:
>>
>>> But the client will know that the key was already disclosed without
> receiving any packets from the server.
>>> This is due to the loose time synchronization and the fixed disclosing
> intervals.
>>>
>>>
>>> On Wed, Mar 5, 2014 at 9:38 PM, Steven M. Bellovin
> <[e-mail]> wrote:
>>>
>>>>
>>>> There is a slightly-convoluted attack scenario against the broadcast
>>>> mode.  Assume a tree of switches, where the attacker is attached
>>>> to some switch that is on-path to the victim.  The attacker DOSes
>>>> the link towards the victim, waits for the next broadcast time
>>>> message (with the accompanying key disclosure), then lifts the DOS
>>>> and sends a bogus time message authenticated with that key to the
>>>> victim.
>>>>
>>>> I don't see how this attack scenario will work. The client will not
> accept any broadcast messages he receives, if the corresponding key has
> already been disclosed. He can verify that since he is loosely time
> synchronized to the server, i.e. the maximum time difference is bounded.
>>>
>>> That’s the point of the DoS attack — it keeps the client from receiving
> the broadcast with that key.
>>>
>>
>>
>
>
> 		 		  		 		  --Steve Bellovin,
https://www.cs.columbia.edu/~smb
>
>
>
>
>


		 		 --Steve Bellovin, https://www.cs.columbia.edu/~smb
_______________________________________________
ntpwg mailing list
[e-mail]
http://lists.ntp.org/listinfo/ntpwg