Subject: [ntpwg] WG: Comments to NTS draft

From: [email-masked]
Date: Wed, 5 Mar 2014 13:41:18 +0000

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: +49-531-592-84 20
E-Mail: [email-masked]
----- Weitergeleitet von Dieter Sibold/PTB am 05.03.2014 13:21 -----

Von:	"Steven M. Bellovin" <[email-masked]>
An:	[email-masked]
Kopie:	Harlan Stenn <[email-masked]>
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
[email-masked]
http://lists.ntp.org/listinfo/ntpwg