[TICTOC] security ID submitted for review
"David L. Mills" <mills@udel.edu> Thu, 01 August 2013 20:42 UTC
Return-Path: <mills@udel.edu>
X-Original-To: tictoc@ietfa.amsl.com
Delivered-To: tictoc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B41AE11E815E for <tictoc@ietfa.amsl.com>; Thu, 1 Aug 2013 13:42:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level:
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TfoaMw13374W for <tictoc@ietfa.amsl.com>; Thu, 1 Aug 2013 13:42:18 -0700 (PDT)
Received: from mail.eecis.udel.edu (louie.udel.edu [128.4.40.12]) by ietfa.amsl.com (Postfix) with ESMTP id 8382411E813F for <tictoc@ietf.org>; Thu, 1 Aug 2013 13:42:18 -0700 (PDT)
Received: from [192.168.1.2] (pool-74-109-13-78.phlapa.fios.verizon.net [74.109.13.78]) (Authenticated sender: mills@mail.eecis.udel.edu) by mail.eecis.udel.edu (Postfix) with ESMTP id 2E31966D; Thu, 1 Aug 2013 16:42:11 -0400 (EDT)
Message-ID: <51FAC820.3090401@udel.edu>
Date: Thu, 01 Aug 2013 20:42:08 +0000
From: "David L. Mills" <mills@udel.edu>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: NTP Working Group <ntpwg@lists.ntp.org>
Content-Type: multipart/alternative; boundary="------------040509030609050009080808"
Cc: "tictoc@ietf.org" <tictoc@ietf.org>
Subject: [TICTOC] security ID submitted for review
X-BeenThere: tictoc@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Timing over IP Connection and Transfer of Clock BOF <tictoc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tictoc>, <mailto:tictoc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tictoc>
List-Post: <mailto:tictoc@ietf.org>
List-Help: <mailto:tictoc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tictoc>, <mailto:tictoc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 01 Aug 2013 20:42:24 -0000
Guys, Here are some general comments on the ID. I apologize if they are a little rough as I have to dictate this message instead of my usual polished wordsmithing. format. The ID does not specify an extension field format. Presumably, the extension field format described in RFC 5906 is adequate with new message types as required. However, in keeping with long Internet tradition, it must be possible to determine correct format without interpreting the header or extension fields. In addition, it must be possible to verify message integrity without interpreting the extension fields. In particular, the private key for the message authentication code (MAC) , if used, must be known beforehand. This is where the "cookie snatcher" issue comes up as described in previous messages. In particular, an important constraint for normal operation is that extension fields are not used unless required for cookie determination. Glaring vulnerability exists when using extension fields, as the key value is public and must be known in advance. This invites a cut-and-paste attack, as well as header changes, even if subsequently detected by the on-wire protocol. certificate. Both RFC 5906 and the ID require the server certificate. The server certificate can be conveyed, either off-line, or directly or indirectly via a certificate trail as described in RFC 5906 or the ID. If obtained via the trail, there is a hazzard due to a middle-man attack and masquerade. A solution proposed in RFC 5906 uses an identity scheme such as IFF. There may be an equivalent, or better schemes available now. protocol. Most of the discussion following the ID announcement is from protocol weenies, affectionately known as protomeister. When the Autokey scheme was first defined in 1996, the signature time required ranged up to one second on the computers of the time. Therefore, a clogging hazzard existed in the form of a replay attack. This is why the timestamp was included in the extension field format to suppress duplicates. Most of the extension fields were computed and signed off-line. Nevertheless, a clogging vulnerability remains in the cookie request message. This requires the server to do two public key incriptions and two hash functions. Today, this overhead may no longer be considered excessive; however, this may not be true for public time servers with thousands and thousands of clients. In broadcast mode, the protocols described in RFC 5906 and the ID are messy and with several possible vulnerabilities. Here is a suggestion that might be useful. Define a new broadcast packet format as the NTP header followed by one extension field representing the MAC. The extension field represents the signature of the header computed using the private key of the server and can be verified by the client using the public key in the server certificate. Originally, this was considered an unacceptable dilution of accuracy due to the variability of the signature computing time and the length of the signature. However, at least in modern NTP, the interleaved broadcast mode can be used to correct for this overhead. This assumes that the overhead for either the server or client is reduced using fast modern processors. As mentioned previously, in NTP symmetric mode the current protocol in RFC 5906 should be changed to use Diffie-Hellman key agreement. This is so easy to do that it can be incorporated separately in the standard. While the interleaved mode is useful in symmetric and broadcast modes, it can't be used when the server does not maintain state separately for each client. However, as in the orginal NTP design many years ago, the output delay can be computed for each transmitted server packet. The output delay can be averaged and used to augment the transmit timestamp or retrieve using an extension field. Note that this message does not address the cookie snatcher issue discussed by our German protomeisters, who have concocted a brillient solution. Many of the issues discussed are relevant to both NTP and PTP, although the on-wire protocol details may be different. I hope this discussion is useful in either context. Dave
- [TICTOC] security ID submitted for review David L. Mills
- Re: [TICTOC] [ntpwg] security ID submitted for re… Kurt Roeckx
- Re: [TICTOC] [ntpwg] security ID submitted for re… David L. Mills
- Re: [TICTOC] [ntpwg] security ID submitted for re… Kurt Roeckx
- Re: [TICTOC] [ntpwg] security ID submitted for re… Kurt Roeckx
- Re: [TICTOC] [ntpwg] security ID submitted for re… dieter.sibold
- Re: [TICTOC] [ntpwg] security ID submitted for re… dieter.sibold
- Re: [TICTOC] [ntpwg] security ID submitted for re… Kurt Roeckx
- Re: [TICTOC] [ntpwg] security ID submitted for re… David L. Mills
- Re: [TICTOC] [ntpwg] security ID submitted for re… Danny Mayer
- Re: [TICTOC] [ntpwg] security ID submitted for re… Greg Dowd