Minutes of the STIME meeting Tuesday, July 13, 1999, 9:00a-11:00a The Authenticated NTP (STIME) group met at the 45th IETF in Oslo, Norway. We have started work and are meeting although we have not been officially blessed by the IESG. There were 70 attendees and one chair, Pat Cain, in attendance. The initial agenda contained five items: Charter Comments An open comment period for a European perspective Methods of generating the shared secret A proposal to fix the 'millenium bug' in NTP4 status of the draft 1. No modifications to the proposed agenda were offered. 2. Charter comments. The chair identified the one comment received on the proposed charter. One of the Security ADs expressed concern about our aggressive schedule. The current draft charter will be modified to address these concerns. Denis Pinkas asked if we could read the charter since he had not seen it anywhere on the IETF site. The chair responded with a brief reading of the charter and stated that since we were a WG in flux, we have not yet been added to the 'official' ietf web page. 3. As this IETF was hosted in Europe, the chair asked if anyone wanted to express a European Opinion about our work. The concern was raised privately previously about the German requirements for trusted time. No offers were received from the assemblage to comment. 4. Methods of generating the shared secret. The intent of the STIME work is to specify a key exchange and protocol-gram to allow clients to authenticate the integrity and originator of an NTP packet. Although NTP currently has a mechanism to provide authentication via a shared-secret, NTP does not define how to generate the secret. So, we need to specify a standard way to generate the shared secret. The intent is to specify an already existing IETF mechanism and NOT to redevelop a new key management system Q: Why don't we use an SSL or other already spec-ed computation? A: SSL is TCP-based, so the client must be running more than just NTP required UDP. The intent is to specify the Internet Key Exchange Protocol (IKE) from the IPSEC WG as a default, and possibly specifying a simple authentication mechanism. Q: How much load will be put on the strontium server if it has to do IKE computations? A: We don't have a good number to answer. The working group discussed whether client authentication by the server is a goal. The current feeling is it is not. Q: Then why not run NTP over IPSEC or TLS? A: The intent is to try to do a 'simple' solution that doesn't require running a full IP(SEC) stack. Q: If the intent is to use a MAC as opposed to a full digital signature, how do you prove to a third party that the time was correct? A: We do not expect to use this protocol to prove to a third party anything. Applications must be written to provide the 'trustability'. Q: We need to make the protocol robust enough to handle a booting up client. A: This topic was discussed in Minneapolis and we didn't forget it. The group discussed the options for the shared secret algorithms. The group agreed that we need to specify a robust algorithm and a simple version, as we need to support both a one-time client request and a longer-term (streaming?) variant. The group also noted that we may have to support for both multicast/broadcast and unicast. 5. The millenium problem? The time counter in NTP4 has two 32 bit quantities. The numbers roll-over in 2036. There has been some debate as to whether this is a problem or not. [Each roll-over is noted as an epoch.] The proposal is to create a new extension (UTC96) for NTP4 to allow a both forward and reverse time specification that will not 'roll-over' for 2**31 epochs. Q: (From the chair). I'm not so sure that solving this problem is contained within our charter. The group discussed this for a while. The group consensus is that the problem should be fixed, but not specifically by this working group, so the discoverer of the problem may want to write an ID suggesting a solution and letting it go by itself. Q: Why don't we just increase the word size from 32 bits to 64 bits, recompile, and ignore the problem for a few centuries? A: A short treatise on NTP packet formats, leading to a "it won't work" answer. 6. The next draft. The current draft is on the STIME web site but has expired in the IETF directory. A new draft should be posted in the next couple of weeks as it gets revised from this meeting. Q: If the draft still relies on computing a signature, we need to specify an 'expected delay' field so the client knows how much delay is in the time computation. A discussion ensued as to the difference between a MAC and a signature. The consensus was to develop one mechanism to generate the shared secret and one mode for simple clients. More concerns were raised about the use of NTP in time stamping and other applications. One of the ADs pointed out that timestamping and other applications were out of scope of the group and should be forwarded to the PKIX group. More discussion was asserted to make sure that we support the 'one-shot' time requests from clients and whether this conflicts with NTP's session-oriented operation. Although agreeing to a shared secret is slow, once agreed to, operations are fast. But since the predominant mode of NTP is one-shot exchanges, we may need to specify a multiple mechanisms. The meeting adjourned. The minutes were reported by Pat Cain.