[ntpwg] Forward of NTS discussion #1

[[e-mail]]

Hi all,

enclosed you will find follow-ups on the NTS discussion that starts at
March, the 4th.



----------------------------------
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:24 -----

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




On Mar 5, 2014, at 5:43 57AM, [e-mail] wrote:

> Hello Steven,
>
> thank you very much for your comments. Especially your suggestion of
> considering CMS. We shall consider all of your comments with care.

Thinking further, the initial setup may need more care to prevent
replay attacks.  Let me think about this a bit.

Also, about that attack scenario I mentioned: that's the sort of
thing that should be in the security considerations, but doesn't
otherwise merit any changes.  The discussion should also include
a suggested range of values for the TESLA-like mechanism, with guidance
on when to go higher or lower.

>
> Do you mind if I pass your comments to the NTP working group?

Of course not.

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


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

Von:	"Steven M. Bellovin" <[e-mail]>
An:	"[e-mail]" <[e-mail]>
Kopie:	Harlan Stenn <[e-mail]>
Datum:	05.03.2014 14:20
Betreff:	Re: IETF draft



Looking further , there's a serious risk of replay of the server_cert
message. The best defense is to have a random challenge in the client
message; the reply should sign it. Alternatively, sign the current time in
the reply.

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

Sent from from a handheld; please excuse tyops

> On Mar 5, 2014, at 5:43 AM, [e-mail] wrote:
>
> Hello Steven,
>
> thank you very much for your comments. Especially your suggestion of
> considering CMS. We shall consider all of your comments with care.
>
> Do you mind if I pass your comments to the NTP working group?
>
> Regards
> Dieter
>
>
> ----------------------------------
> 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:    [e-mail]
> Kopie:    Harlan Stenn <[e-mail]>
> Datum:    04.03.2014 16:58
> Betreff:    Re: IETF draft
>
>
>
> I got tethering working while at the airport, so I did a quick
> read-through.
> I think your basic security model is sound; however, there are risks and
> a minor error.
>
>
> 5.1 is confusing.  It says
>
>          The server does not keep a
> state of the client. Therefore it has to recalculate the cookie each
> time it receives a request from the client. To this end, the client
> has to attach the hash value of its public key to each request (see
> Section 6.4).
>
> However, just the hash of the public key does not allow recalculation
> of that HMAC, because you need the full cert to calculate that HMAC.
>
> I suggest that it instead use
>
>      cookie = MSB_128 (HMAC(server seed, H(X.509 cert of client))),
>
> Note that it uses the cert, not the key, because that lists any
> organizational data that might be needed.  This in turn matters
> for access control decisions by the server, which in turn matters
> a lot for broadcast.
>
> 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.
>
>
> 6.3.2: You're directly encrypting something other than a symmetric
> key with a public key algorithm.  You're also signing something
> without hashes, etc.  That whole concept is very, very fragile.
> Seriously consider using CMS which may imply encrypting that
> stuff with a symmetric key that is properly wrapped.  I suggest
> consulting with Russ Housley on the best format for what you want
> to do here -- there are many subtle traps when doing public key
> signing or encryption.
>
>
> 8.1: is SHA-1 accepted?  I'd say no; there's no reason to include
> it for new protocols.
>
>
>
>
>> On Mar 4, 2014, at 3:51 PM, [e-mail] wrote:
>>
>> Hello Steven,
>>
>> that's a pity, I'm just arrived at the IETF meeting. So we missed.
> Anyway,
>> if you could read the draft we should very much appreciate to get your
>> comments.
>>
>> Greetings and a nice journey
>> Dieter Sibold
>>
>>
>> ----------------------------------
>> 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:         Harlan Stenn <[e-mail]>
>> Kopie:         Dieter Sibold <[e-mail]>
>> Datum:         04.03.2014 11:11
>> Betreff:         Re: IETF draft
>>
>>
>>
>>
>>> On Mar 3, 2014, at 7:44 PM, Harlan Stenn <[e-mail]> wrote:
>>>
>>> Hi Steve,
>>>
>>>> On 2/11/14 11:08 PM, Harlan Stenn wrote:
>>>> Howdy sir,
>>>>
>>>> If you have time to look at this that would be swell.
>>>
>>> The Network Time Security document I sent you from  Dieter is going to
>>> be discussed at this Wednesday's NTP IETF meeting.  We figure there
will
>>> be one more go-round before it's finalized, but if you have had a
chance
>>> to review the document it will certainly speed the process along.
>>>
>>> You are doing well, I trust, and your weather isn't too horrible?
>> I'll see if I can read it before then.  I'm at the IETF meeting, but I
>> leave today; I have to teach on Wednesday.
>>
>>
>>                                    --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:24 -----

Von:	[e-mail]
An:	[e-mail]
Datum:	05.03.2014 18:31
Betreff:	[ntpwg] WG: Comments to NTS draft
Gesendet von:	ntpwg-bounces+dieter.sibold=[e-mail]




Enclosed you will find  valuable comments from Steven Bellovin on the
Network Time Security draft. He allowed me to send it to the mailing list.

Dieter


----------------------------------
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 05.03.2014 13:21 -----

Von:		 "Steven M. Bellovin" <[e-mail]>
An:		 [e-mail]
Kopie:		 Harlan Stenn <[e-mail]>
Datum:		 04.03.2014 16:58
Betreff:		 Re: IETF draft



I got tethering working while at the airport, so I did a quick
read-through.
I think your basic security model is sound; however, there are risks and
a minor error.


5.1 is confusing.  It says

		 		   The server does not keep a
 state of the client. Therefore it has to recalculate the cookie each
 time it receives a request from the client. To this end, the client
 has to attach the hash value of its public key to each request (see
 Section 6.4).

However, just the hash of the public key does not allow recalculation
of that HMAC, because you need the full cert to calculate that HMAC.

I suggest that it instead use

      cookie = MSB_128 (HMAC(server seed, H(X.509 cert of client))),

Note that it uses the cert, not the key, because that lists any
organizational data that might be needed.  This in turn matters
for access control decisions by the server, which in turn matters
a lot for broadcast.

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.


6.3.2: You're directly encrypting something other than a symmetric
key with a public key algorithm.  You're also signing something
without hashes, etc.  That whole concept is very, very fragile.
Seriously consider using CMS which may imply encrypting that
stuff with a symmetric key that is properly wrapped.  I suggest
consulting with Russ Housley on the best format for what you want
to do here -- there are many subtle traps when doing public key
signing or encryption.


8.1: is SHA-1 accepted?  I'd say no; there's no reason to include
it for new protocols.



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





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

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

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:36
Betreff:	Fwd: Re: IETF draft



Hi Steven,

Thank you very much for your comments.

      5.1 is confusing.  It says
                        The server does not keep a
       state of the client. Therefore it has to recalculate the cookie each
       time it receives a request from the client. To this end, the client
       has to attach the hash value of its public key to each request (see
       Section 6.4).
      However, just the hash of the public key does not allow recalculation
      of that HMAC, because you need the full cert to calculate that HMAC.
      I suggest that it instead use
            cookie = MSB_128 (HMAC(server seed, H(X.509 cert of client))),
      Note that it uses the cert, not the key, because that lists any
      organizational data that might be needed.  This in turn matters
      for access control decisions by the server, which in turn matters
      a lot for broadcast.

There is actually an error in the draft in this chapter.
Our real intention was to write:
cookie = MSB_128 (HMAC(server seed, H(public key of client))).
(note that additional Hash operation on the public key)

I think using H(X.509 cert of client) instead would only make a difference
if two clients use the same public key but different certificates. Since it
has no drawbacks and will probably be easier to implement as well, I think
this would be a good modification.

      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.

      6.3.2: You're directly encrypting something other than a symmetric
      key with a public key algorithm.  You're also signing something
      without hashes, etc.  That whole concept is very, very fragile.
      Seriously consider using CMS which may imply encrypting that
      stuff with a symmetric key that is properly wrapped.  I suggest
      consulting with Russ Housley on the best format for what you want
      to do here -- there are many subtle traps when doing public key
      signing or encryption.

Yes, we definitely have to specify the message format. This one is on our
TODO list :).

      8.1: is SHA-1 accepted?  I'd say no; there's no reason to include
      it for new protocols.

Removing it sounds good to me.

Thanks,
Stephen

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

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:38
Betreff:	Re: IETF draft




>
> 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:24 -----

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:43
Betreff:	Re: IETF draft



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:24 -----

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:44
Betreff:	Re: IETF draft



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.
>
_______________________________________________
ntpwg mailing list
[e-mail]
http://lists.ntp.org/listinfo/ntpwg