Subject: [TICTOC] Problem statement

From: "Doug Arnold" <[email-masked]>
Date: Wed, 30 Jul 2008 03:22:41 -0700

Comment on TICTOC problem statement: draft-bryant-tictoc-probstat-02.txt
 
The need for precise time and frequency transfer in engineered LANs is
gernally met by IEEE 1588-2008.  Such networks include high speed
printing presses and other industrial automation applications, power
utility substation sync, etc.  However the 1588 committee failed to come
up with a security mechanism.  So secure time and frequency transfer in
engineered LANs could be one of the charters for TICTOC.
 
//Doug
_______________________________________________
TICTOC mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tictoc

---

From: "Pietilainen, Antti (NSN - FI/Espoo)" <[email-masked]>
Date: Wed, 30 Jul 2008 13:45:09 +0300

Doug,
You said that the IEEE 1588 committee failed to come up with a security
mechanism. However, it did come up with one in the form of a security
protocol annex. It is informative and experimental but it was overviewed
by NIST security experts. Consequently, I propose to re-word your
statement so that the existing security annex is credited somehow. I
also propose to start possible security work by seeing how far one can
go with the existing annex. You might include Ron Cohen as cc so he has
the option to comment.
Antti 

________________________________

	From: [email-masked] [mailto:[email-masked]]
On Behalf Of ext Doug Arnold
	Sent: 30 July, 2008 13:23
	To: [email-masked]
	Subject: [TICTOC] Problem statement

	Comment on TICTOC problem statement:
draft-bryant-tictoc-probstat-02.txt
	 
	The need for precise time and frequency transfer in engineered
LANs is gernally met by IEEE 1588-2008.  Such networks include high
speed printing presses and other industrial automation applications,
power utility substation sync, etc.  However the 1588 committee failed
to come up with a security mechanism.  So secure time and frequency
transfer in engineered LANs could be one of the charters for TICTOC.
	 
	//Doug

---

From: Yaakov Stein <[email-masked]>
Date: Wed, 30 Jul 2008 13:48:37 +0300

Antii

We could discuss the annex at some later meeting,
however, the annex you mention does not address the main concerns of a security mechanism for timing,
namely zero-knowledge proof of time and breaking the loop of authentication requiring time
and time requiring authentication (see the relevant slide from the interim meeting report).

Y(J)S

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Pietilainen, Antti (NSN - FI/Espoo)
Sent: Wednesday, July 30, 2008 1:45 PM
To: ext Doug Arnold; [email-masked]
Subject: Re: [TICTOC] Problem statement

Doug,
You said that the IEEE 1588 committee failed to come up with a security mechanism. However, it did come up with one in the form of a security protocol annex. It is informative and experimental but it was overviewed by NIST security experts. Consequently, I propose to re-word your statement so that the existing security annex is credited somehow. I also propose to start possible security work by seeing how far one can go with the existing annex. You might include Ron Cohen as cc so he has the option to comment.
Antti

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Doug Arnold
Sent: 30 July, 2008 13:23
To: [email-masked]
Subject: [TICTOC] Problem statement

The need for precise time and frequency transfer in engineered LANs is gernally met by IEEE 1588-2008.  Such networks include high speed printing presses and other industrial automation applications, power utility substation sync, etc.  However the 1588 committee failed to come up with a security mechanism.  So secure time and frequency transfer in engineered LANs could be one of the charters for TICTOC.

//Doug

---

From: Danny Mayer <[email-masked]>
Date: Wed, 30 Jul 2008 07:18:19 -0400

Doug,

This is an IETF working group not an IEEE working group. If 1588 needs a 
  security mechanism, it should be done by IEEE. This working group can 
only deal with security as it applies to the Internet and IETF 
protocols. IEEE 1588 is not an IETF protocol.

Danny

---

From: "Pietilainen, Antti (NSN - FI/Espoo)" <[email-masked]>
Date: Wed, 30 Jul 2008 14:29:35 +0300

Yaakov,
 
What you said may be true but it does not change the validity of my
statement: It is incorrect to claim that IEEE 1588 committee did not
come up with a security mechanism. Thus, my previous comment still
applies.
 
By the way, "zero-knowledge proof of time", "breaking the loop of
authentication requiring time", and "time requiring authentication"  are
all new terms. At least I did not find any hits in Google except the two
to the tictoc minutes from Paris. There must be some references that
describe these problems. Could you provide a pointer to a reference (or
pointers) for the group so that the validity of the terms could be
reviewed?
 
Quick comment for Danny Mayer. IETF is one of the organizations that may
define IEEE 1588 profiles. One should check, though, how free hands IEEE
1588 profile makers have. 
 
Antti

	From: ext Yaakov Stein [mailto:[email-masked]] 
	Sent: 30 July, 2008 13:49
	To: Pietilainen, Antti (NSN - FI/Espoo); ext Doug Arnold;
[email-masked]
	Subject: RE: [TICTOC] Problem statement

	Antii
	 
	We could discuss the annex at some later meeting,
	however, the annex you mention does not address the main
concerns of a security mechanism for timing,
	namely zero-knowledge proof of time and breaking the loop of
authentication requiring time
	and time requiring authentication (see the relevant slide from
the interim meeting report).
	 
	Y(J)S

On Behalf Of Pietilainen, Antti (NSN - FI/Espoo)

	Doug,
	You said that the IEEE 1588 committee failed to come up with a
security mechanism. However, it did come up with one in the form of a
security protocol annex. It is informative and experimental but it was
overviewed by NIST security experts. Consequently, I propose to re-word
your statement so that the existing security annex is credited somehow.
I also propose to start possible security work by seeing how far one can
go with the existing annex. You might include Ron Cohen as cc so he has
the option to comment.
	Antti 

		From: [email-masked]
[mailto:[email-masked]] On Behalf Of ext Doug Arnold
		Sent: 30 July, 2008 13:23
		To: [email-masked]
		Subject: [TICTOC] Problem statement

		The need for precise time and frequency transfer in
engineered LANs is gernally met by IEEE 1588-2008.  Such networks
include high speed printing presses and other industrial automation
applications, power utility substation sync, etc.  However the 1588
committee failed to come up with a security mechanism.  So secure time
and frequency transfer in engineered LANs could be one of the charters
for TICTOC.
		 
		//Doug

---

From: "Greg Dowd" <[email-masked]>
Date: Wed, 30 Jul 2008 05:20:31 -0700

http://www.eecis.udel.edu/~mills/ntp.html
and Mill's book on NTP are excellent sources for material on security in
the world of time transfer.

Greg Dowd
gdowd at symmetricom dot com (antispam format)
Symmetricom, Inc.
www.symmetricom.com <blocked::http://www.symmetricom.com/> 
"Everything should be made as simple as possible, but no simpler" Albert
Einstein

	From: [email-masked] [mailto:[email-masked]]
On Behalf Of Pietilainen, Antti (NSN - FI/Espoo)
	Sent: Wednesday, July 30, 2008 4:30 AM
	To: ext Yaakov Stein; Doug Arnold; ext Danny Mayer;
[email-masked]
	Subject: Re: [TICTOC] Problem statement

	Yaakov,
	 
	What you said may be true but it does not change the validity of
my statement: It is incorrect to claim that IEEE 1588 committee did not
come up with a security mechanism. Thus, my previous comment still
applies.
	 
	By the way, "zero-knowledge proof of time", "breaking the loop
of authentication requiring time", and "time requiring authentication"
are all new terms. At least I did not find any hits in Google except the
two to the tictoc minutes from Paris. There must be some references that
describe these problems. Could you provide a pointer to a reference (or
pointers) for the group so that the validity of the terms could be
reviewed?
	 
	Quick comment for Danny Mayer. IETF is one of the organizations
that may define IEEE 1588 profiles. One should check, though, how free
hands IEEE 1588 profile makers have. 
	 
	Antti

		From: ext Yaakov Stein [mailto:[email-masked]] 
		Sent: 30 July, 2008 13:49
		To: Pietilainen, Antti (NSN - FI/Espoo); ext Doug
Arnold; [email-masked]
		Subject: RE: [TICTOC] Problem statement

		Antii
		 
		We could discuss the annex at some later meeting,
		however, the annex you mention does not address the main
concerns of a security mechanism for timing,
		namely zero-knowledge proof of time and breaking the
loop of authentication requiring time
		and time requiring authentication (see the relevant
slide from the interim meeting report).
		 
		Y(J)S

[mailto:[email-masked]] On Behalf Of Pietilainen, Antti (NSN -
FI/Espoo)

		Doug,
		You said that the IEEE 1588 committee failed to come up
with a security mechanism. However, it did come up with one in the form
of a security protocol annex. It is informative and experimental but it
was overviewed by NIST security experts. Consequently, I propose to
re-word your statement so that the existing security annex is credited
somehow. I also propose to start possible security work by seeing how
far one can go with the existing annex. You might include Ron Cohen as
cc so he has the option to comment.
		Antti 

			 
			The need for precise time and frequency transfer
in engineered LANs is gernally met by IEEE 1588-2008.  Such networks
include high speed printing presses and other industrial automation
applications, power utility substation sync, etc.  However the 1588
committee failed to come up with a security mechanism.  So secure time
and frequency transfer in engineered LANs could be one of the charters
for TICTOC.
			 
			//Doug

---

From: "Doug Arnold" <[email-masked]>
Date: Wed, 30 Jul 2008 06:18:31 -0700

Thanks to Antti for correcting my over simplified statement that IEEE
1588 does not have security.  I should of said that the security
features are not fully developed in the 2008 release.  
 
As to why this is relevant to TICTOC: TICTOC should not solve problems
which are already solved by NTPv4 or IEEE 1588-2008.  Therefore we need
to understand what these protocols are capable of delivering, and what
they can not deliver.
 
//Doug

From: Pietilainen, Antti (NSN - FI/Espoo)
[mailto:[email-masked]] 
Sent: Wednesday, July 30, 2008 4:30 AM
To: ext Yaakov Stein; Doug Arnold; ext Danny Mayer; [email-masked]
Subject: RE: [TICTOC] Problem statement

Yaakov,

 
 
Antti

	Antii

	Y(J)S

	Doug,

		 
		 
		//Doug

---

From: Yaakov Stein <[email-masked]>
Date: Wed, 30 Jul 2008 17:21:47 +0300

By the way, "zero-knowledge proof of time", "breaking the loop of authentication requiring time", and "time requiring authentication"  are all new terms. At least I did not find any hits in Google except the two to the tictoc minutes from Paris. There must be some references that describe these problems. Could you provide a pointer to a reference (or pointers) for the group so that the validity of the terms could be reviewed?

Have a look at the autokey draft - you have until Friday to provide LC comments.

In any case, these are NOT new terms. They have been around since the original Autokey.

Y(J)S