Secure Time BOF #2
March 15, 1999
Draft Minutes
Co-chairs: Pat Cain, GTE, and Tim Polk, NIST
Scribe: Tim Polk

Pat Cain from GTE (BBN Technologies) opened the Secure Time BOF #2 with
a description of the Secure Time BOF #1 in Orlando.  While the Orlando
BOF was well attended, we were concerned by the low subscription rate of
the mailing list.  If attendees want to be on the list, please place a
"check mark" by your name on the blue sheet.  Currently, we have email
list and web site hosted by GMT at stime.org.

The main goal of this BOF is developing an acceptable charter to give to
the Area Directors so we can become a working group.  Since this is the
second secure time BOF, we must become a working group or disband.

Pat led a discussion of charter issues.  The main problem is "How does
an internet system obtain reliable time of day without a useful on-board
clock."  Previous discussions in Orlando and on the list, had strayed
from the core issues.  As a result, Pat proposed a reduction in the
scope of the charter to the core issue set.  This will allow a cleaner
more compact charter.  The proposal was that we request a 12 month
charter, and concentrating on securing the current NTP protocols.  The
new schedule would be: (1) charter today; (2) one or two more drafts;
and (3) submit for RFC around the November meeting.  New work items
would be considered, assuming appropriate progress of the core items
and strong drafts were submitted for consideration.

At Orlando, we discussed the "temporal token" as an additional topic.
The chairs proposed moving that topic to pkix and integrating it with
the timestamp work. 

At this point, Pat requested feedback from the audience.  The resulting
discussion addressed a wide variety of topics.

* It was suggested that it would be useful to describe who the clients/
users of secure NTP really are.  It was also noted that securing NTP
does NOT give me accurate time, it just ensures that I know where it
came from.

* It was noted that using PKI as a basis for securing NTP is somewhat
circular.   The client must already know the time to some level.

* The effect on existing systems was questioned:  "Will things like MD5
be deprecated?"  The answer is no, existing mechanisms will continue
to be available for systems that don't need the additional security.  
Marcus Leech noted that the current MD5 "prepended key" technique has
a known security weakness.  This was an excellent example of the
requirement for this work.

* There was a question as to what will make secure NTP unique.  We will
not presume a time infrastructure with authorization certificates, or
some thing that complicated.  A client will need to know what set of
time servers it trusts.  The protocols developed in this working group
will not tell you how to choose whom to trust.

* There was also a discussion for the need for traceability.  The
group agreed this was an important issue.  Time trace route should
be supported as an optional part of setup.

* The scope is not designed to prevent getting bad time from a time
server that has been attacked.  The point is simply to authenticate
the source of time.  A client could use multiple time servers, though. 
Without a coordinated attack on the majority of servers, a client could
choose the best time servers.

* There is an assumption that the client that has some idea what time it
is.  In practice, all systems have a battery on their clock and start
with some clue of the current time.  So bootstrapping procedures can
assume some rudimentary idea of current time (within minutes, perhaps).

* There was a brief discussion of protecting NTP with a TLS connection.
The time delays inherent in TCP/IP based protocols preclude such an
approach.  Marcus Leech pointed out that we could use TCP/IP based
protocol during setup.  For example, we could use TLS for the key
agreement pieces, and sending traceability information.  Then the
NTP protocol is basically unchanged (perhaps longer hash, etc.)

The discussion suggests two work items: one document for traceability
specification and setup, and a second for the NTP extensions.  Others
suggested breaking out traceability into a standalone document, since
that is probably the hardest issue.

Based on a straw poll, the group achieved rough consensus on the
charter.  We will reduce the scope to making NTP secure and request a
12 month charter.  The lone dissenter would like to extend the protocol
to demonstrate that the time data is accurate, and felt it should be
integrated into the protocol.  Marcus Leech suggested that was a
research topic, and should not be taken on by the working group.

Another attendee noted that a policy schema would be a very welcome work
item.  What are the issues that go into making policy on time?  How many
servers should be used, how many hits, etc.?  The group felt this might
be considered as a new work item after we make progress on NTP.