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.