Re: [TICTOC] [ntpwg] security ID submitted for review
"David L. Mills" <mills@udel.edu> Wed, 07 August 2013 01:02 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 4644621F9D4A for <tictoc@ietfa.amsl.com>; Tue, 6 Aug 2013 18:02:17 -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 dxaB5fORV3G1 for <tictoc@ietfa.amsl.com>; Tue, 6 Aug 2013 18:02:11 -0700 (PDT)
Received: from mail.eecis.udel.edu (louie.udel.edu [128.4.40.12]) by ietfa.amsl.com (Postfix) with ESMTP id 4A39D21F9D38 for <tictoc@ietf.org>; Tue, 6 Aug 2013 18:02:10 -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 51D9A1071; Tue, 6 Aug 2013 21:01:50 -0400 (EDT)
Message-ID: <52019C7B.9070602@udel.edu>
Date: Wed, 07 Aug 2013 01:01:47 +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: Kurt Roeckx <kurt@roeckx.be>
References: <51FAC820.3090401@udel.edu> <20130803174008.GA17578@roeckx.be>
In-Reply-To: <20130803174008.GA17578@roeckx.be>
Content-Type: multipart/alternative; boundary="------------040201000803070007040309"
Cc: NTP Working Group <ntpwg@lists.ntp.org>, "tictoc@ietf.org" <tictoc@ietf.org>
Subject: Re: [TICTOC] [ntpwg] 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: Wed, 07 Aug 2013 01:02:17 -0000
Kurt, Thanks for your reply. As a window of history, the Autokey protocol was devised during several walks in Regents Park, London, in 1996. I thought the most significant hazzard was the replay of client messages requiring extensive server cryptographic computations. At that time, I did not think that a middle-man attack would be significant. Both of those assumptions are probably inadvisable today. One problem with Autokey is the assumption that secret keys for each client can be manufactured using packet header fields and a hash of a server private value. A middle-man can manipulate the header fields compromising the client private key. There does not seem to be a solution for this problem other than requiring server state. There are two problems with requiring a server state variable associated with each client. The first is how to reliably match the server state with the client packet. For public time servers with thousands of clients, the storage of something like a client certificate for each client could be prohibitive. The storage could be dynamically allocated as a field in the MRU list maintained in the current NTP implimentation; however, the MRU list for several hundred entries has a lifetime of only 15 seconds, at NIST, for example. In the current Autokey design, the MAC computation covers the header and all extension fields. However, the key used for the MAC computation in packets with extension fields is not private. Therefore, in a cut-and-paste attack, an intruder could mix and match extension fields and simply recalculate the MAC. RFC 5906 defines the extension field including the filestamp and timestamp. The filestamp was designed to reliably associate the cryptographic media with the current version, as it can be frequently changed. This might not be useful in current designs. The timestamp field was designed to detect replays requiring expensive cryptographic computations which could take up to a second. However, the "call gap" (minimum headway) provisions nicely deflect such attacks, so the timestamp field might not be useful in current designs. Lastly, in the current design, each extension field is separately signed at the time the data were constructed. In current designs the signature might be computed at the time of transmission. The more I think of it, the better I like a design where the existing MAC is replaced by a single extension field computed as the signature of the header. I previously suggested this for broadcast mode, but I think this could be useful in other modes as well. It would be hightly interesting to determine the overhead for such a signature using modern processors. An experiment could be designed for the current NTP implementation. It would consist of an adaptor routine that matches an OpenSSL signature routine to the authencrypt/authdecrypt interface routine. I would do this myself, but with my current vision condition, it would not be practical. For someone with knowledge of the NTP programming style, this would be an interesting weekend project. In theis proposed design a busy server could be presented with thousands of signed client requests, each requiring a signed server response. However, the server might ignore the client request signature on the expectation that the server response could be reliably determined. Actually, the NTP on-wire protocol is very good for this. As an aside, the protocol analysis and simulation described in the white paper at the NTP project page could be done for PTP as well. Dave Kurt Roeckx wrote: >On Thu, Aug 01, 2013 at 08:42:08PM +0000, David L. Mills wrote: > > >>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. >> >> > >The draft only seems to specify the the general idea of how it >should work and doesn't seem to go into detail how this should >work at the protocol level. I assume he first wants to know if >the solution is something that can work and that others see >as a good solution before he works out the details. > > > >>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. >> >> > >I'm not sure I understand your remark. As far as I know the >"cookie snatcher" you talk about is the normal "man in the middle" >attack. As I understand we would change the verification by >replacing it by the normal X.509 verification as done for instance >SSL/TLS. > >I assume you meant public key and note private key. > > > >>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. >> >> > >I've seen this cut-and-paste attack mentioned before, but I've >never really understood it. As I understand things, the MAC >is generated over the NTP + extensions. I don't see how you >can take the extension from 1 packet into an other and still >have a valid MAC. Or are you saying that you do something >with a packet even when it doesn't have a valid MAC? > > > >>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. >> >> > >I really don't understand how such a man in the middle attack >can work. Either the certificate + the chain validate, or they >don't. It is of course important to you check that the CommonName >in the certificate matches the server you're trying to reach, >and that the root CA is in your list of trusted CAs. But there >really isn't anything new or hard about this. > > > >>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. >> >> > >I think that in all cases where it's no problem to keep track of >all clients you should use the interleaved mode, and we can use >something like the Diffie-Hellman key agreement for those. > >But there clearly is also a need for servers that can't keep >the state of each client, and we need something else for that. >So maybe we need to define 2 ways of working. > > > >Kurt > > >
- [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