From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Fri Jun 3 06:03:25 2011 Return-Path: X-Original-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92250E066C for ; Fri, 3 Jun 2011 06:03:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qq3Zo6XuhhM8 for ; Fri, 3 Jun 2011 06:03:24 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [IPv6:2001:4f8:fff7:1::7]) by ietfa.amsl.com (Postfix) with ESMTP id 58176E065D for ; Fri, 3 Jun 2011 06:03:19 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id 8F53F86D77B for ; Fri, 3 Jun 2011 13:03:17 +0000 (UTC) X-Original-To: ntpwg@lists.ntp.org Delivered-To: ntpwg@lists.ntp.org Received: from mail1.ntp.org (mail1.ntp.org [IPv6:2001:4f8:fff7:1::5]) by lists.ntp.org (Postfix) with ESMTP id 07A0786D760; Fri, 3 Jun 2011 12:32:45 +0000 (UTC) Received: from [198.22.153.9] (helo=[10.60.111.83]) by mail1.ntp.org with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.75 (FreeBSD)) (envelope-from ) id 1QSTYF-000CG9-G1; Fri, 03 Jun 2011 12:32:44 +0000 Message-ID: <4DE8D4C6.4030101@ntp.org> Date: Fri, 03 Jun 2011 08:34:14 -0400 From: Danny Mayer User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: "David L. Mills" References: <4DE838E0.5070302@udel.edu> In-Reply-To: <4DE838E0.5070302@udel.edu> X-Enigmail-Version: 1.1.1 X-SA-Exim-Connect-IP: 198.22.153.9 X-SA-Exim-Rcpt-To: mills@udel.edu, dieter.sibold@ptb.de, s.roettger@tu-braunschweig.de, hackers@ntp.org, stephen.roettger@ptb.de, ntpwg@lists.ntp.org X-SA-Exim-Mail-From: mayer@ntp.org X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) Cc: NTP Working Group , stephen.roettger@ptb.de, dieter.sibold@ptb.de, hackers@ntp.org, =?ISO-8859-1?Q?Stephen_R=F6ttger?= Subject: Re: [ntpwg] [ntp:hackers] PTB: Doubt about the autokey protocol X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Working Group for Network Time Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Errors-To: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Dieter, There are several things going on here and I'd like to try to clarify them. I'm copying the NTP working group since it is more relevant to that list than hackers. 1) If you are using NTP you should be using at a minimum 3 separate sources of NTP packets. The NTP client uses the sources to decide which is providing the "best" (I don't want to discuss how NTP decides which is best here) source of time. NTP continually reexamines its sources and makes that decision regularly. If the client is not using at least 3 sources then they are not worrying about securing the time service. 2) A man-in-the-middle attack on autokey needs to intercept NTP Packets to EVERY server it is using which is a much harder proposition. Each such server will have its own keys that the middleman would need to manage. 3) I am not clear where the middleman gets its public key. It's not provided in the protocol and can only be obtained Out-of-band. The server provides keys, the client doesn't. Am I mistaken in this? 4) You say that your student was able to perform such an attack but was he able to do it without having any information about the servers keys? I'll have more to say when I understand this issue a little better. Danny On 6/2/2011 9:29 PM, David L. Mills wrote: > Dieter, > = > The problem I have with your scenario is how to convince the client that > the middleman client cookie is genuine. The server provides the client > cookie encrypted with the middleman key, but the middleman has to > encrypt the client cookie for the client using the client key. That > requires the response to be signed, but the middleman cannot encrypt the > signature without the server private key. > = > Here is another way this could be done. The middleman lives in a > compromised router on the same Ethernet as the client. It begins by > simply wiretapping the client cookie request, but allows the client > request/response to complete. It then repeats the request with its own > key and intercepts the response without continuing to the client. > Subsequently, it masquerades as the server and injects its own values > while observing the on-wire protocol rules. > = > It very well may be that the best approach to this and similar problems > is a suite of algorithms designed to verify the integrity of the router, > rather than further complicate the NTP protocol design. This might be a > topic for discussion on the hackers.ntp.org list. > = > I'm still not satisfied with the NTP security document. It was first > written five years ago in somewhat of a hurry as the RFC was submitted > for review. The document does not lie, but its wording is a bit loose. > The main thing that needs to be clarified is how the public values can > be protected against middleman attack. It needs to be tightened and I am > doing that. now. I will advise when it is ready for prime time. > = > Dave > = > dieter.sibold@ptb.de wrote: > = >> Dave, >> thanks for your last email. >> I agree that the usage of the autokey procedure is quite an obstacle >> for "normal" end users who just want to have the time from their >> national laboratory. But that is not our primary intention. Although >> we have quite a high access rate to out time servers the requests for >> signed time packets is quite small. Therefore, I believe that even if >> we provide authenticated time service to the public the usage of it >> would be quite small. Our intention is to investigate if NTP together >> with autokey provides an robust and secure authenticated time service >> for applications which depend on authenticated time information by >> requirements enforced by Germany's Verification Act. For this scenario >> the technical obstacles of autokey are not a major problem. >> >> Nonetheless I also agree that it would be nice if the configuration >> and usage would be easier. >> >> Thanks also for editing of the Security Analysis paper. At this point >> we still have some issues. >> >> At our first question regarding the security of autokey you wrote: >> >> = >> >>> Your analysis left out one crucial fact. The server reply to the cookie >>> request is signed by the server using its private key. The client, in >>> possession of the server public key, can verify the authenticity of the >>> reply. >>> = >> >> That is ok. But nonetheless, my colleague - Stephen - already >> performed a man-in-the-middle attack and he was able to compute a >> valid Message Authentication Code (MAC) for a servers time response. >> The attack works as follows: >> >> First of all the attacker (M) aims to obtain the client cookie C_C for >> the NTP-Client C. To this end the attacker M performs a >> man-in-the-middle attack in which he masquerades as NTP-Client C and >> send a cookie request to the NTP-Server S together with its public key >> P_M and the IP-address IP_C of NTP-Client C. In response M obtains the >> client cookie C_C from the server S, which is encrypted with the >> public key P_M of M and which is meant to be for the NTP-Client C. The >> attacker M is able to decrypt the client cookie C_C because it is >> encrypted with its public key P_M. Now M is in possession of the >> client cookie C_C and will store it. >> As of now the attacker M will change his role and will masquerade as >> NTP-Server S. When C sends a time request to the NTP-Server S it will >> be intercepted by M. Because M stored the client cookie C_C he is now >> able to verify the client request and to construct a timestamp >> response with a valid MAC. >> >> The problem arises because the NTP packet is bound to the client >> cookie C_C in which the client identity is only reflected by the >> clients IP-address IP_C. Therefore M is able to gain possession of the >> client cookie for C by means of a man-in-the-middle attack. >> >> >> In the moment we do not know if the attacker M is now able to change >> the time of the client C; but Stephen is investigating this question. >> >> Obviously we have to emphasize that this scenario is only possible if >> the attacker M is able to introduce himself into the communication >> line between client C and server S. >> >> With best regards >> Dieter >> ----------------------------------------------- >> Physikalisch-Technische Bundesanstalt >> Q.42 - Server Administration >> Bundesallee 100, D-38116 Braunschweig >> Tel: +49-531-592-84 20 >> E-Mail: dieter.sibold@ptb.de >> >> -----"David L. Mills" schrieb: ----- >> An: dieter.sibold@ptb.de >> Von: "David L. Mills" >> Datum: 30.05.2011 02:26AM >> Kopie: stenn@ntp.org >> Betreff: Re: PTB: Doubt about the autokey protocol >> >> Dieter,, >> >> It looks like the NTP Security Analysis needs some work. I have edited >> the page and brought it up to date. See especially sections 4 and 5. >> One issue is whether or not the identity scheme is necessary; for >> protection from middleman attack; I believe it is. However, there are >> some rough edges for a national laboratory deployment. A client needs >> to have the OpenSSL cryptographic library, as well as the Autokey >> configuration selected at build time. I'm not sure this will be >> acceptable on a widespread deployment. >> >> Another issue that needs to be resolved is whether the client needs to >> generate host or signature keys and whether a client certificate is >> necessary. If the client has no dependent clients, it does not need >> these things, but the current implementation requires them, even if >> they are not used. What needs here is some software grooming to ease >> the configuration and deployment on a national scale. This is not hard >> and could in principle be done by the Google software corps. >> >> Dave >> >> dieter.sibold@ptb.de wrote: >> >> = >> >>> Dear Prof. Mills and Mr. Stenn, >>> >>> I am writing this email because I have a couple of open questions >>> regarding the security of the autokey protocol. >>> >>> First, let me start to explain what we want to achieve by means of >>> autokey. >>> The PTB is Germany's national metrology institute. The dissemination >>> of time is one of our legal tasks. Since many years this is done via >>> long-wave transmitter DCF77 and since 1999 we also provide publicely >>> accessible NTP time servers for the dissemination of UTC(PTB) >>> successfully. >>> Within the scope of the new emerging smart grids in energy >>> distribution systems we are investigating if we could enhance our >>> time service in order to provide securely authenticated time to the >>> operators of energy distribution networks. To this end we >>> investigate if NTP together with the autokey-protocol is >>> cryptographically sufficient to meet the requirements which are >>> enforced by Germany's Verification Act. >>> >>> After the study of RFC5906 and recording of the communication >>> messages between NTP-client and NTP-server our student was able to >>> perform a man-in-the-middle attack. As a consequence he was able to >>> masquerade as server. You will find the procedure described in the >>> enclosed attachment. >>> If the described man-in-the-middle attack really breaks the >>> authentication we have to exclude the autokey-protocol from further >>> investigations. So I'd very much appreciate if you would be so kind >>> to comment the described attack. >>> >>> Thank you very much. With best regards >>> >>> Dr. D. Sibold >>> S. R=F6ttger >>> Dr. U. Grottker >>> >>> ----------------------------------------------- >>> Physikalisch-Technische Bundesanstalt >>> Q.42 - Server Administration >>> Bundesallee 100, D-38116 Braunschweig >>> Tel: +49-531-592-84 20 >>> E-Mail: dieter.sibold@ptb.de=3D >>> _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Fri Jun 3 12:24:20 2011 Return-Path: X-Original-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86959E07B7 for ; Fri, 3 Jun 2011 12:24:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FajlrgcyHLFD for ; Fri, 3 Jun 2011 12:24:18 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [IPv6:2001:4f8:fff7:1::7]) by ietfa.amsl.com (Postfix) with ESMTP id 29D5EE07D3 for ; Fri, 3 Jun 2011 12:24:18 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id 3DACE86D9F4 for ; Fri, 3 Jun 2011 19:24:16 +0000 (UTC) X-Original-To: ntpwg@lists.ntp.org Delivered-To: ntpwg@lists.ntp.org Received: from mail1.ntp.org (mail1.ntp.org [IPv6:2001:4f8:fff7:1::5]) by lists.ntp.org (Postfix) with ESMTP id 10F5B86D763 for ; Fri, 3 Jun 2011 18:55:52 +0000 (UTC) Received: from louie.udel.edu ([128.4.40.12] helo=mail.eecis.udel.edu) by mail1.ntp.org with esmtp (Exim 4.75 (FreeBSD)) (envelope-from ) id 1QSZWz-0001vT-T2 for ntpwg@lists.ntp.org; Fri, 03 Jun 2011 18:55:52 +0000 Received: from [192.168.1.3] (pool-74-109-121-175.phlapa.fios.verizon.net [74.109.121.175]) (Authenticated sender: mills@mail.eecis.udel.edu) by mail.eecis.udel.edu (Postfix) with ESMTP id 0ABDB1232; Fri, 3 Jun 2011 14:55:37 -0400 (EDT) Message-ID: <4DE92E29.7010901@udel.edu> Date: Fri, 03 Jun 2011 18:55:37 +0000 From: "David L. Mills" 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: Danny Mayer References: <4DE838E0.5070302@udel.edu> <4DE8D4C6.4030101@ntp.org> In-Reply-To: <4DE8D4C6.4030101@ntp.org> X-SA-Exim-Connect-IP: 128.4.40.12 X-SA-Exim-Rcpt-To: ntpwg@lists.ntp.org X-SA-Exim-Mail-From: mills@udel.edu X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) Cc: NTP Working Group , stephen.roettger@ptb.de, dieter.sibold@ptb.de, hackers@ntp.org, =?ISO-8859-1?Q?Stephen_R=F6ttger?= Subject: Re: [ntpwg] [ntp:hackers] PTB: Doubt about the autokey protocol X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Working Group for Network Time Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" Sender: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Errors-To: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Danny, You might have misinterpreted by reason for posting to this list. Dieter = is from the PTB, the German equivalent of NIST. His concern is not = necessarily on good client practice, but provable defense against a = middleman attack. This is one of two vulnerabilities that occur with = public key cryptography as applied to NTP. The first is when obtaining = client cookie from a server as I described. The second is with old duplicates in broadcast modes and in particular = an old duplicate of a autokeys values message. The problem occurs with = symmetric and public key cryptography, since an old duplicate cannot = easily be distinguished from a legitimate backward adjustment of the = system clock. The interesting aspect from an engineering point of view is that, while = symmetric key cryptography is in general immune to middleman threats, = public key cryptography, not just Autokey, is devilishly hard to avoid = middleman compromise. My hope in posting to this list is to stimulate = discussion on ways to fix the problem. There are two white papers addressing these issues, "Analysis and = Simulation of the NT On-Wire Protocol" = www.eecis.udel.edu/~mills/onwire.html and "NTP Security Analysis" = www.eecis.udel.edu/~mills/security.html. Your comments are inivited. Dave Danny Mayer wrote: >Dieter, > >There are several things going on here and I'd like to try to clarify >them. I'm copying the NTP working group since it is more relevant to >that list than hackers. > >1) If you are using NTP you should be using at a minimum 3 separate >sources of NTP packets. The NTP client uses the sources to decide which >is providing the "best" (I don't want to discuss how NTP decides which >is best here) source of time. NTP continually reexamines its sources and >makes that decision regularly. If the client is not using at least 3 >sources then they are not worrying about securing the time service. > >2) A man-in-the-middle attack on autokey needs to intercept NTP Packets >to EVERY server it is using which is a much harder proposition. Each >such server will have its own keys that the middleman would need to manage. > >3) I am not clear where the middleman gets its public key. It's not >provided in the protocol and can only be obtained Out-of-band. The >server provides keys, the client doesn't. Am I mistaken in this? > >4) You say that your student was able to perform such an attack but was >he able to do it without having any information about the servers keys? > >I'll have more to say when I understand this issue a little better. > >Danny > >On 6/2/2011 9:29 PM, David L. Mills wrote: > = > >>Dieter, >> >>The problem I have with your scenario is how to convince the client that >>the middleman client cookie is genuine. The server provides the client >>cookie encrypted with the middleman key, but the middleman has to >>encrypt the client cookie for the client using the client key. That >>requires the response to be signed, but the middleman cannot encrypt the >>signature without the server private key. >> >>Here is another way this could be done. The middleman lives in a >>compromised router on the same Ethernet as the client. It begins by >>simply wiretapping the client cookie request, but allows the client >>request/response to complete. It then repeats the request with its own >>key and intercepts the response without continuing to the client. >>Subsequently, it masquerades as the server and injects its own values >>while observing the on-wire protocol rules. >> >>It very well may be that the best approach to this and similar problems >>is a suite of algorithms designed to verify the integrity of the router, >>rather than further complicate the NTP protocol design. This might be a >>topic for discussion on the hackers.ntp.org list. >> >>I'm still not satisfied with the NTP security document. It was first >>written five years ago in somewhat of a hurry as the RFC was submitted >>for review. The document does not lie, but its wording is a bit loose. >>The main thing that needs to be clarified is how the public values can >>be protected against middleman attack. It needs to be tightened and I am >>doing that. now. I will advise when it is ready for prime time. >> >>Dave >> >>dieter.sibold@ptb.de wrote: >> >> = >> >>>Dave, >>>thanks for your last email. >>>I agree that the usage of the autokey procedure is quite an obstacle >>>for "normal" end users who just want to have the time from their >>>national laboratory. But that is not our primary intention. Although >>>we have quite a high access rate to out time servers the requests for >>>signed time packets is quite small. Therefore, I believe that even if >>>we provide authenticated time service to the public the usage of it >>>would be quite small. Our intention is to investigate if NTP together >>>with autokey provides an robust and secure authenticated time service >>>for applications which depend on authenticated time information by >>>requirements enforced by Germany's Verification Act. For this scenario >>>the technical obstacles of autokey are not a major problem. >>> >>>Nonetheless I also agree that it would be nice if the configuration >>>and usage would be easier. >>> >>>Thanks also for editing of the Security Analysis paper. At this point >>>we still have some issues. >>> >>>At our first question regarding the security of autokey you wrote: >>> >>> = >>> >>> = >>> >>>>Your analysis left out one crucial fact. The server reply to the cookie >>>>request is signed by the server using its private key. The client, in >>>>possession of the server public key, can verify the authenticity of the >>>>reply. >>>> = >>>> = >>>> >>>That is ok. But nonetheless, my colleague - Stephen - already >>>performed a man-in-the-middle attack and he was able to compute a >>>valid Message Authentication Code (MAC) for a servers time response. >>>The attack works as follows: >>> >>>First of all the attacker (M) aims to obtain the client cookie C_C for >>>the NTP-Client C. To this end the attacker M performs a >>>man-in-the-middle attack in which he masquerades as NTP-Client C and >>>send a cookie request to the NTP-Server S together with its public key >>>P_M and the IP-address IP_C of NTP-Client C. In response M obtains the >>>client cookie C_C from the server S, which is encrypted with the >>>public key P_M of M and which is meant to be for the NTP-Client C. The >>>attacker M is able to decrypt the client cookie C_C because it is >>>encrypted with its public key P_M. Now M is in possession of the >>>client cookie C_C and will store it. >>>As of now the attacker M will change his role and will masquerade as >>>NTP-Server S. When C sends a time request to the NTP-Server S it will >>>be intercepted by M. Because M stored the client cookie C_C he is now >>>able to verify the client request and to construct a timestamp >>>response with a valid MAC. >>> >>>The problem arises because the NTP packet is bound to the client >>>cookie C_C in which the client identity is only reflected by the >>>clients IP-address IP_C. Therefore M is able to gain possession of the >>>client cookie for C by means of a man-in-the-middle attack. >>> >>> >>>In the moment we do not know if the attacker M is now able to change >>>the time of the client C; but Stephen is investigating this question. >>> >>>Obviously we have to emphasize that this scenario is only possible if >>>the attacker M is able to introduce himself into the communication >>>line between client C and server S. >>> >>>With best regards >>>Dieter >>>----------------------------------------------- >>>Physikalisch-Technische Bundesanstalt >>>Q.42 - Server Administration >>>Bundesallee 100, D-38116 Braunschweig >>>Tel: +49-531-592-84 20 >>>E-Mail: dieter.sibold@ptb.de >>> >>>-----"David L. Mills" schrieb: ----- >>>An: dieter.sibold@ptb.de >>>Von: "David L. Mills" >>>Datum: 30.05.2011 02:26AM >>>Kopie: stenn@ntp.org >>>Betreff: Re: PTB: Doubt about the autokey protocol >>> >>>Dieter,, >>> >>>It looks like the NTP Security Analysis needs some work. I have edited >>>the page and brought it up to date. See especially sections 4 and 5. >>>One issue is whether or not the identity scheme is necessary; for >>>protection from middleman attack; I believe it is. However, there are >>>some rough edges for a national laboratory deployment. A client needs >>>to have the OpenSSL cryptographic library, as well as the Autokey >>>configuration selected at build time. I'm not sure this will be >>>acceptable on a widespread deployment. >>> >>>Another issue that needs to be resolved is whether the client needs to >>>generate host or signature keys and whether a client certificate is >>>necessary. If the client has no dependent clients, it does not need >>>these things, but the current implementation requires them, even if >>>they are not used. What needs here is some software grooming to ease >>>the configuration and deployment on a national scale. This is not hard >>>and could in principle be done by the Google software corps. >>> >>>Dave >>> >>>dieter.sibold@ptb.de wrote: >>> >>> = >>> >>> = >>> >>>>Dear Prof. Mills and Mr. Stenn, >>>> >>>>I am writing this email because I have a couple of open questions >>>>regarding the security of the autokey protocol. >>>> >>>>First, let me start to explain what we want to achieve by means of >>>>autokey. >>>>The PTB is Germany's national metrology institute. The dissemination >>>>of time is one of our legal tasks. Since many years this is done via >>>>long-wave transmitter DCF77 and since 1999 we also provide publicely >>>>accessible NTP time servers for the dissemination of UTC(PTB) >>>>successfully. >>>>Within the scope of the new emerging smart grids in energy >>>>distribution systems we are investigating if we could enhance our >>>>time service in order to provide securely authenticated time to the >>>>operators of energy distribution networks. To this end we >>>>investigate if NTP together with the autokey-protocol is >>>>cryptographically sufficient to meet the requirements which are >>>>enforced by Germany's Verification Act. >>>> >>>>After the study of RFC5906 and recording of the communication >>>>messages between NTP-client and NTP-server our student was able to >>>>perform a man-in-the-middle attack. As a consequence he was able to >>>>masquerade as server. You will find the procedure described in the >>>>enclosed attachment. >>>>If the described man-in-the-middle attack really breaks the >>>>authentication we have to exclude the autokey-protocol from further >>>>investigations. So I'd very much appreciate if you would be so kind >>>>to comment the described attack. >>>> >>>>Thank you very much. With best regards >>>> >>>>Dr. D. Sibold >>>>S. R=F6ttger >>>>Dr. U. Grottker >>>> >>>>----------------------------------------------- >>>>Physikalisch-Technische Bundesanstalt >>>>Q.42 - Server Administration >>>>Bundesallee 100, D-38116 Braunschweig >>>>Tel: +49-531-592-84 20 >>>>E-Mail: dieter.sibold@ptb.de=3D >>>> >>>> = >>>> _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Fri Jun 3 14:09:09 2011 Return-Path: X-Original-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F36B5E07DC for ; Fri, 3 Jun 2011 14:09:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uNGvAem4o0Nl for ; Fri, 3 Jun 2011 14:09:07 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [IPv6:2001:4f8:fff7:1::7]) by ietfa.amsl.com (Postfix) with ESMTP id 692ADE07D4 for ; Fri, 3 Jun 2011 14:09:06 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id 570E986D841 for ; Fri, 3 Jun 2011 21:09:05 +0000 (UTC) X-Original-To: ntpwg@lists.ntp.org Delivered-To: ntpwg@lists.ntp.org Received: from mail1.ntp.org (mail1.ntp.org [IPv6:2001:4f8:fff7:1::5]) by lists.ntp.org (Postfix) with ESMTP id E569286D763; Fri, 3 Jun 2011 20:43:04 +0000 (UTC) Received: from [198.22.153.9] (helo=[10.60.111.83]) by mail1.ntp.org with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.75 (FreeBSD)) (envelope-from ) id 1QSbCm-000Cg3-4k; Fri, 03 Jun 2011 20:43:03 +0000 Message-ID: <4DE947B3.20400@ntp.org> Date: Fri, 03 Jun 2011 16:44:35 -0400 From: Danny Mayer User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: "David L. Mills" References: <4DE838E0.5070302@udel.edu> <4DE8D4C6.4030101@ntp.org> <4DE92E29.7010901@udel.edu> In-Reply-To: <4DE92E29.7010901@udel.edu> X-Enigmail-Version: 1.1.1 X-SA-Exim-Connect-IP: 198.22.153.9 X-SA-Exim-Rcpt-To: mills@udel.edu, dieter.sibold@ptb.de, s.roettger@tu-braunschweig.de, hackers@ntp.org, stephen.roettger@ptb.de, ntpwg@lists.ntp.org X-SA-Exim-Mail-From: mayer@ntp.org X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) Cc: NTP Working Group , stephen.roettger@ptb.de, dieter.sibold@ptb.de, hackers@ntp.org, =?ISO-8859-1?Q?Stephen_R=F6ttger?= Subject: Re: [ntpwg] [ntp:hackers] PTB: Doubt about the autokey protocol X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Working Group for Network Time Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Errors-To: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Dave, No I don't think that I misinterpreted the reason. I understood about PTB. One of my points was that if you are going to be using autokey you are trying to ensure that you are getting good reliable time and therefore need to make sure that you are using more than one source and that you are using autokey for each one. Another point is that a backward adjustment, legitimate or not, will get ignored because the other sources are telling you that it is a falseticker. In such cases a falseticker would be required to restart the autorun dance from the beginning, or at least it should be doing that. There are several scenarios here: 1) the middleman acts just on one server, in which case the packets will get thrown out as it will be considered a falseticker; 2) the middleman acts for all servers and tries to fool the client into thinking it has valid time for all servers but then all of the servers will appear to be serving time with an almost identical set of timestamps in which case all servers will look the same and be suspiciously close to each other. As we know networks are wildly varying in their delays and the only way that such a middleman can do this is by being on the same subnet as the client which is a hard thing to accomplish. Failing that it would be very hard for a middleman to do this on multiple subnets. The middleman would also need to make sure that the packets did not reach the real server or the real server's response packets reach the client since the client will see the packets and start to discount the packets coming from what it thinks is one place and because the autokey dance values will not agree thereby causing the server to be marked as a falseticker. The part I'm struggling with is the client cookie and how did the middleman get hold of a private key for it to act as a substitute server. Danny On 6/3/2011 2:55 PM, David L. Mills wrote: > Danny, > = > You might have misinterpreted by reason for posting to this list. Dieter > is from the PTB, the German equivalent of NIST. His concern is not > necessarily on good client practice, but provable defense against a > middleman attack. This is one of two vulnerabilities that occur with > public key cryptography as applied to NTP. The first is when obtaining > client cookie from a server as I described. > = > The second is with old duplicates in broadcast modes and in particular > an old duplicate of a autokeys values message. The problem occurs with > symmetric and public key cryptography, since an old duplicate cannot > easily be distinguished from a legitimate backward adjustment of the > system clock. > = > The interesting aspect from an engineering point of view is that, while > symmetric key cryptography is in general immune to middleman threats, > public key cryptography, not just Autokey, is devilishly hard to avoid > middleman compromise. My hope in posting to this list is to stimulate > discussion on ways to fix the problem. > = > There are two white papers addressing these issues, "Analysis and > Simulation of the NT On-Wire Protocol" > www.eecis.udel.edu/~mills/onwire.html and "NTP Security Analysis" > www.eecis.udel.edu/~mills/security.html. Your comments are inivited. > = > Dave > = > Danny Mayer wrote: > = >> Dieter, >> >> There are several things going on here and I'd like to try to clarify >> them. I'm copying the NTP working group since it is more relevant to >> that list than hackers. >> >> 1) If you are using NTP you should be using at a minimum 3 separate >> sources of NTP packets. The NTP client uses the sources to decide which >> is providing the "best" (I don't want to discuss how NTP decides which >> is best here) source of time. NTP continually reexamines its sources and >> makes that decision regularly. If the client is not using at least 3 >> sources then they are not worrying about securing the time service. >> >> 2) A man-in-the-middle attack on autokey needs to intercept NTP Packets >> to EVERY server it is using which is a much harder proposition. Each >> such server will have its own keys that the middleman would need to >> manage. >> >> 3) I am not clear where the middleman gets its public key. It's not >> provided in the protocol and can only be obtained Out-of-band. The >> server provides keys, the client doesn't. Am I mistaken in this? >> >> 4) You say that your student was able to perform such an attack but was >> he able to do it without having any information about the servers keys? >> >> I'll have more to say when I understand this issue a little better. >> >> Danny >> >> On 6/2/2011 9:29 PM, David L. Mills wrote: >> = >> >>> Dieter, >>> >>> The problem I have with your scenario is how to convince the client that >>> the middleman client cookie is genuine. The server provides the client >>> cookie encrypted with the middleman key, but the middleman has to >>> encrypt the client cookie for the client using the client key. That >>> requires the response to be signed, but the middleman cannot encrypt the >>> signature without the server private key. >>> >>> Here is another way this could be done. The middleman lives in a >>> compromised router on the same Ethernet as the client. It begins by >>> simply wiretapping the client cookie request, but allows the client >>> request/response to complete. It then repeats the request with its own >>> key and intercepts the response without continuing to the client. >>> Subsequently, it masquerades as the server and injects its own values >>> while observing the on-wire protocol rules. >>> >>> It very well may be that the best approach to this and similar problems >>> is a suite of algorithms designed to verify the integrity of the router, >>> rather than further complicate the NTP protocol design. This might be a >>> topic for discussion on the hackers.ntp.org list. >>> >>> I'm still not satisfied with the NTP security document. It was first >>> written five years ago in somewhat of a hurry as the RFC was submitted >>> for review. The document does not lie, but its wording is a bit loose. >>> The main thing that needs to be clarified is how the public values can >>> be protected against middleman attack. It needs to be tightened and I am >>> doing that. now. I will advise when it is ready for prime time. >>> >>> Dave >>> >>> dieter.sibold@ptb.de wrote: >>> >>> = >>>> Dave, >>>> thanks for your last email. >>>> I agree that the usage of the autokey procedure is quite an obstacle >>>> for "normal" end users who just want to have the time from their >>>> national laboratory. But that is not our primary intention. Although >>>> we have quite a high access rate to out time servers the requests for >>>> signed time packets is quite small. Therefore, I believe that even if >>>> we provide authenticated time service to the public the usage of it >>>> would be quite small. Our intention is to investigate if NTP together >>>> with autokey provides an robust and secure authenticated time service >>>> for applications which depend on authenticated time information by >>>> requirements enforced by Germany's Verification Act. For this scenario >>>> the technical obstacles of autokey are not a major problem. >>>> >>>> Nonetheless I also agree that it would be nice if the configuration >>>> and usage would be easier. >>>> >>>> Thanks also for editing of the Security Analysis paper. At this point >>>> we still have some issues. >>>> >>>> At our first question regarding the security of autokey you wrote: >>>> >>>> >>>> >>>> = >>>>> Your analysis left out one crucial fact. The server reply to the >>>>> cookie >>>>> request is signed by the server using its private key. The client, in >>>>> possession of the server public key, can verify the authenticity of >>>>> the >>>>> reply. >>>>> = >>>>> = >>>> That is ok. But nonetheless, my colleague - Stephen - already >>>> performed a man-in-the-middle attack and he was able to compute a >>>> valid Message Authentication Code (MAC) for a servers time response. >>>> The attack works as follows: >>>> >>>> First of all the attacker (M) aims to obtain the client cookie C_C for >>>> the NTP-Client C. To this end the attacker M performs a >>>> man-in-the-middle attack in which he masquerades as NTP-Client C and >>>> send a cookie request to the NTP-Server S together with its public key >>>> P_M and the IP-address IP_C of NTP-Client C. In response M obtains the >>>> client cookie C_C from the server S, which is encrypted with the >>>> public key P_M of M and which is meant to be for the NTP-Client C. The >>>> attacker M is able to decrypt the client cookie C_C because it is >>>> encrypted with its public key P_M. Now M is in possession of the >>>> client cookie C_C and will store it. >>>> As of now the attacker M will change his role and will masquerade as >>>> NTP-Server S. When C sends a time request to the NTP-Server S it will >>>> be intercepted by M. Because M stored the client cookie C_C he is now >>>> able to verify the client request and to construct a timestamp >>>> response with a valid MAC. >>>> >>>> The problem arises because the NTP packet is bound to the client >>>> cookie C_C in which the client identity is only reflected by the >>>> clients IP-address IP_C. Therefore M is able to gain possession of the >>>> client cookie for C by means of a man-in-the-middle attack. >>>> >>>> >>>> In the moment we do not know if the attacker M is now able to change >>>> the time of the client C; but Stephen is investigating this question. >>>> >>>> Obviously we have to emphasize that this scenario is only possible if >>>> the attacker M is able to introduce himself into the communication >>>> line between client C and server S. >>>> >>>> With best regards >>>> Dieter >>>> ----------------------------------------------- >>>> Physikalisch-Technische Bundesanstalt >>>> Q.42 - Server Administration >>>> Bundesallee 100, D-38116 Braunschweig >>>> Tel: +49-531-592-84 20 >>>> E-Mail: dieter.sibold@ptb.de >>>> >>>> -----"David L. Mills" schrieb: ----- >>>> An: dieter.sibold@ptb.de >>>> Von: "David L. Mills" >>>> Datum: 30.05.2011 02:26AM >>>> Kopie: stenn@ntp.org >>>> Betreff: Re: PTB: Doubt about the autokey protocol >>>> >>>> Dieter,, >>>> >>>> It looks like the NTP Security Analysis needs some work. I have edited >>>> the page and brought it up to date. See especially sections 4 and 5. >>>> One issue is whether or not the identity scheme is necessary; for >>>> protection from middleman attack; I believe it is. However, there are >>>> some rough edges for a national laboratory deployment. A client needs >>>> to have the OpenSSL cryptographic library, as well as the Autokey >>>> configuration selected at build time. I'm not sure this will be >>>> acceptable on a widespread deployment. >>>> >>>> Another issue that needs to be resolved is whether the client needs to >>>> generate host or signature keys and whether a client certificate is >>>> necessary. If the client has no dependent clients, it does not need >>>> these things, but the current implementation requires them, even if >>>> they are not used. What needs here is some software grooming to ease >>>> the configuration and deployment on a national scale. This is not hard >>>> and could in principle be done by the Google software corps. >>>> >>>> Dave >>>> >>>> dieter.sibold@ptb.de wrote: >>>> >>>> >>>> >>>> = >>>>> Dear Prof. Mills and Mr. Stenn, >>>>> >>>>> I am writing this email because I have a couple of open questions >>>>> regarding the security of the autokey protocol. >>>>> >>>>> First, let me start to explain what we want to achieve by means of >>>>> autokey. >>>>> The PTB is Germany's national metrology institute. The dissemination >>>>> of time is one of our legal tasks. Since many years this is done via >>>>> long-wave transmitter DCF77 and since 1999 we also provide publicely >>>>> accessible NTP time servers for the dissemination of UTC(PTB) >>>>> successfully. >>>>> Within the scope of the new emerging smart grids in energy >>>>> distribution systems we are investigating if we could enhance our >>>>> time service in order to provide securely authenticated time to the >>>>> operators of energy distribution networks. To this end we >>>>> investigate if NTP together with the autokey-protocol is >>>>> cryptographically sufficient to meet the requirements which are >>>>> enforced by Germany's Verification Act. >>>>> >>>>> After the study of RFC5906 and recording of the communication >>>>> messages between NTP-client and NTP-server our student was able to >>>>> perform a man-in-the-middle attack. As a consequence he was able to >>>>> masquerade as server. You will find the procedure described in the >>>>> enclosed attachment. >>>>> If the described man-in-the-middle attack really breaks the >>>>> authentication we have to exclude the autokey-protocol from further >>>>> investigations. So I'd very much appreciate if you would be so kind >>>>> to comment the described attack. >>>>> >>>>> Thank you very much. With best regards >>>>> >>>>> Dr. D. Sibold >>>>> S. R=F6ttger >>>>> Dr. U. Grottker >>>>> >>>>> ----------------------------------------------- >>>>> Physikalisch-Technische Bundesanstalt >>>>> Q.42 - Server Administration >>>>> Bundesallee 100, D-38116 Braunschweig >>>>> Tel: +49-531-592-84 20 >>>>> E-Mail: dieter.sibold@ptb.de=3D >>>>> >>>>> = > = > = > = _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Fri Jun 3 22:49:15 2011 Return-Path: X-Original-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBE2FE0674 for ; Fri, 3 Jun 2011 22:49:15 -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=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U+V2SX4jH3zF for ; Fri, 3 Jun 2011 22:49:13 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [IPv6:2001:4f8:fff7:1::7]) by ietfa.amsl.com (Postfix) with ESMTP id E605AE0690 for ; Fri, 3 Jun 2011 22:49:12 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id 7E6BD86D76D for ; Sat, 4 Jun 2011 05:49:11 +0000 (UTC) X-Original-To: ntpwg@lists.ntp.org Delivered-To: ntpwg@lists.ntp.org Received: from mail1.ntp.org (mail1.ntp.org [IPv6:2001:4f8:fff7:1::5]) by lists.ntp.org (Postfix) with ESMTP id A98F286D41E for ; Sat, 4 Jun 2011 04:27:45 +0000 (UTC) Received: from louie.udel.edu ([128.4.40.12] helo=mail.eecis.udel.edu) by mail1.ntp.org with esmtp (Exim 4.75 (FreeBSD)) (envelope-from ) id 1QSiSR-000FS4-QN for ntpwg@lists.ntp.org; Sat, 04 Jun 2011 04:27:45 +0000 Received: from [192.168.1.3] (pool-74-109-121-175.phlapa.fios.verizon.net [74.109.121.175]) (Authenticated sender: mills@mail.eecis.udel.edu) by mail.eecis.udel.edu (Postfix) with ESMTP id C8AE596D; Sat, 4 Jun 2011 00:27:30 -0400 (EDT) Message-ID: <4DE9B433.1060905@udel.edu> Date: Sat, 04 Jun 2011 04:27:31 +0000 From: "David L. Mills" 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: Danny Mayer References: <4DE838E0.5070302@udel.edu> <4DE8D4C6.4030101@ntp.org> <4DE92E29.7010901@udel.edu> <4DE947B3.20400@ntp.org> In-Reply-To: <4DE947B3.20400@ntp.org> X-SA-Exim-Connect-IP: 128.4.40.12 X-SA-Exim-Rcpt-To: ntpwg@lists.ntp.org X-SA-Exim-Mail-From: mills@udel.edu X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) Cc: NTP Working Group , stephen.roettger@ptb.de, dieter.sibold@ptb.de, hackers@ntp.org, =?ISO-8859-1?Q?Stephen_R=F6ttger?= Subject: Re: [ntpwg] [ntp:hackers] PTB: Doubt about the autokey protocol X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Working Group for Network Time Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============6429861264645486158==" Sender: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Errors-To: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org This is a multi-part message in MIME format. --===============6429861264645486158== Content-Type: multipart/alternative; boundary="------------030909030006030903070000" This is a multi-part message in MIME format. --------------030909030006030903070000 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Danny, I'm not disputing what you said, but you are missing the point. This is=20 a very technical scenario in a very narrow sense. Assuming a middleman=20 can hack into either a server or client network router, the attack I=20 described is possible. The technical issue is how to warp the protocol=20 so this is not possible. This is independent on whether additional=20 means, such as the NTP mitigation algorithms, are available. Dave Danny Mayer wrote: >Dave, > >No I don't think that I misinterpreted the reason. I understood about PT= B. > >One of my points was that if you are going to be using autokey you are >trying to ensure that you are getting good reliable time and therefore >need to make sure that you are using more than one source and that you >are using autokey for each one. > >Another point is that a backward adjustment, legitimate or not, will get >ignored because the other sources are telling you that it is a >falseticker. In such cases a falseticker would be required to restart >the autorun dance from the beginning, or at least it should be doing >that. There are several scenarios here: > >1) the middleman acts just on one server, in which case the packets will >get thrown out as it will be considered a falseticker; > >2) the middleman acts for all servers and tries to fool the client into >thinking it has valid time for all servers but then all of the servers >will appear to be serving time with an almost identical set of >timestamps in which case all servers will look the same and be >suspiciously close to each other. As we know networks are wildly varying >in their delays and the only way that such a middleman can do this is by >being on the same subnet as the client which is a hard thing to >accomplish. Failing that it would be very hard for a middleman to do >this on multiple subnets. The middleman would also need to make sure >that the packets did not reach the real server or the real server's >response packets reach the client since the client will see the packets >and start to discount the packets coming from what it thinks is one >place and because the autokey dance values will not agree thereby >causing the server to be marked as a falseticker. > >The part I'm struggling with is the client cookie and how did the >middleman get hold of a private key for it to act as a substitute server= . > >Danny > >On 6/3/2011 2:55 PM, David L. Mills wrote: > =20 > >>Danny, >> >>You might have misinterpreted by reason for posting to this list. Diete= r >>is from the PTB, the German equivalent of NIST. His concern is not >>necessarily on good client practice, but provable defense against a >>middleman attack. This is one of two vulnerabilities that occur with >>public key cryptography as applied to NTP. The first is when obtaining >>client cookie from a server as I described. >> >>The second is with old duplicates in broadcast modes and in particular >>an old duplicate of a autokeys values message. The problem occurs with >>symmetric and public key cryptography, since an old duplicate cannot >>easily be distinguished from a legitimate backward adjustment of the >>system clock. >> >>The interesting aspect from an engineering point of view is that, while >>symmetric key cryptography is in general immune to middleman threats, >>public key cryptography, not just Autokey, is devilishly hard to avoid >>middleman compromise. My hope in posting to this list is to stimulate >>discussion on ways to fix the problem. >> >>There are two white papers addressing these issues, "Analysis and >>Simulation of the NT On-Wire Protocol" >>www.eecis.udel.edu/~mills/onwire.html and "NTP Security Analysis" >>www.eecis.udel.edu/~mills/security.html. Your comments are inivited. >> >>Dave >> >>Danny Mayer wrote: >> >> =20 >> >>>Dieter, >>> >>>There are several things going on here and I'd like to try to clarify >>>them. I'm copying the NTP working group since it is more relevant to >>>that list than hackers. >>> >>>1) If you are using NTP you should be using at a minimum 3 separate >>>sources of NTP packets. The NTP client uses the sources to decide whic= h >>>is providing the "best" (I don't want to discuss how NTP decides which >>>is best here) source of time. NTP continually reexamines its sources a= nd >>>makes that decision regularly. If the client is not using at least 3 >>>sources then they are not worrying about securing the time service. >>> >>>2) A man-in-the-middle attack on autokey needs to intercept NTP Packet= s >>>to EVERY server it is using which is a much harder proposition. Each >>>such server will have its own keys that the middleman would need to >>>manage. >>> >>>3) I am not clear where the middleman gets its public key. It's not >>>provided in the protocol and can only be obtained Out-of-band. The >>>server provides keys, the client doesn't. Am I mistaken in this? >>> >>>4) You say that your student was able to perform such an attack but wa= s >>>he able to do it without having any information about the servers keys= ? >>> >>>I'll have more to say when I understand this issue a little better. >>> >>>Danny >>> >>>On 6/2/2011 9:29 PM, David L. Mills wrote: >>>=20 >>> >>> =20 >>> >>>>Dieter, >>>> >>>>The problem I have with your scenario is how to convince the client t= hat >>>>the middleman client cookie is genuine. The server provides the clien= t >>>>cookie encrypted with the middleman key, but the middleman has to >>>>encrypt the client cookie for the client using the client key. That >>>>requires the response to be signed, but the middleman cannot encrypt = the >>>>signature without the server private key. >>>> >>>>Here is another way this could be done. The middleman lives in a >>>>compromised router on the same Ethernet as the client. It begins by >>>>simply wiretapping the client cookie request, but allows the client >>>>request/response to complete. It then repeats the request with its o= wn >>>>key and intercepts the response without continuing to the client. >>>>Subsequently, it masquerades as the server and injects its own values >>>>while observing the on-wire protocol rules. >>>> >>>>It very well may be that the best approach to this and similar probl= ems >>>>is a suite of algorithms designed to verify the integrity of the rout= er, >>>>rather than further complicate the NTP protocol design. This might be= a >>>>topic for discussion on the hackers.ntp.org list. >>>> >>>>I'm still not satisfied with the NTP security document. It was first >>>>written five years ago in somewhat of a hurry as the RFC was submitte= d >>>>for review. The document does not lie, but its wording is a bit loose= . >>>>The main thing that needs to be clarified is how the public values ca= n >>>>be protected against middleman attack. It needs to be tightened and I= am >>>>doing that. now. I will advise when it is ready for prime time. >>>> >>>>Dave >>>> >>>>dieter.sibold@ptb.de wrote: >>>> >>>> =20 >>>> =20 >>>> >>>>>Dave, >>>>>thanks for your last email. >>>>>I agree that the usage of the autokey procedure is quite an obstacle >>>>>for "normal" end users who just want to have the time from their >>>>>national laboratory. But that is not our primary intention. Although >>>>>we have quite a high access rate to out time servers the requests fo= r >>>>>signed time packets is quite small. Therefore, I believe that even i= f >>>>>we provide authenticated time service to the public the usage of it >>>>>would be quite small. Our intention is to investigate if NTP togethe= r >>>>>with autokey provides an robust and secure authenticated time servic= e >>>>>for applications which depend on authenticated time information by >>>>>requirements enforced by Germany's Verification Act. For this scenar= io >>>>>the technical obstacles of autokey are not a major problem. >>>>> >>>>>Nonetheless I also agree that it would be nice if the configuration >>>>>and usage would be easier. >>>>> >>>>>Thanks also for editing of the Security Analysis paper. At this poin= t >>>>>we still have some issues. >>>>> >>>>>At our first question regarding the security of autokey you wrote: >>>>> >>>>> >>>>> >>>>> =20 >>>>> =20 >>>>> >>>>>>Your analysis left out one crucial fact. The server reply to the >>>>>>cookie >>>>>>request is signed by the server using its private key. The client, = in >>>>>>possession of the server public key, can verify the authenticity of >>>>>>the >>>>>>reply. >>>>>>=20 >>>>>> =20 >>>>>> =20 >>>>>> >>>>>That is ok. But nonetheless, my colleague - Stephen - already >>>>>performed a man-in-the-middle attack and he was able to compute a >>>>>valid Message Authentication Code (MAC) for a servers time response. >>>>>The attack works as follows: >>>>> >>>>>First of all the attacker (M) aims to obtain the client cookie C_C f= or >>>>>the NTP-Client C. To this end the attacker M performs a >>>>>man-in-the-middle attack in which he masquerades as NTP-Client C and >>>>>send a cookie request to the NTP-Server S together with its public k= ey >>>>>P_M and the IP-address IP_C of NTP-Client C. In response M obtains t= he >>>>>client cookie C_C from the server S, which is encrypted with the >>>>>public key P_M of M and which is meant to be for the NTP-Client C. T= he >>>>>attacker M is able to decrypt the client cookie C_C because it is >>>>>encrypted with its public key P_M. Now M is in possession of the >>>>>client cookie C_C and will store it. >>>>>As of now the attacker M will change his role and will masquerade as >>>>>NTP-Server S. When C sends a time request to the NTP-Server S it wil= l >>>>>be intercepted by M. Because M stored the client cookie C_C he is no= w >>>>>able to verify the client request and to construct a timestamp >>>>>response with a valid MAC. >>>>> >>>>>The problem arises because the NTP packet is bound to the client >>>>>cookie C_C in which the client identity is only reflected by the >>>>>clients IP-address IP_C. Therefore M is able to gain possession of t= he >>>>>client cookie for C by means of a man-in-the-middle attack. >>>>> >>>>> >>>>>In the moment we do not know if the attacker M is now able to change >>>>>the time of the client C; but Stephen is investigating this question= . >>>>> >>>>>Obviously we have to emphasize that this scenario is only possible i= f >>>>>the attacker M is able to introduce himself into the communication >>>>>line between client C and server S. >>>>> >>>>>With best regards >>>>>Dieter >>>>>----------------------------------------------- >>>>>Physikalisch-Technische Bundesanstalt >>>>>Q.42 - Server Administration >>>>>Bundesallee 100, D-38116 Braunschweig >>>>>Tel: +49-531-592-84 20 >>>>>E-Mail: dieter.sibold@ptb.de >>>>> >>>>>-----"David L. Mills" schrieb: ----- >>>>>An: dieter.sibold@ptb.de >>>>>Von: "David L. Mills" >>>>>Datum: 30.05.2011 02:26AM >>>>>Kopie: stenn@ntp.org >>>>>Betreff: Re: PTB: Doubt about the autokey protocol >>>>> >>>>>Dieter,, >>>>> >>>>>It looks like the NTP Security Analysis needs some work. I have edit= ed >>>>>the page and brought it up to date. See especially sections 4 and 5. >>>>>One issue is whether or not the identity scheme is necessary; for >>>>>protection from middleman attack; I believe it is. However, there ar= e >>>>>some rough edges for a national laboratory deployment. A client need= s >>>>>to have the OpenSSL cryptographic library, as well as the Autokey >>>>>configuration selected at build time. I'm not sure this will be >>>>>acceptable on a widespread deployment. >>>>> >>>>>Another issue that needs to be resolved is whether the client needs = to >>>>>generate host or signature keys and whether a client certificate is >>>>>necessary. If the client has no dependent clients, it does not need >>>>>these things, but the current implementation requires them, even if >>>>>they are not used. What needs here is some software grooming to ease >>>>>the configuration and deployment on a national scale. This is not ha= rd >>>>>and could in principle be done by the Google software corps. >>>>> >>>>>Dave >>>>> >>>>>dieter.sibold@ptb.de wrote: >>>>> >>>>> >>>>> >>>>> =20 >>>>> =20 >>>>> >>>>>>Dear Prof. Mills and Mr. Stenn, >>>>>> >>>>>>I am writing this email because I have a couple of open questions >>>>>>regarding the security of the autokey protocol. >>>>>> >>>>>>First, let me start to explain what we want to achieve by means of >>>>>>autokey. >>>>>>The PTB is Germany's national metrology institute. The disseminatio= n >>>>>>of time is one of our legal tasks. Since many years this is done v= ia >>>>>>long-wave transmitter DCF77 and since 1999 we also provide publicel= y >>>>>>accessible NTP time servers for the dissemination of UTC(PTB) >>>>>>successfully. >>>>>>Within the scope of the new emerging smart grids in energy >>>>>>distribution systems we are investigating if we could enhance our >>>>>>time service in order to provide securely authenticated time to t= he >>>>>>operators of energy distribution networks. To this end we >>>>>>investigate if NTP together with the autokey-protocol is >>>>>>cryptographically sufficient to meet the requirements which are >>>>>>enforced by Germany's Verification Act. >>>>>> >>>>>>After the study of RFC5906 and recording of the communication >>>>>>messages between NTP-client and NTP-server our student was able to >>>>>>perform a man-in-the-middle attack. As a consequence he was able to >>>>>>masquerade as server. You will find the procedure described in th= e >>>>>>enclosed attachment. >>>>>>If the described man-in-the-middle attack really breaks the >>>>>>authentication we have to exclude the autokey-protocol from further >>>>>>investigations. So I'd very much appreciate if you would be so kind >>>>>>to comment the described attack. >>>>>> >>>>>>Thank you very much. With best regards >>>>>> >>>>>>Dr. D. Sibold >>>>>>S. R=F6ttger >>>>>>Dr. U. Grottker >>>>>> >>>>>>----------------------------------------------- >>>>>>Physikalisch-Technische Bundesanstalt >>>>>>Q.42 - Server Administration >>>>>>Bundesallee 100, D-38116 Braunschweig >>>>>>Tel: +49-531-592-84 20 >>>>>>E-Mail: dieter.sibold@ptb.de=3D >>>>>> >>>>>> =20 >>>>>> =20 >>>>>> >> >> =20 >> > > =20 > --------------030909030006030903070000 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Danny,

I'm not disputing what you said, but you are missing the point. This is a very technical scenario in a very narrow sense. Assuming a middleman can hack into either a server or client network router, the attack I described is possible. The technical issue is how to warp the protocol so this is not possible. This is independent on whether additional means, such as the NTP mitigation algorithms, are available.

Dave

Danny Mayer wrote: 
Dave,

No I don't think that I misinterpreted the reason. I understood about PTB.

One of my points was that if you are going to be using autokey you are
trying to ensure that you are getting good reliable time and therefore
need to make sure that you are using more than one source and that you
are using autokey for each one.

Another point is that a backward adjustment, legitimate or not, will get
ignored because the other sources are telling you that it is a
falseticker. In such cases a falseticker would be required to restart
the autorun dance from the beginning, or at least it should be doing
that. There are several scenarios here:

1) the middleman acts just on one server, in which case the packets will
get thrown out as it will be considered a falseticker;

2) the middleman acts for all servers and tries to fool the client into
thinking it has valid time for all servers but then all of the servers
will appear to be serving time with an almost identical set of
timestamps in which case all servers will look the same and be
suspiciously close to each other. As we know networks are wildly varying
in their delays and the only way that such a middleman can do this is by
being on the same subnet as the client which is a hard thing to
accomplish. Failing that it would be very hard for a middleman to do
this on multiple subnets. The middleman would also need to make sure
that the packets did not reach the real server or the real server's
response packets reach the client since the client will see the packets
and start to discount the packets coming from what it thinks is one
place and because the autokey dance values will not agree thereby
causing the server to be marked as a falseticker.

The part I'm struggling with is the client cookie and how did the
middleman get hold of a private key for it to act as a substitute server.

Danny

On 6/3/2011 2:55 PM, David L. Mills wrote:
  
Danny,

You might have misinterpreted by reason for posting to this list. Dieter
is from the PTB, the German equivalent of NIST. His concern is not
necessarily on good client practice, but provable defense against a
middleman attack. This is one of two vulnerabilities that occur with
public key cryptography as applied to NTP. The first is when obtaining
client cookie from a server as I described.

The second is with old duplicates in broadcast modes and in particular
an old duplicate of a autokeys values message. The problem occurs with
symmetric and public key cryptography, since an old duplicate cannot
easily be distinguished from a legitimate backward adjustment of the
system clock.

The interesting aspect from an engineering point of view is that, while
symmetric key cryptography is in general immune to middleman threats,
public key cryptography, not just Autokey, is devilishly hard to avoid
middleman compromise. My hope in posting to this list is to stimulate
discussion on ways to fix the problem.

There are two white papers addressing these issues, "Analysis and
Simulation of the NT On-Wire Protocol"
www.eecis.udel.edu/~mills/onwire.html and "NTP Security Analysis"
www.eecis.udel.edu/~mills/security.html. Your comments are inivited.

Dave

Danny Mayer wrote:

    
Dieter,

There are several things going on here and I'd like to try to clarify
them. I'm copying the NTP working group since it is more relevant to
that list than hackers.

1) If you are using NTP you should be using at a minimum 3 separate
sources of NTP packets. The NTP client uses the sources to decide which
is providing the "best" (I don't want to discuss how NTP decides which
is best here) source of time. NTP continually reexamines its sources and
makes that decision regularly. If the client is not using at least 3
sources then they are not worrying about securing the time service.

2) A man-in-the-middle attack on autokey needs to intercept NTP Packets
to EVERY server it is using which is a much harder proposition. Each
such server will have its own keys that the middleman would need to
manage.

3) I am not clear where the middleman gets its public key. It's not
provided in the protocol and can only be obtained Out-of-band. The
server provides keys, the client doesn't. Am I mistaken in this?

4) You say that your student was able to perform such an attack but was
he able to do it without having any information about the servers keys?

I'll have more to say when I understand this issue a little better.

Danny

On 6/2/2011 9:29 PM, David L. Mills wrote:
 

      
Dieter,

The problem I have with your scenario is how to convince the client that
the middleman client cookie is genuine. The server provides the client
cookie encrypted with the middleman key, but the middleman has to
encrypt the client cookie for the client using the client key. That
requires the response to be signed, but the middleman cannot encrypt the
signature without the server private key.

Here is another way this could be done. The middleman lives in a
compromised router on the same Ethernet as the client. It begins by
simply wiretapping the client cookie request, but allows the client
request/response to complete. It then repeats the request  with its own
key and intercepts the response without continuing to the client.
Subsequently, it masquerades as the server and injects its own values
while observing the on-wire protocol rules.

It very well may be that the best  approach to this and similar problems
is a suite of algorithms designed to verify the integrity of the router,
rather than further complicate the NTP protocol design. This might be a
topic for discussion on the hackers.ntp.org list.

I'm still not satisfied with the NTP security document. It was first
written five years ago in somewhat of a hurry as the RFC was submitted
for review. The document does not lie, but its wording is a bit loose.
The main thing that needs to be clarified is how the public values can
be protected against middleman attack. It needs to be tightened and I am
doing that. now. I will advise when it is ready for prime time.

Dave

dieter.sibold@ptb.de wrote:

  
        
Dave,
thanks for your last email.
I agree that the usage of the autokey procedure is quite an obstacle
for "normal" end users who just want to have the time from their
national laboratory. But that is not our primary intention. Although
we have quite a high access rate to out time servers the requests for
signed time packets is quite small. Therefore, I believe that even if
we provide authenticated time service to the public the usage of it
would be quite small. Our intention is to investigate if NTP together
with autokey provides an robust and secure authenticated time service
for applications which depend on authenticated time information by
requirements enforced by Germany's Verification Act. For this scenario
the technical obstacles of autokey are not a major problem.

Nonetheless I also agree that it would be nice if the configuration
and usage would be easier.

Thanks also for editing of the Security Analysis paper. At this point
we still have some issues.

At our first question regarding the security of autokey you wrote:



    
          
Your analysis left out one crucial fact. The server reply to the
cookie
request is signed by the server using its private key. The client, in
possession of the server public key, can verify the authenticity of
the
reply.
 
      
            
That is ok. But nonetheless, my colleague - Stephen - already
performed a man-in-the-middle attack and he was able to compute a
valid Message Authentication Code (MAC) for a servers time response.
The attack works as follows:

First of all the attacker (M) aims to obtain the client cookie C_C for
the NTP-Client C. To this end the attacker M performs a
man-in-the-middle attack in which he masquerades as NTP-Client C and
send a cookie request to the NTP-Server S together with its public key
P_M and the IP-address IP_C of NTP-Client C. In response M obtains the
client cookie C_C from the server S, which is encrypted with the
public key P_M of M and which is meant to be for the NTP-Client C. The
attacker M is able to decrypt the client cookie C_C because it is
encrypted with its public key P_M. Now M is in possession of the
client cookie C_C and will store it.
As of now the attacker M will change his role and will masquerade as
NTP-Server S. When C sends a time request to the NTP-Server S it will
be intercepted by M. Because M stored the client cookie C_C he is now
able to verify the client request and to construct a timestamp
response with a valid MAC.

The problem arises because the NTP packet is bound to the client
cookie C_C in which the client identity is only reflected by the
clients IP-address IP_C. Therefore M is able to gain possession of the
client cookie for C by means of a man-in-the-middle attack.


In the moment we do not know if the attacker M is now able to change
the time of the client C; but Stephen is investigating this question.

Obviously we have to emphasize that this scenario is only possible if
the attacker M is able to introduce himself into the communication
line between client C and server S.

With best regards
Dieter
-----------------------------------------------
Physikalisch-Technische Bundesanstalt
Q.42 - Server Administration
Bundesallee 100, D-38116 Braunschweig
Tel: +49-531-592-84 20
E-Mail: dieter.sibold@ptb.de

-----"David L. Mills" <mills@udel.edu> schrieb: -----
An: dieter.sibold@ptb.de
Von: "David L. Mills" <mills@udel.edu>
Datum: 30.05.2011 02:26AM
Kopie: stenn@ntp.org
Betreff: Re: PTB: Doubt about the autokey protocol

Dieter,,

It looks like the NTP Security Analysis needs some work. I have edited
the page and brought it up to date. See especially sections 4 and 5.
One issue is whether or not the identity scheme is necessary; for
protection from middleman attack; I believe it is. However, there are
some rough edges for a national laboratory deployment. A client needs
to have the OpenSSL cryptographic library, as well as the Autokey
configuration selected at build time. I'm not sure this will be
acceptable on a widespread deployment.

Another issue that needs to be resolved is whether the client needs to
generate host or signature keys and whether a client certificate is
necessary. If the client has no dependent clients, it does not need
these things, but the current implementation requires them, even if
they are not used. What needs here is some software grooming to ease
the configuration and deployment on a national scale. This is not hard
and could in principle be done by the Google software corps.

Dave

dieter.sibold@ptb.de wrote:



    
          
Dear Prof. Mills and Mr. Stenn,

I am writing this email because I have a couple of open questions
regarding the security of the autokey protocol.

First, let me start to explain what we want to achieve by means of
autokey.
The PTB is Germany's national metrology institute. The dissemination
of  time is one of our legal tasks. Since many years this is done via
long-wave transmitter DCF77 and since 1999 we also provide publicely
accessible NTP time servers for the dissemination of UTC(PTB)
successfully.
Within the scope of the new emerging smart grids in energy
distribution systems we are investigating if we could enhance our
time service  in order to provide securely  authenticated time to the
operators of energy distribution networks.  To this end we
investigate if NTP together with the autokey-protocol is
cryptographically sufficient to meet the requirements which are
enforced by Germany's Verification Act.

After the study of RFC5906 and recording of the communication
messages between NTP-client and NTP-server our student was able to
perform a man-in-the-middle attack. As a consequence he was able to
masquerade as server. You will find the  procedure  described in the
enclosed attachment.
If the described man-in-the-middle attack really breaks the
authentication we have to exclude the autokey-protocol from further
investigations. So I'd very much appreciate if you would be so kind
to comment the described attack.

Thank you very much. With best regards

Dr. D. Sibold
S. Röttger
Dr. U. Grottker

-----------------------------------------------
Physikalisch-Technische Bundesanstalt
Q.42 - Server Administration
Bundesallee 100, D-38116 Braunschweig
Tel: +49-531-592-84 20
E-Mail: dieter.sibold@ptb.de=

--------------030909030006030903070000-- --===============6429861264645486158== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg --===============6429861264645486158==-- From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Sat Jun 4 12:02:37 2011 Return-Path: X-Original-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8346311E8071 for ; Sat, 4 Jun 2011 12:02:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.7 X-Spam-Level: X-Spam-Status: No, score=-3.7 tagged_above=-999 required=5 tests=[MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XgfXmnnt73kB for ; Sat, 4 Jun 2011 12:02:36 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [IPv6:2001:4f8:fff7:1::7]) by ietfa.amsl.com (Postfix) with ESMTP id A7581228008 for ; Sat, 4 Jun 2011 12:02:32 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id 97A4186D842 for ; Sat, 4 Jun 2011 19:02:30 +0000 (UTC) X-Original-To: ntpwg@lists.ntp.org Delivered-To: ntpwg@lists.ntp.org Received: from mail1.ntp.org (mail1.ntp.org [IPv6:2001:4f8:fff7:1::5]) by lists.ntp.org (Postfix) with ESMTP id A709786D763 for ; Sat, 4 Jun 2011 00:25:09 +0000 (UTC) Received: from mailfront3.rz.tu-bs.de ([134.169.12.134] helo=tu-bs.de) by mail1.ntp.org with esmtp (Exim 4.75 (FreeBSD)) (envelope-from ) id 1QSeff-000Di1-P8 for ntpwg@lists.ntp.org; Sat, 04 Jun 2011 00:25:09 +0000 Received: from [84.133.215.34] (account y0034674@tu-braunschweig.de HELO [192.168.2.131]) by rz.tu-bs.de (CommuniGate Pro SMTP 5.3.13) with ESMTPA id 6542504; Sat, 04 Jun 2011 02:24:48 +0200 Message-ID: <4DE97B29.70605@tu-bs.de> Date: Sat, 04 Jun 2011 02:24:09 +0200 From: =?ISO-8859-1?Q?Stephen_R=F6ttger?= User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110518 Lightning/1.0b3pre Thunderbird/3.1.10 MIME-Version: 1.0 To: Danny Mayer References: <4DE838E0.5070302@udel.edu> <4DE8D4C6.4030101@ntp.org> <4DE92E29.7010901@udel.edu> <4DE947B3.20400@ntp.org> In-Reply-To: <4DE947B3.20400@ntp.org> X-SA-Exim-Connect-IP: 134.169.12.134 X-SA-Exim-Rcpt-To: ntpwg@lists.ntp.org X-SA-Exim-Mail-From: s.roettger@tu-bs.de X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) X-Mailman-Approved-At: Sat, 04 Jun 2011 18:31:47 +0000 Cc: NTP Working Group , stephen.roettger@ptb.de, dieter.sibold@ptb.de, hackers@ntp.org Subject: Re: [ntpwg] [ntp:hackers] PTB: Doubt about the autokey protocol X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Working Group for Network Time Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Errors-To: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Danny, You are right, the attacker has to be able to intercept the communication to every server. But I think, this is not an unlikely scenario. Otherwise, if the attacker can only intercept the connection to one server, he would not be able to change a clients time, even if autokey is disabled. > 2) the middleman acts for all servers and tries to fool the client into > thinking it has valid time for all servers but then all of the servers > will appear to be serving time with an almost identical set of > timestamps in which case all servers will look the same and be > suspiciously close to each other. This is not a difficulty for the attacker (if he is a man-in-the-middle to all servers). He can either vary its response times dependent on the server he spoofs, or, as I did it in my proof-of-concept code, forward all requests unchanged to the according server, but change the time values in the responses using a fixed offset. In the latter case, the time variations between the servers stay the same and can not be detected by the client as an attack. Stephen On 06/03/11 22:44, Danny Mayer wrote: > Dave, > = > No I don't think that I misinterpreted the reason. I understood about PTB. > = > One of my points was that if you are going to be using autokey you are > trying to ensure that you are getting good reliable time and therefore > need to make sure that you are using more than one source and that you > are using autokey for each one. > = > Another point is that a backward adjustment, legitimate or not, will get > ignored because the other sources are telling you that it is a > falseticker. In such cases a falseticker would be required to restart > the autorun dance from the beginning, or at least it should be doing > that. There are several scenarios here: > = > 1) the middleman acts just on one server, in which case the packets will > get thrown out as it will be considered a falseticker; > = > 2) the middleman acts for all servers and tries to fool the client into > thinking it has valid time for all servers but then all of the servers > will appear to be serving time with an almost identical set of > timestamps in which case all servers will look the same and be > suspiciously close to each other. As we know networks are wildly varying > in their delays and the only way that such a middleman can do this is by > being on the same subnet as the client which is a hard thing to > accomplish. Failing that it would be very hard for a middleman to do > this on multiple subnets. The middleman would also need to make sure > that the packets did not reach the real server or the real server's > response packets reach the client since the client will see the packets > and start to discount the packets coming from what it thinks is one > place and because the autokey dance values will not agree thereby > causing the server to be marked as a falseticker. > = > The part I'm struggling with is the client cookie and how did the > middleman get hold of a private key for it to act as a substitute server. > = > Danny > = > On 6/3/2011 2:55 PM, David L. Mills wrote: >> Danny, >> >> You might have misinterpreted by reason for posting to this list. Dieter >> is from the PTB, the German equivalent of NIST. His concern is not >> necessarily on good client practice, but provable defense against a >> middleman attack. This is one of two vulnerabilities that occur with >> public key cryptography as applied to NTP. The first is when obtaining >> client cookie from a server as I described. >> >> The second is with old duplicates in broadcast modes and in particular >> an old duplicate of a autokeys values message. The problem occurs with >> symmetric and public key cryptography, since an old duplicate cannot >> easily be distinguished from a legitimate backward adjustment of the >> system clock. >> >> The interesting aspect from an engineering point of view is that, while >> symmetric key cryptography is in general immune to middleman threats, >> public key cryptography, not just Autokey, is devilishly hard to avoid >> middleman compromise. My hope in posting to this list is to stimulate >> discussion on ways to fix the problem. >> >> There are two white papers addressing these issues, "Analysis and >> Simulation of the NT On-Wire Protocol" >> www.eecis.udel.edu/~mills/onwire.html and "NTP Security Analysis" >> www.eecis.udel.edu/~mills/security.html. Your comments are inivited. >> >> Dave >> >> Danny Mayer wrote: >> >>> Dieter, >>> >>> There are several things going on here and I'd like to try to clarify >>> them. I'm copying the NTP working group since it is more relevant to >>> that list than hackers. >>> >>> 1) If you are using NTP you should be using at a minimum 3 separate >>> sources of NTP packets. The NTP client uses the sources to decide which >>> is providing the "best" (I don't want to discuss how NTP decides which >>> is best here) source of time. NTP continually reexamines its sources and >>> makes that decision regularly. If the client is not using at least 3 >>> sources then they are not worrying about securing the time service. >>> >>> 2) A man-in-the-middle attack on autokey needs to intercept NTP Packets >>> to EVERY server it is using which is a much harder proposition. Each >>> such server will have its own keys that the middleman would need to >>> manage. >>> >>> 3) I am not clear where the middleman gets its public key. It's not >>> provided in the protocol and can only be obtained Out-of-band. The >>> server provides keys, the client doesn't. Am I mistaken in this? >>> >>> 4) You say that your student was able to perform such an attack but was >>> he able to do it without having any information about the servers keys? >>> >>> I'll have more to say when I understand this issue a little better. >>> >>> Danny >>> >>> On 6/2/2011 9:29 PM, David L. Mills wrote: >>> = >>> >>>> Dieter, >>>> >>>> The problem I have with your scenario is how to convince the client th= at >>>> the middleman client cookie is genuine. The server provides the client >>>> cookie encrypted with the middleman key, but the middleman has to >>>> encrypt the client cookie for the client using the client key. That >>>> requires the response to be signed, but the middleman cannot encrypt t= he >>>> signature without the server private key. >>>> >>>> Here is another way this could be done. The middleman lives in a >>>> compromised router on the same Ethernet as the client. It begins by >>>> simply wiretapping the client cookie request, but allows the client >>>> request/response to complete. It then repeats the request with its own >>>> key and intercepts the response without continuing to the client. >>>> Subsequently, it masquerades as the server and injects its own values >>>> while observing the on-wire protocol rules. >>>> >>>> It very well may be that the best approach to this and similar proble= ms >>>> is a suite of algorithms designed to verify the integrity of the route= r, >>>> rather than further complicate the NTP protocol design. This might be a >>>> topic for discussion on the hackers.ntp.org list. >>>> >>>> I'm still not satisfied with the NTP security document. It was first >>>> written five years ago in somewhat of a hurry as the RFC was submitted >>>> for review. The document does not lie, but its wording is a bit loose. >>>> The main thing that needs to be clarified is how the public values can >>>> be protected against middleman attack. It needs to be tightened and I = am >>>> doing that. now. I will advise when it is ready for prime time. >>>> >>>> Dave >>>> >>>> dieter.sibold@ptb.de wrote: >>>> >>>> = >>>>> Dave, >>>>> thanks for your last email. >>>>> I agree that the usage of the autokey procedure is quite an obstacle >>>>> for "normal" end users who just want to have the time from their >>>>> national laboratory. But that is not our primary intention. Although >>>>> we have quite a high access rate to out time servers the requests for >>>>> signed time packets is quite small. Therefore, I believe that even if >>>>> we provide authenticated time service to the public the usage of it >>>>> would be quite small. Our intention is to investigate if NTP together >>>>> with autokey provides an robust and secure authenticated time service >>>>> for applications which depend on authenticated time information by >>>>> requirements enforced by Germany's Verification Act. For this scenario >>>>> the technical obstacles of autokey are not a major problem. >>>>> >>>>> Nonetheless I also agree that it would be nice if the configuration >>>>> and usage would be easier. >>>>> >>>>> Thanks also for editing of the Security Analysis paper. At this point >>>>> we still have some issues. >>>>> >>>>> At our first question regarding the security of autokey you wrote: >>>>> >>>>> >>>>> >>>>> = >>>>>> Your analysis left out one crucial fact. The server reply to the >>>>>> cookie >>>>>> request is signed by the server using its private key. The client, in >>>>>> possession of the server public key, can verify the authenticity of >>>>>> the >>>>>> reply. >>>>>> = >>>>>> = >>>>> That is ok. But nonetheless, my colleague - Stephen - already >>>>> performed a man-in-the-middle attack and he was able to compute a >>>>> valid Message Authentication Code (MAC) for a servers time response. >>>>> The attack works as follows: >>>>> >>>>> First of all the attacker (M) aims to obtain the client cookie C_C for >>>>> the NTP-Client C. To this end the attacker M performs a >>>>> man-in-the-middle attack in which he masquerades as NTP-Client C and >>>>> send a cookie request to the NTP-Server S together with its public key >>>>> P_M and the IP-address IP_C of NTP-Client C. In response M obtains the >>>>> client cookie C_C from the server S, which is encrypted with the >>>>> public key P_M of M and which is meant to be for the NTP-Client C. The >>>>> attacker M is able to decrypt the client cookie C_C because it is >>>>> encrypted with its public key P_M. Now M is in possession of the >>>>> client cookie C_C and will store it. >>>>> As of now the attacker M will change his role and will masquerade as >>>>> NTP-Server S. When C sends a time request to the NTP-Server S it will >>>>> be intercepted by M. Because M stored the client cookie C_C he is now >>>>> able to verify the client request and to construct a timestamp >>>>> response with a valid MAC. >>>>> >>>>> The problem arises because the NTP packet is bound to the client >>>>> cookie C_C in which the client identity is only reflected by the >>>>> clients IP-address IP_C. Therefore M is able to gain possession of the >>>>> client cookie for C by means of a man-in-the-middle attack. >>>>> >>>>> >>>>> In the moment we do not know if the attacker M is now able to change >>>>> the time of the client C; but Stephen is investigating this question. >>>>> >>>>> Obviously we have to emphasize that this scenario is only possible if >>>>> the attacker M is able to introduce himself into the communication >>>>> line between client C and server S. >>>>> >>>>> With best regards >>>>> Dieter >>>>> ----------------------------------------------- >>>>> Physikalisch-Technische Bundesanstalt >>>>> Q.42 - Server Administration >>>>> Bundesallee 100, D-38116 Braunschweig >>>>> Tel: +49-531-592-84 20 >>>>> E-Mail: dieter.sibold@ptb.de >>>>> >>>>> -----"David L. Mills" schrieb: ----- >>>>> An: dieter.sibold@ptb.de >>>>> Von: "David L. Mills" >>>>> Datum: 30.05.2011 02:26AM >>>>> Kopie: stenn@ntp.org >>>>> Betreff: Re: PTB: Doubt about the autokey protocol >>>>> >>>>> Dieter,, >>>>> >>>>> It looks like the NTP Security Analysis needs some work. I have edited >>>>> the page and brought it up to date. See especially sections 4 and 5. >>>>> One issue is whether or not the identity scheme is necessary; for >>>>> protection from middleman attack; I believe it is. However, there are >>>>> some rough edges for a national laboratory deployment. A client needs >>>>> to have the OpenSSL cryptographic library, as well as the Autokey >>>>> configuration selected at build time. I'm not sure this will be >>>>> acceptable on a widespread deployment. >>>>> >>>>> Another issue that needs to be resolved is whether the client needs to >>>>> generate host or signature keys and whether a client certificate is >>>>> necessary. If the client has no dependent clients, it does not need >>>>> these things, but the current implementation requires them, even if >>>>> they are not used. What needs here is some software grooming to ease >>>>> the configuration and deployment on a national scale. This is not hard >>>>> and could in principle be done by the Google software corps. >>>>> >>>>> Dave >>>>> >>>>> dieter.sibold@ptb.de wrote: >>>>> >>>>> >>>>> >>>>> = >>>>>> Dear Prof. Mills and Mr. Stenn, >>>>>> >>>>>> I am writing this email because I have a couple of open questions >>>>>> regarding the security of the autokey protocol. >>>>>> >>>>>> First, let me start to explain what we want to achieve by means of >>>>>> autokey. >>>>>> The PTB is Germany's national metrology institute. The dissemination >>>>>> of time is one of our legal tasks. Since many years this is done via >>>>>> long-wave transmitter DCF77 and since 1999 we also provide publicely >>>>>> accessible NTP time servers for the dissemination of UTC(PTB) >>>>>> successfully. >>>>>> Within the scope of the new emerging smart grids in energy >>>>>> distribution systems we are investigating if we could enhance our >>>>>> time service in order to provide securely authenticated time to the >>>>>> operators of energy distribution networks. To this end we >>>>>> investigate if NTP together with the autokey-protocol is >>>>>> cryptographically sufficient to meet the requirements which are >>>>>> enforced by Germany's Verification Act. >>>>>> >>>>>> After the study of RFC5906 and recording of the communication >>>>>> messages between NTP-client and NTP-server our student was able to >>>>>> perform a man-in-the-middle attack. As a consequence he was able to >>>>>> masquerade as server. You will find the procedure described in the >>>>>> enclosed attachment. >>>>>> If the described man-in-the-middle attack really breaks the >>>>>> authentication we have to exclude the autokey-protocol from further >>>>>> investigations. So I'd very much appreciate if you would be so kind >>>>>> to comment the described attack. >>>>>> >>>>>> Thank you very much. With best regards >>>>>> >>>>>> Dr. D. Sibold >>>>>> S. R=F6ttger >>>>>> Dr. U. Grottker >>>>>> >>>>>> ----------------------------------------------- >>>>>> Physikalisch-Technische Bundesanstalt >>>>>> Q.42 - Server Administration >>>>>> Bundesallee 100, D-38116 Braunschweig >>>>>> Tel: +49-531-592-84 20 >>>>>> E-Mail: dieter.sibold@ptb.de=3D >>>>>> >>>>>> = >> >> >> > = _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Sun Jun 5 18:52:42 2011 Return-Path: X-Original-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD32F11E809E for ; Sun, 5 Jun 2011 18:52:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q---ttOelSDy for ; Sun, 5 Jun 2011 18:52:41 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [IPv6:2001:4f8:fff7:1::7]) by ietfa.amsl.com (Postfix) with ESMTP id C18BE11E8086 for ; Sun, 5 Jun 2011 18:52:36 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id B233286D928 for ; Mon, 6 Jun 2011 01:52:34 +0000 (UTC) X-Original-To: ntpwg@lists.ntp.org Delivered-To: ntpwg@lists.ntp.org Received: from mail1.ntp.org (mail1.ntp.org [IPv6:2001:4f8:fff7:1::5]) by lists.ntp.org (Postfix) with ESMTP id DB1CB86D4F1 for ; Mon, 6 Jun 2011 01:00:08 +0000 (UTC) Received: from elasmtp-mealy.atl.sa.earthlink.net ([209.86.89.69]) by mail1.ntp.org with esmtp (Exim 4.75 (FreeBSD)) (envelope-from ) id 1QTOAe-00072j-00 for ntpwg@lists.ntp.org; Mon, 06 Jun 2011 01:00:08 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=fnx1ddsbRd9WVuowRZi81xKr8ald7D2i7m9TEnKeMD1hqS8qlyZ1glUQjIsYDPcl; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:X-Opacus-Archived:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [67.180.133.66] (helo=[192.168.1.101]) by elasmtp-mealy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1QTOAY-0007ao-3d for ntpwg@lists.ntp.org; Sun, 05 Jun 2011 20:59:50 -0400 Message-ID: <4DEC26A2.4080902@earthlink.net> Date: Sun, 05 Jun 2011 18:00:18 -0700 From: todd glassey User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: ntpwg@lists.ntp.org References: <4DE838E0.5070302@udel.edu> <4DE8D4C6.4030101@ntp.org> <4DE92E29.7010901@udel.edu> <4DE947B3.20400@ntp.org> <4DE97B29.70605@tu-bs.de> In-Reply-To: <4DE97B29.70605@tu-bs.de> X-Opacus-Archived: none X-ELNK-Trace: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec792e2992cd98a4d13e6820f7d3d43e1e97350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 67.180.133.66 X-SA-Exim-Connect-IP: 209.86.89.69 X-SA-Exim-Rcpt-To: ntpwg@lists.ntp.org X-SA-Exim-Mail-From: tglassey@earthlink.net X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) Subject: Re: [ntpwg] [ntp:hackers] PTB: Doubt about the autokey protocol X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Working Group for Network Time Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" Sender: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Errors-To: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org On 6/3/2011 5:24 PM, Stephen R=F6ttger wrote: > Danny, > > You are right, the attacker has to be able to intercept the > communication to every server. But I think, this is not an unlikely > scenario. Compromising an aggregation router in a Data Center type application = implements that attack. Likewise since most all of the reliable = reference sources are on off-shoot or end-run type end-user connections = rather than at Internet hubs, this also mitigates this functional risk = further. > Otherwise, if the attacker can only intercept the connection to one > server, he would not be able to change a clients time, even if autokey > is disabled. > >> 2) the middleman acts for all servers and tries to fool the client into >> thinking it has valid time for all servers but then all of the servers >> will appear to be serving time with an almost identical set of >> timestamps in which case all servers will look the same and be >> suspiciously close to each other. > This is not a difficulty for the attacker (if he is a man-in-the-middle > to all servers). He can either vary its response times dependent on the > server he spoofs, or, as I did it in my proof-of-concept code, forward > all requests unchanged to the according server, but change the time > values in the responses using a fixed offset. True which is why its so much more reasonable for instances which need = trustable time to require private networks for them. > In the latter case, the time variations between the servers stay the > same and can not be detected by the client as an attack. True. > Stephen > > On 06/03/11 22:44, Danny Mayer wrote: >> Dave, >> >> No I don't think that I misinterpreted the reason. I understood about PT= B. >> >> One of my points was that if you are going to be using autokey you are >> trying to ensure that you are getting good reliable time and therefore >> need to make sure that you are using more than one source and that you >> are using autokey for each one. >> >> Another point is that a backward adjustment, legitimate or not, will get >> ignored because the other sources are telling you that it is a >> falseticker. In such cases a falseticker would be required to restart >> the autorun dance from the beginning, or at least it should be doing >> that. There are several scenarios here: >> >> 1) the middleman acts just on one server, in which case the packets will >> get thrown out as it will be considered a falseticker; >> >> 2) the middleman acts for all servers and tries to fool the client into >> thinking it has valid time for all servers but then all of the servers >> will appear to be serving time with an almost identical set of >> timestamps in which case all servers will look the same and be >> suspiciously close to each other. As we know networks are wildly varying >> in their delays and the only way that such a middleman can do this is by >> being on the same subnet as the client which is a hard thing to >> accomplish. Failing that it would be very hard for a middleman to do >> this on multiple subnets. The middleman would also need to make sure >> that the packets did not reach the real server or the real server's >> response packets reach the client since the client will see the packets >> and start to discount the packets coming from what it thinks is one >> place and because the autokey dance values will not agree thereby >> causing the server to be marked as a falseticker. >> >> The part I'm struggling with is the client cookie and how did the >> middleman get hold of a private key for it to act as a substitute server. >> >> Danny >> >> On 6/3/2011 2:55 PM, David L. Mills wrote: >>> Danny, >>> >>> You might have misinterpreted by reason for posting to this list. Dieter >>> is from the PTB, the German equivalent of NIST. His concern is not >>> necessarily on good client practice, but provable defense against a >>> middleman attack. This is one of two vulnerabilities that occur with >>> public key cryptography as applied to NTP. The first is when obtaining >>> client cookie from a server as I described. >>> >>> The second is with old duplicates in broadcast modes and in particular >>> an old duplicate of a autokeys values message. The problem occurs with >>> symmetric and public key cryptography, since an old duplicate cannot >>> easily be distinguished from a legitimate backward adjustment of the >>> system clock. >>> >>> The interesting aspect from an engineering point of view is that, while >>> symmetric key cryptography is in general immune to middleman threats, >>> public key cryptography, not just Autokey, is devilishly hard to avoid >>> middleman compromise. My hope in posting to this list is to stimulate >>> discussion on ways to fix the problem. >>> >>> There are two white papers addressing these issues, "Analysis and >>> Simulation of the NT On-Wire Protocol" >>> www.eecis.udel.edu/~mills/onwire.html and "NTP Security Analysis" >>> www.eecis.udel.edu/~mills/security.html. Your comments are inivited. >>> >>> Dave >>> >>> Danny Mayer wrote: >>> >>>> Dieter, >>>> >>>> There are several things going on here and I'd like to try to clarify >>>> them. I'm copying the NTP working group since it is more relevant to >>>> that list than hackers. >>>> >>>> 1) If you are using NTP you should be using at a minimum 3 separate >>>> sources of NTP packets. The NTP client uses the sources to decide which >>>> is providing the "best" (I don't want to discuss how NTP decides which >>>> is best here) source of time. NTP continually reexamines its sources a= nd >>>> makes that decision regularly. If the client is not using at least 3 >>>> sources then they are not worrying about securing the time service. >>>> >>>> 2) A man-in-the-middle attack on autokey needs to intercept NTP Packets >>>> to EVERY server it is using which is a much harder proposition. Each >>>> such server will have its own keys that the middleman would need to >>>> manage. >>>> >>>> 3) I am not clear where the middleman gets its public key. It's not >>>> provided in the protocol and can only be obtained Out-of-band. The >>>> server provides keys, the client doesn't. Am I mistaken in this? >>>> >>>> 4) You say that your student was able to perform such an attack but was >>>> he able to do it without having any information about the servers keys? >>>> >>>> I'll have more to say when I understand this issue a little better. >>>> >>>> Danny >>>> >>>> On 6/2/2011 9:29 PM, David L. Mills wrote: >>>> >>>> >>>>> Dieter, >>>>> >>>>> The problem I have with your scenario is how to convince the client t= hat >>>>> the middleman client cookie is genuine. The server provides the client >>>>> cookie encrypted with the middleman key, but the middleman has to >>>>> encrypt the client cookie for the client using the client key. That >>>>> requires the response to be signed, but the middleman cannot encrypt = the >>>>> signature without the server private key. >>>>> >>>>> Here is another way this could be done. The middleman lives in a >>>>> compromised router on the same Ethernet as the client. It begins by >>>>> simply wiretapping the client cookie request, but allows the client >>>>> request/response to complete. It then repeats the request with its o= wn >>>>> key and intercepts the response without continuing to the client. >>>>> Subsequently, it masquerades as the server and injects its own values >>>>> while observing the on-wire protocol rules. >>>>> >>>>> It very well may be that the best approach to this and similar probl= ems >>>>> is a suite of algorithms designed to verify the integrity of the rout= er, >>>>> rather than further complicate the NTP protocol design. This might be= a >>>>> topic for discussion on the hackers.ntp.org list. >>>>> >>>>> I'm still not satisfied with the NTP security document. It was first >>>>> written five years ago in somewhat of a hurry as the RFC was submitted >>>>> for review. The document does not lie, but its wording is a bit loose. >>>>> The main thing that needs to be clarified is how the public values can >>>>> be protected against middleman attack. It needs to be tightened and I= am >>>>> doing that. now. I will advise when it is ready for prime time. >>>>> >>>>> Dave >>>>> >>>>> dieter.sibold@ptb.de wrote: >>>>> >>>>> >>>>>> Dave, >>>>>> thanks for your last email. >>>>>> I agree that the usage of the autokey procedure is quite an obstacle >>>>>> for "normal" end users who just want to have the time from their >>>>>> national laboratory. But that is not our primary intention. Although >>>>>> we have quite a high access rate to out time servers the requests for >>>>>> signed time packets is quite small. Therefore, I believe that even if >>>>>> we provide authenticated time service to the public the usage of it >>>>>> would be quite small. Our intention is to investigate if NTP together >>>>>> with autokey provides an robust and secure authenticated time service >>>>>> for applications which depend on authenticated time information by >>>>>> requirements enforced by Germany's Verification Act. For this scenar= io >>>>>> the technical obstacles of autokey are not a major problem. >>>>>> >>>>>> Nonetheless I also agree that it would be nice if the configuration >>>>>> and usage would be easier. >>>>>> >>>>>> Thanks also for editing of the Security Analysis paper. At this point >>>>>> we still have some issues. >>>>>> >>>>>> At our first question regarding the security of autokey you wrote: >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> Your analysis left out one crucial fact. The server reply to the >>>>>>> cookie >>>>>>> request is signed by the server using its private key. The client, = in >>>>>>> possession of the server public key, can verify the authenticity of >>>>>>> the >>>>>>> reply. >>>>>>> >>>>>>> >>>>>> That is ok. But nonetheless, my colleague - Stephen - already >>>>>> performed a man-in-the-middle attack and he was able to compute a >>>>>> valid Message Authentication Code (MAC) for a servers time response. >>>>>> The attack works as follows: >>>>>> >>>>>> First of all the attacker (M) aims to obtain the client cookie C_C f= or >>>>>> the NTP-Client C. To this end the attacker M performs a >>>>>> man-in-the-middle attack in which he masquerades as NTP-Client C and >>>>>> send a cookie request to the NTP-Server S together with its public k= ey >>>>>> P_M and the IP-address IP_C of NTP-Client C. In response M obtains t= he >>>>>> client cookie C_C from the server S, which is encrypted with the >>>>>> public key P_M of M and which is meant to be for the NTP-Client C. T= he >>>>>> attacker M is able to decrypt the client cookie C_C because it is >>>>>> encrypted with its public key P_M. Now M is in possession of the >>>>>> client cookie C_C and will store it. >>>>>> As of now the attacker M will change his role and will masquerade as >>>>>> NTP-Server S. When C sends a time request to the NTP-Server S it will >>>>>> be intercepted by M. Because M stored the client cookie C_C he is now >>>>>> able to verify the client request and to construct a timestamp >>>>>> response with a valid MAC. >>>>>> >>>>>> The problem arises because the NTP packet is bound to the client >>>>>> cookie C_C in which the client identity is only reflected by the >>>>>> clients IP-address IP_C. Therefore M is able to gain possession of t= he >>>>>> client cookie for C by means of a man-in-the-middle attack. >>>>>> >>>>>> >>>>>> In the moment we do not know if the attacker M is now able to change >>>>>> the time of the client C; but Stephen is investigating this question. >>>>>> >>>>>> Obviously we have to emphasize that this scenario is only possible if >>>>>> the attacker M is able to introduce himself into the communication >>>>>> line between client C and server S. >>>>>> >>>>>> With best regards >>>>>> Dieter >>>>>> ----------------------------------------------- >>>>>> Physikalisch-Technische Bundesanstalt >>>>>> Q.42 - Server Administration >>>>>> Bundesallee 100, D-38116 Braunschweig >>>>>> Tel: +49-531-592-84 20 >>>>>> E-Mail: dieter.sibold@ptb.de >>>>>> >>>>>> -----"David L. Mills" schrieb: ----- >>>>>> An: dieter.sibold@ptb.de >>>>>> Von: "David L. Mills" >>>>>> Datum: 30.05.2011 02:26AM >>>>>> Kopie: stenn@ntp.org >>>>>> Betreff: Re: PTB: Doubt about the autokey protocol >>>>>> >>>>>> Dieter,, >>>>>> >>>>>> It looks like the NTP Security Analysis needs some work. I have edit= ed >>>>>> the page and brought it up to date. See especially sections 4 and 5. >>>>>> One issue is whether or not the identity scheme is necessary; for >>>>>> protection from middleman attack; I believe it is. However, there are >>>>>> some rough edges for a national laboratory deployment. A client needs >>>>>> to have the OpenSSL cryptographic library, as well as the Autokey >>>>>> configuration selected at build time. I'm not sure this will be >>>>>> acceptable on a widespread deployment. >>>>>> >>>>>> Another issue that needs to be resolved is whether the client needs = to >>>>>> generate host or signature keys and whether a client certificate is >>>>>> necessary. If the client has no dependent clients, it does not need >>>>>> these things, but the current implementation requires them, even if >>>>>> they are not used. What needs here is some software grooming to ease >>>>>> the configuration and deployment on a national scale. This is not ha= rd >>>>>> and could in principle be done by the Google software corps. >>>>>> >>>>>> Dave >>>>>> >>>>>> dieter.sibold@ptb.de wrote: >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> Dear Prof. Mills and Mr. Stenn, >>>>>>> >>>>>>> I am writing this email because I have a couple of open questions >>>>>>> regarding the security of the autokey protocol. >>>>>>> >>>>>>> First, let me start to explain what we want to achieve by means of >>>>>>> autokey. >>>>>>> The PTB is Germany's national metrology institute. The dissemination >>>>>>> of time is one of our legal tasks. Since many years this is done v= ia >>>>>>> long-wave transmitter DCF77 and since 1999 we also provide publicely >>>>>>> accessible NTP time servers for the dissemination of UTC(PTB) >>>>>>> successfully. >>>>>>> Within the scope of the new emerging smart grids in energy >>>>>>> distribution systems we are investigating if we could enhance our >>>>>>> time service in order to provide securely authenticated time to t= he >>>>>>> operators of energy distribution networks. To this end we >>>>>>> investigate if NTP together with the autokey-protocol is >>>>>>> cryptographically sufficient to meet the requirements which are >>>>>>> enforced by Germany's Verification Act. >>>>>>> >>>>>>> After the study of RFC5906 and recording of the communication >>>>>>> messages between NTP-client and NTP-server our student was able to >>>>>>> perform a man-in-the-middle attack. As a consequence he was able to >>>>>>> masquerade as server. You will find the procedure described in the >>>>>>> enclosed attachment. >>>>>>> If the described man-in-the-middle attack really breaks the >>>>>>> authentication we have to exclude the autokey-protocol from further >>>>>>> investigations. So I'd very much appreciate if you would be so kind >>>>>>> to comment the described attack. >>>>>>> >>>>>>> Thank you very much. With best regards >>>>>>> >>>>>>> Dr. D. Sibold >>>>>>> S. R=F6ttger >>>>>>> Dr. U. Grottker >>>>>>> >>>>>>> ----------------------------------------------- >>>>>>> Physikalisch-Technische Bundesanstalt >>>>>>> Q.42 - Server Administration >>>>>>> Bundesallee 100, D-38116 Braunschweig >>>>>>> Tel: +49-531-592-84 20 >>>>>>> E-Mail: dieter.sibold@ptb.de=3D >>>>>>> >>>>>>> >>> >>> > _______________________________________________ > ntpwg mailing list > ntpwg@lists.ntp.org > http://lists.ntp.org/listinfo/ntpwg > -- = Todd S. Glassey This is from my personal email account and any materials from this account = come with personal disclaimers. _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Mon Jun 6 08:18:39 2011 Return-Path: X-Original-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC50F11E8169 for ; Mon, 6 Jun 2011 08:18:39 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version" X-Spam-Flag: NO X-Spam-Score: -6.098 X-Spam-Level: X-Spam-Status: No, score=-6.098 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BAD_LINEBREAK=0.5, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W068bRcuE26t for ; Mon, 6 Jun 2011 08:18:37 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [IPv6:2001:4f8:fff7:1::7]) by ietfa.amsl.com (Postfix) with ESMTP id 237EE11E815C for ; Mon, 6 Jun 2011 08:18:36 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id 863E686DA65 for ; Mon, 6 Jun 2011 15:18:35 +0000 (UTC) X-Original-To: ntpwg@lists.ntp.org Delivered-To: ntpwg@lists.ntp.org Received: from mail1.ntp.org (mail1.ntp.org [IPv6:2001:4f8:fff7:1::5]) by lists.ntp.org (Postfix) with ESMTP id E816B86D4F0 for ; Mon, 6 Jun 2011 09:56:04 +0000 (UTC) Received: from u99105.bs.ptb.de ([192.53.103.105]) by mail1.ntp.org with esmtp (Exim 4.75 (FreeBSD)) (envelope-from ) id 1QTWXH-000H26-Qf for ntpwg@lists.ntp.org; Mon, 06 Jun 2011 09:56:04 +0000 Received: from u99105.bs.ptb.de (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 2BD1092F7A7; Mon, 6 Jun 2011 11:55:49 +0200 (CEST) Received: from rose.bs.ptb.de (rose.bs.ptb.de [141.25.85.201]) by u99105.bs.ptb.de (Postfix) with ESMTP id 1236992F794; Mon, 6 Jun 2011 11:55:49 +0200 (CEST) X-Disclaimed: 1 MIME-Version: 1.0 Importance: Normal X-Priority: 3 (Normal) In-Reply-To: <4DE8D4C6.4030101@ntp.org> References: <4DE8D4C6.4030101@ntp.org>, <4DE838E0.5070302@udel.edu> From: stephen.roettger@ptb.de To: mayer@ntp.org Message-ID: Date: Mon, 6 Jun 2011 11:55:47 +0200 X-Mailer: Lotus Domino Web Server Release 8.5.2FP2 March 22, 2011 X-MIMETrack: Serialize by Notes Server on ROSE/PTB(Release 8.5.2FP2|March 22, 2011) at 06/06/2011 11:55:47, Serialize complete at 06/06/2011 11:55:47, Itemize by Notes Server on ROSE/PTB(Release 8.5.2FP2|March 22, 2011) at 06/06/2011 11:55:47, Serialize by Router on ROSE/PTB(Release 8.5.2FP2|March 22, 2011) at 06/06/2011 11:55:48, Serialize complete at 06/06/2011 11:55:48 MIME-Version: 1.0 X-SA-Exim-Connect-IP: 192.53.103.105 X-SA-Exim-Rcpt-To: ntpwg@lists.ntp.org X-SA-Exim-Mail-From: stephen.roettger@ptb.de X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) X-Mailman-Approved-At: Mon, 06 Jun 2011 14:20:18 +0000 Cc: ntpwg@lists.ntp.org, dieter.sibold@ptb.de, hackers@ntp.org, s.roettger@tu-braunschweig.de Subject: [ntpwg] Antwort: Re: [ntp:hackers] PTB: Doubt about the autokey protocol X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Working Group for Network Time Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2276165915097389954==" Sender: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Errors-To: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org --===============2276165915097389954== Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Hello,

I want to infor= m you that we were able to perform our described attack
and finished a p= iece of proof-of-concept code, that is able to change
a clients time des= pite autokey is enabled. Currently, it only works
if the client starts i= t's NTP process after the attacker is in place,
but I think it shows the= point.
=0D
= =0DWe think it would be a good mitigation to modify the cookie calculation.=
=0DInstead of using the clients IP address, its public key could be use= d.
=0DConsequently, the attacker would not be able to obtain the cookie = for a
=0Dclient without knowing the clients private key.
=0DThis woul= d have the positive side effect, that autokey would work with
=0DNATs an= d it is the only possibility that we can think of, that leaves
=0Dthe se= rver stateless and does not add requirements to the client (e.g.=0Da
=0D= certificate from a trusted authority).
=0DOn the other hand, it would re= quire the client, to send its public key
=0Dwith every time request mess= age.

Stephen

-----Dann= y Mayer &l= t;mayer@ntp.org> schrieb: -----
An: "David L. Mills" <mills@udel.edu>
Von: = Danny Mayer <mayer@ntp.org>
Datum: 03.06.2011 14:32
Kopie: dieter.s= ibold@ptb.de, Stephen R=F6ttger <s.roettger@tu-braunschweig.de= >, hackers@ntp.org, stephen.roettger@ptb.de, NTP Working Group= <= ;ntpwg@lists.ntp.org>
Betreff: Re: [ntp:hackers] PTB: Doubt about= the autokey protocol

Dieter,

There are several things going on here and I'd = like to try to clarify
them. I'm copying the NTP working group since it = is more relevant to
that list than hackers.

1) If you are using N= TP you should be using at a minimum 3 separate
sources of NTP packets. T= he NTP client uses the sources to decide which
is providing the "best" (= I don't want to discuss how NTP decides which
is best here) source of ti= me. NTP continually reexamines its sources and
makes that decision regul= arly. If the client is not using at least 3
sources then they are not wo= rrying about securing the time service.

2) A man-in-the-middle attac= k on autokey needs to intercept NTP Packets
to EVERY server it is using = which is a much harder proposition. Each
such server will have its own k= eys that the middleman would need to manage.

3) I am not clear where= the middleman gets its public key. It's not
provided in the protocol an= d can only be obtained Out-of-band. The
server provides keys, the client= doesn't. Am I mistaken in this?

4) You say that your student was ab= le to perform such an attack but was
he able to do it without having any= information about the servers keys?

I'll have more to say when I un= derstand this issue a little better.

Danny

On 6/2/2011 9:29 P= M, David L. Mills wrote:
> Dieter,
>
> The problem I hav= e with your scenario is how to convince the client that
> the middlem= an client cookie is genuine. The server provides the client
> cookie = encrypted with the middleman key, but the middleman has to
> encrypt = the client cookie for the client using the client key. That
> require= s the response to be signed, but the middleman cannot encrypt the
> s= ignature without the server private key.
>
> Here is another w= ay this could be done. The middleman lives in a
> compromised router = on the same Ethernet as the client. It begins by
> simply wiretapping= the client cookie request, but allows the client
> request/response = to complete. It then repeats the request  with its own
> key and= intercepts the response without continuing to the client.
> Subseque= ntly, it masquerades as the server and injects its own values
> while= observing the on-wire protocol rules.
>
> It very well may be= that the best  approach to this and similar problems
> is a sui= te of algorithms designed to verify the integrity of the router,
> ra= ther than further complicate the NTP protocol design. This might be a
&g= t; topic for discussion on the hackers.ntp.org list.
>
> I'm s= till not satisfied with the NTP security document. It was first
> wri= tten five years ago in somewhat of a hurry as the RFC was submitted
>= for review. The document does not lie, but its wording is a bit loose.
= > The main thing that needs to be clarified is how the public values can=
> be protected against middleman attack. It needs to be tightened an= d I am
> doing that. now. I will advise when it is ready for prime ti= me.
>
> Dave
>
> dieter.sibold@ptb.de wrote:<= br>>
>> Dave,
>> thanks for your last email.
>&= gt; I agree that the usage of the autokey procedure is quite an obstacle>> for "normal" end users who just want to have the time from their<= br>>> national laboratory. But that is not our primary intention. Alt= hough
>> we have quite a high access rate to out time servers the = requests for
>> signed time packets is quite small. Therefore, I b= elieve that even if
>> we provide authenticated time service to th= e public the usage of it
>> would be quite small. Our intention is= to investigate if NTP together
>> with autokey provides an robust= and secure authenticated time service
>> for applications which d= epend on authenticated time information by
>> requirements enforce= d by Germany's Verification Act. For this scenario
>> the technica= l obstacles of autokey are not a major problem.
>>
>> Non= etheless I also agree that it would be nice if the configuration
>>= ; and usage would be easier.
>>
>> Thanks also for editin= g of the Security Analysis paper. At this point
>> we still have s= ome issues.
>>
>> At our first question regarding the sec= urity of autokey you wrote:
>>
>>  
>>
&= gt;>> Your analysis left out one crucial fact. The server reply = to the cookie
>>> request is signed by the server using its pri= vate key. The client, in
>>> possession of the server public ke= y, can verify the authenticity of the
>>> reply.
>>>= ;  
>>
>> That is ok. But nonetheless, my colleague= - Stephen - already
>> performed a man-in-the-middle attack and h= e was able to compute a
>> valid Message Authentication Code (MAC)= for a servers time response.
>> The attack works as follows:
&= gt;>
>> First of all the attacker (M) aims to obtain the client= cookie C=5FC for
>> the NTP-Client C. To this end the attacker M = performs a
>> man-in-the-middle attack in which he masquerades as = NTP-Client C and
>> send a cookie request to the NTP-Server S toge= ther with its public key
>> P=5FM and the IP-address IP=5FC of NTP= -Client C. In response M obtains the
>> client cookie C=5FC from t= he server S, which is encrypted with the
>> public key P=5FM of M = and which is meant to be for the NTP-Client C. The
>> attacker M i= s able to decrypt the client cookie C=5FC because it is
>> encrypt= ed with its public key P=5FM. Now M is in possession of the
>> cli= ent cookie C=5FC and will store it.
>> As of now the attacker M wi= ll change his role and will masquerade as
>> NTP-Server S. When C = sends a time request to the NTP-Server S it will
>> be intercepted= by M. Because M stored the client cookie C=5FC he is now
>> able = to verify the client request and to construct a timestamp
>> respo= nse with a valid MAC.
>>
>> The problem arises because th= e NTP packet is bound to the client
>> cookie C=5FC in which the c= lient identity is only reflected by the
>> clients IP-address IP= =5FC. Therefore M is able to gain possession of the
>> client cook= ie for C by means of a man-in-the-middle attack.
>>
>>>> In the moment we do not know if the attacker M is now able to cha= nge
>> the time of the client C; but Stephen is investigating this= question.
>>
>> Obviously we have to emphasize that this= scenario is only possible if
>> the attacker M is able to introdu= ce himself into the communication
>> line between client C and ser= ver S.
>>
>> With best regards
>> Dieter
>= > -----------------------------------------------
>> Physikalis= ch-Technische Bundesanstalt
>> Q.42 - Server Administration
>= ;> Bundesallee 100, D-38116 Braunschweig
>> Tel: +49-531-592-84= 20
>> E-Mail: dieter.sibold@ptb.de
>>
>> --= ---"David L. Mills" <mills@udel.edu> schrieb: -----
>> An: dieter= .sibold@ptb.de
>> Von: "David L. Mills" <mills@udel.edu>
&= gt;> Datum: 30.05.2011 02:26AM
>> Kopie: stenn@ntp.org
>>= Betreff: Re: PTB: Doubt about the autokey protocol
>>
>>= Dieter,,
>>
>> It looks like the NTP Security Analysis n= eeds some work. I have edited
>> the page and brought it up to dat= e. See especially sections 4 and 5.
>> One issue is whether or not= the identity scheme is necessary; for
>> protection from middlema= n attack; I believe it is. However, there are
>> some rough edges = for a national laboratory deployment. A client needs
>> to have th= e OpenSSL cryptographic library, as well as the Autokey
>> configu= ration selected at build time. I'm not sure this will be
>> accept= able on a widespread deployment.
>>
>> Another issue that= needs to be resolved is whether the client needs to
>> generate h= ost or signature keys and whether a client certificate is
>> neces= sary. If the client has no dependent clients, it does not need
>> = these things, but the current implementation requires them, even if
>= > they are not used. What needs here is some software grooming to ease>> the configuration and deployment on a national scale. This is no= t hard
>> and could in principle be done by the Google software co= rps.
>>
>> Dave
>>
>> dieter.sibold@ptb= .de wrote:
>>
>>  
>>
>>> D= ear Prof. Mills and Mr. Stenn,
>>>
>>> I am writing= this email because I have a couple of open questions
>>> regar= ding the security of the autokey protocol.
>>>
>>> = First, let me start to explain what we want to achieve by means of
>&= gt;> autokey.
>>> The PTB is Germany's national metrology in= stitute. The dissemination
>>> of  time is one of our lega= l tasks. Since many years this is done via
>>> long-wave transm= itter DCF77 and since 1999 we also provide publicely
>>> access= ible NTP time servers for the dissemination of UTC(PTB)
>>> suc= cessfully.
>>> Within the scope of the new emerging smart grids= in energy
>>> distribution systems we are investigating if we = could enhance our
>>> time service  in order to provide se= curely  authenticated time to the
>>> operators of energy = distribution networks.  To this end we
>>> investigate if = NTP together with the autokey-protocol is
>>> cryptographically= sufficient to meet the requirements which are
>>> enforced by = Germany's Verification Act.
>>>
>>> After the study= of RFC5906 and recording of the communication
>>> messages bet= ween NTP-client and NTP-server our student was able to
>>> perf= orm a man-in-the-middle attack. As a consequence he was able to
>>= > masquerade as server. You will find the  procedure  describe= d in the
>>> enclosed attachment.
>>> If the descri= bed man-in-the-middle attack really breaks the
>>> authenticati= on we have to exclude the autokey-protocol from further
>>> inv= estigations. So I'd very much appreciate if you would be so kind
>>= ;> to comment the described attack.
>>>
>>> Than= k you very much. With best regards
>>>
>>> Dr. D. S= ibold
>>> S. R=F6ttger
>>> Dr. U. Grottker
>&= gt;>
>>> -----------------------------------------------
= >>> Physikalisch-Technische Bundesanstalt
>>> Q.42 - S= erver Administration
>>> Bundesallee 100, D-38116 Braunschweig<= br>>>> Tel: +49-531-592-84 20
>>> E-Mail: dieter.si= bold@ptb.de=3D
>>>
= = --===============2276165915097389954== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg --===============2276165915097389954==-- From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Tue Jun 7 08:44:19 2011 Return-Path: X-Original-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2853111E816A for ; Tue, 7 Jun 2011 08:44:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.597 X-Spam-Level: X-Spam-Status: No, score=-6.597 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KVpPciwCMskD for ; Tue, 7 Jun 2011 08:44:17 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [IPv6:2001:4f8:fff7:1::7]) by ietfa.amsl.com (Postfix) with ESMTP id 3C7CE11E8162 for ; Tue, 7 Jun 2011 08:44:16 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id C493286DAA2 for ; Tue, 7 Jun 2011 15:44:14 +0000 (UTC) X-Original-To: ntpwg@lists.ntp.org Delivered-To: ntpwg@lists.ntp.org Received: from mail1.ntp.org (mail1.ntp.org [IPv6:2001:4f8:fff7:1::5]) by lists.ntp.org (Postfix) with ESMTP id 5D4C286D767 for ; Tue, 7 Jun 2011 14:37:47 +0000 (UTC) Received: from louie.udel.edu ([128.4.40.12] helo=mail.eecis.udel.edu) by mail1.ntp.org with esmtp (Exim 4.75 (FreeBSD)) (envelope-from ) id 1QTxPR-0009XP-CS for ntpwg@lists.ntp.org; Tue, 07 Jun 2011 14:37:47 +0000 Received: from [192.168.1.3] (pool-74-109-121-175.phlapa.fios.verizon.net [74.109.121.175]) (Authenticated sender: mills@mail.eecis.udel.edu) by mail.eecis.udel.edu (Postfix) with ESMTP id 33EAC739; Tue, 7 Jun 2011 10:37:32 -0400 (EDT) Message-ID: <4DEE37AE.40408@udel.edu> Date: Tue, 07 Jun 2011 14:37:34 +0000 From: "David L. Mills" 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: stephen.roettger@ptb.de References: <4DE8D4C6.4030101@ntp.org>, <4DE838E0.5070302@udel.edu> In-Reply-To: X-SA-Exim-Connect-IP: 128.4.40.12 X-SA-Exim-Rcpt-To: ntpwg@lists.ntp.org X-SA-Exim-Mail-From: mills@udel.edu X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) Cc: ntpwg@lists.ntp.org, dieter.sibold@ptb.de, hackers@ntp.org, s.roettger@tu-braunschweig.de Subject: Re: [ntpwg] Antwort: Re: [ntp:hackers] PTB: Doubt about the autokey protocol X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Working Group for Network Time Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2812588115849372223==" Sender: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Errors-To: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org This is a multi-part message in MIME format. --===============2812588115849372223== Content-Type: multipart/alternative; boundary="------------070904080107030801080305" This is a multi-part message in MIME format. --------------070904080107030801080305 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Stephen, It would indeed avoid the problem you cite, but that would involve an=20 expensive cryptographic computation for every server packet. This was=20 considered in the Autokey briefing at the NTP project page, but rejected. There might still be room for an innovative approach. However, upon=20 close examination there are more vulnerabilities, including a=20 cut-and-paste attack on the Autokey extension fields. The Autokey dances=20 are not the only ones vulnerable to these attacks, but a generic=20 solution is really hard to find. Meanwhile, one of the things we can assume is that the client has a=20 secure means to obtain the server public key or certificate. The same=20 issue applies to the public identity key if used. This avoids middleman=20 attack in the same way as a symmetric key. The issue about the cookie=20 exchange and autokey values exchange needs to be looked at more carefully= . All this activity started with a more careful examination of the=20 middleman issues. The Autokey project began in 1996, but was only=20 finalized in 2005 and generally not actively pursued since the stime=20 IETF study group in 20006. In the light of a much more aggressive=20 intruder threat today, these issues should be examined in great detail.=20 The lessons learned might benefit a wider community. Dave Stephen.roettger@ptb.de wrote: > Hello, > > I want to inform you that we were able to perform our described attack > and finished a piece of proof-of-concept code, that is able to change > a clients time despite autokey is enabled. Currently, it only works > if the client starts it's NTP process after the attacker is in place, > but I think it shows the point. > > We think it would be a good mitigation to modify the cookie calculation= . > Instead of using the clients IP address, its public key could be used. > Consequently, the attacker would not be able to obtain the cookie for a > client without knowing the clients private key. > This would have the positive side effect, that autokey would work with > NATs and it is the only possibility that we can think of, that leaves > the server stateless and does not add requirements to the client (e.g. = a > certificate from a trusted authority). > On the other hand, it would require the client, to send its public key > with every time request message. > > Stephen > > -----Danny Mayer schrieb: ----- > > An: "David L. Mills" > Von: Danny Mayer > Datum: 03.06.2011 14:32 > Kopie: dieter.sibold@ptb.de, Stephen R=F6ttger > , hackers@ntp.org, > stephen.roettger@ptb.de, NTP Working Group > Betreff: Re: [ntp:hackers] PTB: Doubt about the autokey protocol > > Dieter, > > There are several things going on here and I'd like to try to clari= fy > them. I'm copying the NTP working group since it is more relevant t= o > that list than hackers. > > 1) If you are using NTP you should be using at a minimum 3 separate > sources of NTP packets. The NTP client uses the sources to decide > which > is providing the "best" (I don't want to discuss how NTP decides wh= ich > is best here) source of time. NTP continually reexamines its > sources and > makes that decision regularly. If the client is not using at least = 3 > sources then they are not worrying about securing the time service. > > 2) A man-in-the-middle attack on autokey needs to intercept NTP > Packets > to EVERY server it is using which is a much harder proposition. Eac= h > such server will have its own keys that the middleman would need > to manage. > > 3) I am not clear where the middleman gets its public key. It's not > provided in the protocol and can only be obtained Out-of-band. The > server provides keys, the client doesn't. Am I mistaken in this? > > 4) You say that your student was able to perform such an attack > but was > he able to do it without having any information about the servers > keys? > > I'll have more to say when I understand this issue a little better. > > Danny > > On 6/2/2011 9:29 PM, David L. Mills wrote: > > Dieter, > > > > The problem I have with your scenario is how to convince the > client that > > the middleman client cookie is genuine. The server provides the > client > > cookie encrypted with the middleman key, but the middleman has to > > encrypt the client cookie for the client using the client key. Th= at > > requires the response to be signed, but the middleman cannot > encrypt the > > signature without the server private key. > > > > Here is another way this could be done. The middleman lives in a > > compromised router on the same Ethernet as the client. It begins = by > > simply wiretapping the client cookie request, but allows the clie= nt > > request/response to complete. It then repeats the request with > its own > > key and intercepts the response without continuing to the client. > > Subsequently, it masquerades as the server and injects its own > values > > while observing the on-wire protocol rules. > > > > It very well may be that the best approach to this and similar > problems > > is a suite of algorithms designed to verify the integrity of the > router, > > rather than further complicate the NTP protocol design. This > might be a > > topic for discussion on the hackers.ntp.org list. > > > > I'm still not satisfied with the NTP security document. It was fi= rst > > written five years ago in somewhat of a hurry as the RFC was > submitted > > for review. The document does not lie, but its wording is a bit > loose. > > The main thing that needs to be clarified is how the public > values can > > be protected against middleman attack. It needs to be tightened > and I am > > doing that. now. I will advise when it is ready for prime time. > > > > Dave > > > > dieter.sibold@ptb.de wrote: > > > >> Dave, > >> thanks for your last email. > >> I agree that the usage of the autokey procedure is quite an > obstacle > >> for "normal" end users who just want to have the time from their > >> national laboratory. But that is not our primary intention. > Although > >> we have quite a high access rate to out time servers the > requests for > >> signed time packets is quite small. Therefore, I believe that > even if > >> we provide authenticated time service to the public the usage of= it > >> would be quite small. Our intention is to investigate if NTP > together > >> with autokey provides an robust and secure authenticated time > service > >> for applications which depend on authenticated time information = by > >> requirements enforced by Germany's Verification Act. For this > scenario > >> the technical obstacles of autokey are not a major problem. > >> > >> Nonetheless I also agree that it would be nice if the configurat= ion > >> and usage would be easier. > >> > >> Thanks also for editing of the Security Analysis paper. At this > point > >> we still have some issues. > >> > >> At our first question regarding the security of autokey you wrot= e: > >> > >> =20 > >> > >>> Your analysis left out one crucial fact. The server reply to > the cookie > >>> request is signed by the server using its private key. The > client, in > >>> possession of the server public key, can verify the > authenticity of the > >>> reply. > >>> =20 > >> > >> That is ok. But nonetheless, my colleague - Stephen - already > >> performed a man-in-the-middle attack and he was able to compute = a > >> valid Message Authentication Code (MAC) for a servers time > response. > >> The attack works as follows: > >> > >> First of all the attacker (M) aims to obtain the client cookie > C_C for > >> the NTP-Client C. To this end the attacker M performs a > >> man-in-the-middle attack in which he masquerades as NTP-Client > C and > >> send a cookie request to the NTP-Server S together with its > public key > >> P_M and the IP-address IP_C of NTP-Client C. In response M > obtains the > >> client cookie C_C from the server S, which is encrypted with the > >> public key P_M of M and which is meant to be for the NTP-Client > C. The > >> attacker M is able to decrypt the client cookie C_C because it i= s > >> encrypted with its public key P_M. Now M is in possession of the > >> client cookie C_C and will store it. > >> As of now the attacker M will change his role and will > masquerade as > >> NTP-Server S. When C sends a time request to the NTP-Server S > it will > >> be intercepted by M. Because M stored the client cookie C_C he > is now > >> able to verify the client request and to construct a timestamp > >> response with a valid MAC. > >> > >> The problem arises because the NTP packet is bound to the client > >> cookie C_C in which the client identity is only reflected by the > >> clients IP-address IP_C. Therefore M is able to gain possession > of the > >> client cookie for C by means of a man-in-the-middle attack. > >> > >> > >> In the moment we do not know if the attacker M is now able to > change > >> the time of the client C; but Stephen is investigating this > question. > >> > >> Obviously we have to emphasize that this scenario is only > possible if > >> the attacker M is able to introduce himself into the communicati= on > >> line between client C and server S. > >> > >> With best regards > >> Dieter > >> ----------------------------------------------- > >> Physikalisch-Technische Bundesanstalt > >> Q.42 - Server Administration > >> Bundesallee 100, D-38116 Braunschweig > >> Tel: +49-531-592-84 20 > >> E-Mail: dieter.sibold@ptb.de > >> > >> -----"David L. Mills" schrieb: ----- > >> An: dieter.sibold@ptb.de > >> Von: "David L. Mills" > >> Datum: 30.05.2011 02:26AM > >> Kopie: stenn@ntp.org > >> Betreff: Re: PTB: Doubt about the autokey protocol > >> > >> Dieter,, > >> > >> It looks like the NTP Security Analysis needs some work. I have > edited > >> the page and brought it up to date. See especially sections 4 > and 5. > >> One issue is whether or not the identity scheme is necessary; fo= r > >> protection from middleman attack; I believe it is. However, > there are > >> some rough edges for a national laboratory deployment. A client > needs > >> to have the OpenSSL cryptographic library, as well as the Autoke= y > >> configuration selected at build time. I'm not sure this will be > >> acceptable on a widespread deployment. > >> > >> Another issue that needs to be resolved is whether the client > needs to > >> generate host or signature keys and whether a client certificate= is > >> necessary. If the client has no dependent clients, it does not n= eed > >> these things, but the current implementation requires them, even= if > >> they are not used. What needs here is some software grooming to > ease > >> the configuration and deployment on a national scale. This is > not hard > >> and could in principle be done by the Google software corps. > >> > >> Dave > >> > >> dieter.sibold@ptb.de wrote: > >> > >> =20 > >> > >>> Dear Prof. Mills and Mr. Stenn, > >>> > >>> I am writing this email because I have a couple of open questio= ns > >>> regarding the security of the autokey protocol. > >>> > >>> First, let me start to explain what we want to achieve by means= of > >>> autokey. > >>> The PTB is Germany's national metrology institute. The > dissemination > >>> of time is one of our legal tasks. Since many years this is > done via > >>> long-wave transmitter DCF77 and since 1999 we also provide > publicely > >>> accessible NTP time servers for the dissemination of UTC(PTB) > >>> successfully. > >>> Within the scope of the new emerging smart grids in energy > >>> distribution systems we are investigating if we could enhance o= ur > >>> time service in order to provide securely authenticated time > to the > >>> operators of energy distribution networks. To this end we > >>> investigate if NTP together with the autokey-protocol is > >>> cryptographically sufficient to meet the requirements which are > >>> enforced by Germany's Verification Act. > >>> > >>> After the study of RFC5906 and recording of the communication > >>> messages between NTP-client and NTP-server our student was able= to > >>> perform a man-in-the-middle attack. As a consequence he was > able to > >>> masquerade as server. You will find the procedure described > in the > >>> enclosed attachment. > >>> If the described man-in-the-middle attack really breaks the > >>> authentication we have to exclude the autokey-protocol from > further > >>> investigations. So I'd very much appreciate if you would be so > kind > >>> to comment the described attack. > >>> > >>> Thank you very much. With best regards > >>> > >>> Dr. D. Sibold > >>> S. R=F6ttger > >>> Dr. U. Grottker > >>> > >>> ----------------------------------------------- > >>> Physikalisch-Technische Bundesanstalt > >>> Q.42 - Server Administration > >>> Bundesallee 100, D-38116 Braunschweig > >>> Tel: +49-531-592-84 20 > >>> E-Mail: dieter.sibold@ptb.de=3D > >>> > --------------070904080107030801080305 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Stephen,

It would indeed avoid the problem you cite, but that would involve an expensive cryptographic computation for every server packet. This was considered in the Autokey briefing at the NTP project page, but rejected.

There might still be room for an innovative approach. However, upon close examination there are more vulnerabilities, including a cut-and-paste attack on the Autokey extension fields. The Autokey dances are not the only ones vulnerable to these attacks, but a generic solution is really hard to find.

Meanwhile, one of the things we can assume is that the client has a secure means to obtain the server public key or certificate. The same issue applies to the public identity key if used. This avoids middleman attack in the same way as a symmetric key. The issue about the cookie exchange and autokey values exchange needs to be looked at more carefully.

All this activity started with a more careful examination of the middleman issues. The Autokey project began in 1996, but was only finalized in 2005 and generally not actively pursued since the stime IETF study group in 20006. In the light of a much more aggressive intruder threat today, these issues should be examined in great detail. The lessons learned might benefit a wider community.

Dave

Stephen.roettger@ptb.de wrote:
Hello,

I want to inform you that we were able to perform our described attack
and finished a piece of proof-of-concept code, that is able to change
a clients time despite autokey is enabled. Currently, it only works
if the client starts it's NTP process after the attacker is in place,
but I think it shows the point.

We think it would be a good mitigation to modify the cookie calculation.
Instead of using the clients IP address, its public key could be used.
Consequently, the attacker would not be able to obtain the cookie for a
client without knowing the clients private key.
This would have the positive side effect, that autokey would work with
NATs and it is the only possibility that we can think of, that leaves
the server stateless and does not add requirements to the client (e.g. a
certificate from a trusted authority).
On the other hand, it would require the client, to send its public key
with every time request message.

Stephen

-----Danny Mayer <mayer@ntp.org> schrieb: -----
An: "David L. Mills" <mills@udel.edu>
Von: Danny Mayer <mayer@ntp.org>
Datum: 03.06.2011 14:32
Kopie: dieter.sibold@ptb.de, Stephen Röttger <s.roettger@tu-braunschweig.de>, hackers@ntp.org, stephen.roettger@ptb.de, NTP Working Group <ntpwg@lists.ntp.org>
Betreff: Re: [ntp:hackers] PTB: Doubt about the autokey protocol

Dieter,

There are several things going on here and I'd like to try to clarify
them. I'm copying the NTP working group since it is more relevant to
that list than hackers.

1) If you are using NTP you should be using at a minimum 3 separate
sources of NTP packets. The NTP client uses the sources to decide which
is providing the "best" (I don't want to discuss how NTP decides which
is best here) source of time. NTP continually reexamines its sources and
makes that decision regularly. If the client is not using at least 3
sources then they are not worrying about securing the time service.

2) A man-in-the-middle attack on autokey needs to intercept NTP Packets
to EVERY server it is using which is a much harder proposition. Each
such server will have its own keys that the middleman would need to manage.

3) I am not clear where the middleman gets its public key. It's not
provided in the protocol and can only be obtained Out-of-band. The
server provides keys, the client doesn't. Am I mistaken in this?

4) You say that your student was able to perform such an attack but was
he able to do it without having any information about the servers keys?

I'll have more to say when I understand this issue a little better.

Danny

On 6/2/2011 9:29 PM, David L. Mills wrote:
> Dieter,
>
> The problem I have with your scenario is how to convince the client that
> the middleman client cookie is genuine. The server provides the client
> cookie encrypted with the middleman key, but the middleman has to
> encrypt the client cookie for the client using the client key. That
> requires the response to be signed, but the middleman cannot encrypt the
> signature without the server private key.
>
> Here is another way this could be done. The middleman lives in a
> compromised router on the same Ethernet as the client. It begins by
> simply wiretapping the client cookie request, but allows the client
> request/response to complete. It then repeats the request  with its own
> key and intercepts the response without continuing to the client.
> Subsequently, it masquerades as the server and injects its own values
> while observing the on-wire protocol rules.
>
> It very well may be that the best  approach to this and similar problems
> is a suite of algorithms designed to verify the integrity of the router,
> rather than further complicate the NTP protocol design. This might be a
> topic for discussion on the hackers.ntp.org list.
>
> I'm still not satisfied with the NTP security document. It was first
> written five years ago in somewhat of a hurry as the RFC was submitted
> for review. The document does not lie, but its wording is a bit loose.
> The main thing that needs to be clarified is how the public values can
> be protected against middleman attack. It needs to be tightened and I am
> doing that. now. I will advise when it is ready for prime time.
>
> Dave
>
> dieter.sibold@ptb.de wrote:
>
>> Dave,
>> thanks for your last email.
>> I agree that the usage of the autokey procedure is quite an obstacle
>> for "normal" end users who just want to have the time from their
>> national laboratory. But that is not our primary intention. Although
>> we have quite a high access rate to out time servers the requests for
>> signed time packets is quite small. Therefore, I believe that even if
>> we provide authenticated time service to the public the usage of it
>> would be quite small. Our intention is to investigate if NTP together
>> with autokey provides an robust and secure authenticated time service
>> for applications which depend on authenticated time information by
>> requirements enforced by Germany's Verification Act. For this scenario
>> the technical obstacles of autokey are not a major problem.
>>
>> Nonetheless I also agree that it would be nice if the configuration
>> and usage would be easier.
>>
>> Thanks also for editing of the Security Analysis paper. At this point
>> we still have some issues.
>>
>> At our first question regarding the security of autokey you wrote:
>>
>>  
>>
>>> Your analysis left out one crucial fact. The server reply to the cookie
>>> request is signed by the server using its private key. The client, in
>>> possession of the server public key, can verify the authenticity of the
>>> reply.
>>>  
>>
>> That is ok. But nonetheless, my colleague - Stephen - already
>> performed a man-in-the-middle attack and he was able to compute a
>> valid Message Authentication Code (MAC) for a servers time response.
>> The attack works as follows:
>>
>> First of all the attacker (M) aims to obtain the client cookie C_C for
>> the NTP-Client C. To this end the attacker M performs a
>> man-in-the-middle attack in which he masquerades as NTP-Client C and
>> send a cookie request to the NTP-Server S together with its public key
>> P_M and the IP-address IP_C of NTP-Client C. In response M obtains the
>> client cookie C_C from the server S, which is encrypted with the
>> public key P_M of M and which is meant to be for the NTP-Client C. The
>> attacker M is able to decrypt the client cookie C_C because it is
>> encrypted with its public key P_M. Now M is in possession of the
>> client cookie C_C and will store it.
>> As of now the attacker M will change his role and will masquerade as
>> NTP-Server S. When C sends a time request to the NTP-Server S it will
>> be intercepted by M. Because M stored the client cookie C_C he is now
>> able to verify the client request and to construct a timestamp
>> response with a valid MAC.
>>
>> The problem arises because the NTP packet is bound to the client
>> cookie C_C in which the client identity is only reflected by the
>> clients IP-address IP_C. Therefore M is able to gain possession of the
>> client cookie for C by means of a man-in-the-middle attack.
>>
>>
>> In the moment we do not know if the attacker M is now able to change
>> the time of the client C; but Stephen is investigating this question.
>>
>> Obviously we have to emphasize that this scenario is only possible if
>> the attacker M is able to introduce himself into the communication
>> line between client C and server S.
>>
>> With best regards
>> Dieter
>> -----------------------------------------------
>> Physikalisch-Technische Bundesanstalt
>> Q.42 - Server Administration
>> Bundesallee 100, D-38116 Braunschweig
>> Tel: +49-531-592-84 20
>> E-Mail: dieter.sibold@ptb.de
>>
>> -----"David L. Mills" <mills@udel.edu> schrieb: -----
>> An: dieter.sibold@ptb.de
>> Von: "David L. Mills" <mills@udel.edu>
>> Datum: 30.05.2011 02:26AM
>> Kopie: stenn@ntp.org
>> Betreff: Re: PTB: Doubt about the autokey protocol
>>
>> Dieter,,
>>
>> It looks like the NTP Security Analysis needs some work. I have edited
>> the page and brought it up to date. See especially sections 4 and 5.
>> One issue is whether or not the identity scheme is necessary; for
>> protection from middleman attack; I believe it is. However, there are
>> some rough edges for a national laboratory deployment. A client needs
>> to have the OpenSSL cryptographic library, as well as the Autokey
>> configuration selected at build time. I'm not sure this will be
>> acceptable on a widespread deployment.
>>
>> Another issue that needs to be resolved is whether the client needs to
>> generate host or signature keys and whether a client certificate is
>> necessary. If the client has no dependent clients, it does not need
>> these things, but the current implementation requires them, even if
>> they are not used. What needs here is some software grooming to ease
>> the configuration and deployment on a national scale. This is not hard
>> and could in principle be done by the Google software corps.
>>
>> Dave
>>
>> dieter.sibold@ptb.de wrote:
>>
>>  
>>
>>> Dear Prof. Mills and Mr. Stenn,
>>>
>>> I am writing this email because I have a couple of open questions
>>> regarding the security of the autokey protocol.
>>>
>>> First, let me start to explain what we want to achieve by means of
>>> autokey.
>>> The PTB is Germany's national metrology institute. The dissemination
>>> of  time is one of our legal tasks. Since many years this is done via
>>> long-wave transmitter DCF77 and since 1999 we also provide publicely
>>> accessible NTP time servers for the dissemination of UTC(PTB)
>>> successfully.
>>> Within the scope of the new emerging smart grids in energy
>>> distribution systems we are investigating if we could enhance our
>>> time service  in order to provide securely  authenticated time to the
>>> operators of energy distribution networks.  To this end we
>>> investigate if NTP together with the autokey-protocol is
>>> cryptographically sufficient to meet the requirements which are
>>> enforced by Germany's Verification Act.
>>>
>>> After the study of RFC5906 and recording of the communication
>>> messages between NTP-client and NTP-server our student was able to
>>> perform a man-in-the-middle attack. As a consequence he was able to
>>> masquerade as server. You will find the  procedure  described in the
>>> enclosed attachment.
>>> If the described man-in-the-middle attack really breaks the
>>> authentication we have to exclude the autokey-protocol from further
>>> investigations. So I'd very much appreciate if you would be so kind
>>> to comment the described attack.
>>>
>>> Thank you very much. With best regards
>>>
>>> Dr. D. Sibold
>>> S. Röttger
>>> Dr. U. Grottker
>>>
>>> -----------------------------------------------
>>> Physikalisch-Technische Bundesanstalt
>>> Q.42 - Server Administration
>>> Bundesallee 100, D-38116 Braunschweig
>>> Tel: +49-531-592-84 20
>>> E-Mail: dieter.sibold@ptb.de=
>>>

--------------070904080107030801080305-- --===============2812588115849372223== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg --===============2812588115849372223==-- From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Wed Jun 8 22:02:04 2011 Return-Path: X-Original-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8914611E808D for ; Wed, 8 Jun 2011 22:02:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.098 X-Spam-Level: X-Spam-Status: No, score=-105.098 tagged_above=-999 required=5 tests=[AWL=1.500, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FasWaQWrMcub for ; Wed, 8 Jun 2011 22:01:59 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [IPv6:2001:4f8:fff7:1::7]) by ietfa.amsl.com (Postfix) with ESMTP id 2678511E8074 for ; Wed, 8 Jun 2011 22:01:57 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id 05A6C86DAF3 for ; Thu, 9 Jun 2011 05:01:55 +0000 (UTC) X-Original-To: ntpwg@lists.ntp.org Delivered-To: ntpwg@lists.ntp.org Received: from mail1.ntp.org (mail1.ntp.org [IPv6:2001:4f8:fff7:1::5]) by lists.ntp.org (Postfix) with ESMTP id 7E80B86D760 for ; Thu, 9 Jun 2011 03:10:11 +0000 (UTC) Received: from mail-vw0-f41.google.com ([209.85.212.41]) by mail1.ntp.org with esmtps (TLSv1:RC4-SHA:128) (Exim 4.75 (FreeBSD)) (envelope-from ) id 1QUVd4-000OBf-GR for ntpwg@lists.ntp.org; Thu, 09 Jun 2011 03:10:11 +0000 Received: by vws4 with SMTP id 4so1265535vws.14 for ; Wed, 08 Jun 2011 20:09:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:reply-to:user-agent :mime-version:to:subject:content-type; bh=ftpLFoHtYUuQo6IOs2p6vjv0MMKIVp7izm3JcdwrQ9I=; b=S1daO9etuunm2mfEJX2JV9lwJSQcwKPl8IktmR2AfDqaTgPWzDPHoNvksuwKi8yA26 nNzjx+VGx8qpM7aEfZQ4gonIQ9iii1y5UmfOuJURuiAzUIICNLaS+1gMjikruDNf3SJX LYKDZ52Hc8EzwN6JW8nbRYrNJnifygPzJdkZ8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:reply-to:user-agent:mime-version:to :subject:content-type; b=B3Uz8Bw0UgUKoKxQYmsv38PgS9+k6qEagGScuUlDHB8H8zAkJ85WUVpfydMbczKIPr VOXeybbBBXhTyWLaK2i2sQojG5331ykcWzCshzIrB1nzBiahEoUAFn2AxLED5p5N5xuR nm1Q2vQj66VwasD80E8MYZpoVYQAcWP4REvEw= Received: by 10.52.98.39 with SMTP id ef7mr295847vdb.88.1307588988052; Wed, 08 Jun 2011 20:09:48 -0700 (PDT) Received: from kodonog-mac.local (d-173-44-65-143.cpe.metrocast.net [173.44.65.143]) by mx.google.com with ESMTPS id bq1sm753301vbb.10.2011.06.08.20.09.45 (version=SSLv3 cipher=OTHER); Wed, 08 Jun 2011 20:09:47 -0700 (PDT) Message-ID: <4DF03979.5070204@pobox.com> Date: Wed, 08 Jun 2011 23:09:45 -0400 From: Karen O'Donoghue User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: NTP Working Group , tictoc@ietf.org X-SA-Exim-Connect-IP: 209.85.212.41 X-SA-Exim-Rcpt-To: ntpwg@lists.ntp.org X-SA-Exim-Mail-From: kodonog@gmail.com X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) Subject: [ntpwg] Fwd: Re: Fwd: [TICTOC] reminder for remote participation in today's tictoc meeting X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: kodonog@pobox.com List-Id: IETF Working Group for Network Time Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2771636932697951184==" Sender: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Errors-To: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org This is a multi-part message in MIME format. --===============2771636932697951184== Content-Type: multipart/alternative; boundary="------------000506080008010306030001" This is a multi-part message in MIME format. --------------000506080008010306030001 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Folks, This came to me personally, and I neglected to send it on to the ntp and tictoc wg lists. My apologies for the delay. The question before us is whether or not the interleave capability should be properly documented and where the resources will come from to complete the effort. Karen -------- Original Message -------- Subject: Re: [ntpwg] Fwd: [TICTOC] reminder for remote participation in today's tictoc meeting Date: Tue, 12 Apr 2011 18:18:43 +0000 From: David L. Mills To: kodonog@pobox.com Karen, The following is in response to the ID you distributed. I offer it as a candidate for distribution to th eWG members. Dave This internet draft describes experiments using the interleaved broadcast mode recently incorporated in the NTP reference implementation. The experiments do not include the interleaved symmetric mode, which provides similar functionality in peer-to-peer configurations. For reference, these modes, their relevance to PTP and related information are discussed in detail in Chapters 15 through 17 of the book "Network Time Synchronization - the Network Time Protocol on Earth and in Space, Second Edition, CRC Press 2011, as cited on my web page www.eedis.udel.edu/~mills. However, most of the information relevant to the followings discussion can be found in the white papers at www.eecis.udel.edu/~mills/ntp.html. Of particular interest are the documents "Analysis and Simulation of the NTP On-Wire Protocol" and "Security Analysis of the NTP Protocol." Both of these documents represent an update since the book was published late last year. Readers may wonder why these documents have not been published as an update to the protocol specification RFC-5905, which would have been the expectation several years ago in the adolescent Internet. However, the effort necessary to publish an ID with figures, tables and equations is nowadays simply unacceptable. My experience with RFC-5905 and RFC-5906 over the last five years of publishing effort is not sustainable. Thus, unless some collaboration, perhaps the TICTOC working group, chose to publish them as IDs, I will not commit that adventure myself. First some nomenclature that may help in the following discussion. Timestamps captured for the clock discipline are classed as hardstamps, drivestamps and softstamps. Softstamps are captured during the course of user-space processing; they may be corrupted by operating system and device latencies, as well as transmission delays. Drivestamps are captured during the packet interrupt routines, so are much less affected by operating system scheduling and competition with other programs. Hardstamps are captured by dedicated hardware means, typically in the PHY layer of the network interface card (NIC). While the details vary, the typical intercept point is the media independent interface (MII), which monitors the frame level interface on a character by character basis. The capture means is usuallt a field-programmable gate array (FPGA) that parses the packeet, inserts timestamp data and recomputes the UDP checksum. The interleaved capability was originally not intended for NTP, but for the Proximity-1 protocol specified by the Consultive Committee on Space Data systems (CCSDS). The Proximity-1 protocol is designed for communication between spacecraft in the vicinity of Mars and for future missions in the vicinity of the Moon. Space data links are often operated at very low data rates compared to typical Ethernet links. Typical rates range from 1 kb/s to 256 kb/s with very different data rates in each direction. Due to various queuing and transmission operations, the output delay can reach 30 s, so it is imparities that timestamps be captured close to the PHY layer. In the Proximity-1 desing, hardstamps are captured upon the passage of the ASM code combination at the beginning of each transmitted frame.. Queuing and transmission delays are not the only contributors to space data link delay. Reed-Solomon and convolutional encoding delays can be a large contribution to the link delay; however, these delays are a constant contribution to the lightwave transmission delay. These contributions -- up to many seconds -- can dwarf the lightwave transmission delays. In the NTP interleaved design, drivestamps are captured in the device interrupt routine - on input immediately after the frame has been received and before copying to an input buffer; on output shortly after the frame has been transmitted and before the buffer is released for the following input or output frame. This can become rather awkward in the case of NICs of the PCNET architecture, as data are copied directly from user space to device buffers directed by DMA descriptors. Drivestamps have been used on input for many years, but for output this is possible only using the interleaved modes. The result avoids the latencies due to the message digest computation, Autokey protocol data units, output queuing and frame transmissions, typically some 10-40 microseconds. It should be obvious from the documents that a primary motivation for the NTP interleaved design was protection from network errors and intruder attack. The detailed analysis and simulation are designed to demonstrate resistance to common corruptions such as dropped or duplicate packets and possible bogus attacks. The NTP design includes a four-level security model, the lower two levels might be considered for a PTP application. This is one of the most important difference between the PTP and NTP protocol designs; however, the NTP design might be considered overkill in a sheltered, isolated Ethernet network. Careful observers may notice an interesting anomaly with the interleaved broadcast mode. The preliminary volley intended to measure the roundtrip time uses basic mode, not interleaved mode. The reason for this requires some explanation. In times of old, the dominant concern was the 6-bone, an international consortium of multicast application developers. In that context with historic multicast configurations, including DVMRP and PIM, the multicast spanning tree was far different than the unicast spanning tree. Therefore, the preliminary volley was important to estimate the offset of the multicast server to the multicast client and thus the apparent one-way delay. In principle, with adroit protocolmanship, it would be possible to change the protocol to measure the interleaved roundtrip delay, which would be more appropriate for modern high-speed Ethernet networks. Karen O'Donoghue wrote: > > > -------- Original Message -------- > Subject: [TICTOC] reminder for remote participation in today's tictoc > meeting > Date: Thu, 31 Mar 2011 09:56:35 +0200 > From: Karen O'Donoghue > Reply-To: odonoghue@isoc.org > Organization: ISOC > To: tictoc@ietf.org, NTP Working Group > > > > Folks, > > This is a reminder that the tictoc working group will meet today from > 17:40 - 19:40 CEST (15:40 - 17:40 UTC). The tools agenda for the IETF > meeting (http://tools.ietf.org/agenda/80/) has links for the drafts, > presentations, jabber chat room, and audio streaming to facilitate > remote participation. > > Regards, > Karen > > _______________________________________________ > TICTOC mailing list > TICTOC@ietf.org > https://www.ietf.org/mailman/listinfo/tictoc > > ------------------------------------------------------------------------ > > _______________________________________________ > ntpwg mailing list > ntpwg@lists.ntp.org > http://lists.ntp.org/listinfo/ntpwg --------------000506080008010306030001 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Folks,

This came to me personally, and I neglected to send it on to the ntp and tictoc wg lists. My apologies for the delay. The question before us is whether or not the interleave capability should be properly documented and where the resources will come from to complete the effort.

Karen

-------- Original Message --------
Subject: Re: [ntpwg] Fwd: [TICTOC] reminder for remote participation in today's tictoc meeting
Date: Tue, 12 Apr 2011 18:18:43 +0000
From: David L. Mills <mills@udel.edu>
To: kodonog@pobox.com


Karen,

The following is in response to the ID you distributed. I offer it as a candidate for distribution to th eWG members.

Dave

This internet draft describes experiments using the interleaved broadcast mode recently incorporated in the NTP reference implementation. The experiments do not include the interleaved symmetric mode, which provides similar functionality in peer-to-peer configurations. For reference, these modes, their relevance to PTP and related information are discussed in detail in Chapters 15 through 17 of the book "Network Time Synchronization - the Network Time Protocol on Earth and in Space, Second Edition, CRC Press 2011, as cited on my web page www.eedis.udel.edu/~mills. However, most of the information relevant to the followings discussion can be found in the white papers at www.eecis.udel.edu/~mills/ntp.html. Of particular interest are the documents "Analysis and Simulation of the NTP On-Wire Protocol" and "Security Analysis of the NTP Protocol." Both of these documents represent an update since the book was published late last year.

Readers may wonder why these documents have not been published as an update to the protocol specification RFC-5905, which would have been the expectation several years ago in the adolescent Internet. However, the effort necessary to publish an ID with figures, tables and equations is nowadays simply unacceptable. My experience with RFC-5905 and RFC-5906 over the last five years of publishing effort is not sustainable. Thus, unless some collaboration, perhaps the TICTOC working group, chose to publish them as IDs, I will not commit that adventure myself.

First some nomenclature that may help in the following discussion. Timestamps captured for the clock discipline are classed as hardstamps, drivestamps and softstamps. Softstamps are captured during the course of user-space processing; they may be corrupted by operating system and device latencies, as well as transmission delays. Drivestamps are captured during the packet interrupt routines, so are much less affected by operating system scheduling and competition with other programs. Hardstamps are captured by dedicated hardware means, typically in the PHY layer of the network interface card (NIC). While the details vary, the typical intercept point is the media independent interface (MII), which monitors the frame level interface on a character by character basis. The capture means is usuallt a field-programmable gate array (FPGA) that parses the packeet, inserts timestamp data and recomputes the UDP checksum.

The interleaved capability was originally not intended for NTP, but for the Proximity-1 protocol specified by the Consultive Committee on Space Data systems (CCSDS). The Proximity-1 protocol is designed for communication between spacecraft in the vicinity of Mars and for future missions in the vicinity of the Moon. Space data links are often operated at very low data rates compared to typical Ethernet links. Typical rates range from 1 kb/s to 256 kb/s with very different data rates in each direction. Due to various queuing and transmission operations, the output delay can reach 30 s, so it is imparities that timestamps be captured close to the PHY layer. In the Proximity-1 desing, hardstamps are captured upon the passage of the ASM code combination at the beginning of each transmitted frame..

Queuing and transmission delays are not the only contributors to space data link delay. Reed-Solomon and convolutional encoding delays can be a large contribution to the link delay; however, these delays are a constant contribution to the lightwave transmission delay. These contributions – up to many seconds – can dwarf the lightwave transmission delays.

In the NTP interleaved design, drivestamps are captured in the device interrupt routine - on input immediately after the frame has been received and before copying to an input buffer; on output shortly after the frame has been transmitted and before the buffer is released for the following input or output frame. This can become rather awkward in the case of NICs of the PCNET architecture, as data are copied directly from user space to device buffers directed by DMA descriptors. Drivestamps have been used on input for many years, but for output this is possible only using the interleaved modes. The result avoids the latencies due to the message digest computation, Autokey protocol data units, output queuing and frame transmissions, typically some 10-40 microseconds.

It should be obvious from the documents that a primary motivation for the NTP interleaved design was protection from network errors and intruder attack. The detailed analysis and simulation are designed to demonstrate resistance to common corruptions such as dropped or duplicate packets and possible bogus attacks. The NTP design includes a four-level security model, the lower two levels might be considered for a PTP application. This is one of the most important difference between the PTP and NTP protocol designs; however, the NTP design might be considered overkill in a sheltered, isolated Ethernet network.

Careful observers may notice an interesting anomaly with the interleaved broadcast mode. The preliminary volley intended to measure the roundtrip time uses basic mode, not interleaved mode. The reason for this requires some explanation. In times of old, the dominant concern was the 6-bone, an international consortium of multicast application developers. In that context with historic multicast configurations, including DVMRP and PIM, the multicast spanning tree was far different than the unicast spanning tree. Therefore, the preliminary volley was important to estimate the offset of the multicast server to the multicast client and thus the apparent one-way delay. In principle, with adroit protocolmanship, it would be possible to change the protocol to measure the interleaved roundtrip delay, which would be more appropriate for modern high-speed Ethernet networks.

Karen O'Donoghue wrote:


-------- Original Message --------
Subject: [TICTOC] reminder for remote participation in today's tictoc meeting
Date: Thu, 31 Mar 2011 09:56:35 +0200
From: Karen O'Donoghue <odonoghue@isoc.org>
Reply-To: odonoghue@isoc.org
Organization: ISOC
To: tictoc@ietf.org, NTP Working Group <ntpwg@lists.ntp.org> 


Folks,

This is a reminder that the tictoc working group will meet today from 
17:40 - 19:40 CEST (15:40 - 17:40 UTC). The tools agenda for the IETF 
meeting (http://tools.ietf.org/agenda/80/) has links for the drafts, 
presentations, jabber chat room, and audio streaming to facilitate 
remote participation.

Regards,
Karen

_______________________________________________
TICTOC mailing list
TICTOC@ietf.org
https://www.ietf.org/mailman/listinfo/tictoc
  

_______________________________________________
ntpwg mailing list
ntpwg@lists.ntp.org
http://lists.ntp.org/listinfo/ntpwg

--------------000506080008010306030001-- --===============2771636932697951184== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg --===============2771636932697951184==-- From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Thu Jun 9 00:01:46 2011 Return-Path: X-Original-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D58411E8074 for ; Thu, 9 Jun 2011 00:01:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3JQCJoajfPlG for ; Thu, 9 Jun 2011 00:01:45 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [IPv6:2001:4f8:fff7:1::7]) by ietfa.amsl.com (Postfix) with ESMTP id 18A401F0C35 for ; Thu, 9 Jun 2011 00:01:44 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id D128C86D77D for ; Thu, 9 Jun 2011 07:01:42 +0000 (UTC) X-Original-To: ntpwg@lists.ntp.org Delivered-To: ntpwg@lists.ntp.org Received: from stenn.ntp.org (stenn.ntp.org [IPv6:2001:4f8:fff7:1::30]) by lists.ntp.org (Postfix) with ESMTP id AC89B86D762 for ; Thu, 9 Jun 2011 05:39:18 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=stenn.ntp.org) by stenn.ntp.org with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QUXxc-0006iQ-Aj; Wed, 08 Jun 2011 22:39:16 -0700 To: kodonog@pobox.com In-reply-to: <4DF03979.5070204@pobox.com> References: <4DF03979.5070204@pobox.com> Comments: In-reply-to Karen O'Donoghue message dated "Wed, 08 Jun 2011 23:09:45 -0400." X-Mailer: MH-E 7.4.2; nmh 1.2; XEmacs 21.4 (patch 22) Mime-Version: 1.0 (generated by tm-edit 1.8) Date: Wed, 08 Jun 2011 22:39:16 -0700 From: Harlan Stenn Message-Id: Cc: NTP Working Group , tictoc@ietf.org Subject: Re: [ntpwg] Fwd: Re: Fwd: [TICTOC] reminder for remote participation in today's tictoc meeting X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Working Group for Network Time Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Errors-To: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Karen wrote: > The question before us is whether or not the interleave capability > should be properly documented Yes > and where the resources will come from to complete the effort. Good question. H _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Thu Jun 9 06:31:59 2011 Return-Path: X-Original-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BB0A11E80BA for ; Thu, 9 Jun 2011 06:31:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OsSXxk9yqv4p for ; Thu, 9 Jun 2011 06:31:58 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [IPv6:2001:4f8:fff7:1::7]) by ietfa.amsl.com (Postfix) with ESMTP id 26C9F11E808F for ; Thu, 9 Jun 2011 06:31:52 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id CE16286DB21 for ; Thu, 9 Jun 2011 13:31:50 +0000 (UTC) X-Original-To: ntpwg@lists.ntp.org Delivered-To: ntpwg@lists.ntp.org Received: from mail1.ntp.org (mail1.ntp.org [IPv6:2001:4f8:fff7:1::5]) by lists.ntp.org (Postfix) with ESMTP id 5B2C586D762 for ; Thu, 9 Jun 2011 11:53:49 +0000 (UTC) Received: from [198.22.153.9] (helo=[10.60.111.31]) by mail1.ntp.org with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.75 (FreeBSD)) (envelope-from ) id 1QUdnr-0008Bc-U8; Thu, 09 Jun 2011 11:53:47 +0000 Message-ID: <4DF0B423.2030504@ntp.org> Date: Thu, 09 Jun 2011 07:53:07 -0400 From: Danny Mayer User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: kodonog@pobox.com References: <4DF03979.5070204@pobox.com> In-Reply-To: <4DF03979.5070204@pobox.com> X-Enigmail-Version: 1.1.1 X-SA-Exim-Connect-IP: 198.22.153.9 X-SA-Exim-Rcpt-To: kodonog@pobox.com, ntpwg@lists.ntp.org, tictoc@ietf.org, mills@udel.edu X-SA-Exim-Mail-From: mayer@ntp.org X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) Cc: NTP Working Group , tictoc@ietf.org Subject: Re: [ntpwg] Fwd: Re: Fwd: [TICTOC] reminder for remote participation in today's tictoc meeting X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Working Group for Network Time Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable Sender: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Errors-To: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org It's not just interleave capability that needs to be added, but also: 1) mode 6 (public) command control packets which is documented in RFC 1305 but got dropped when obsoleting it; 2) add support for SHA-nnn to replace MD5 for FIPS compliance (see Rich Schmidt's bug report); 3) The work your former group has been doing that was presented at the last IETF meeting in Prague, if it's worth standardizing. I seem to remember a few other issues that we had discussed but I can't think of them right now. Danny On 6/8/2011 11:09 PM, Karen O'Donoghue wrote: > Folks, > = > This came to me personally, and I neglected to send it on to the ntp and > tictoc wg lists. My apologies for the delay. The question before us is > whether or not the interleave capability should be properly documented > and where the resources will come from to complete the effort. > = > Karen > = > -------- Original Message -------- > Subject: Re: [ntpwg] Fwd: [TICTOC] reminder for remote participation in > today's tictoc meeting > Date: Tue, 12 Apr 2011 18:18:43 +0000 > From: David L. Mills > To: kodonog@pobox.com > = > = > = > Karen, > = > The following is in response to the ID you distributed. I offer it as a > candidate for distribution to th eWG members. > = > Dave > = > This internet draft describes experiments using the interleaved > broadcast mode recently incorporated in the NTP reference > implementation. The experiments do not include the interleaved symmetric > mode, which provides similar functionality in peer-to-peer > configurations. For reference, these modes, their relevance to PTP and > related information are discussed in detail in Chapters 15 through 17 of > the book "Network Time Synchronization - the Network Time Protocol on > Earth and in Space, Second Edition, CRC Press 2011, as cited on my web > page www.eedis.udel.edu/~mills. However, most of the information > relevant to the followings discussion can be found in the white papers > at www.eecis.udel.edu/~mills/ntp.html. Of particular interest are the > documents "Analysis and Simulation of the NTP On-Wire Protocol" and > "Security Analysis of the NTP Protocol." Both of these documents > represent an update since the book was published late last year. > = > Readers may wonder why these documents have not been published as an > update to the protocol specification RFC-5905, which would have been the > expectation several years ago in the adolescent Internet. However, the > effort necessary to publish an ID with figures, tables and equations is > nowadays simply unacceptable. My experience with RFC-5905 and RFC-5906 > over the last five years of publishing effort is not sustainable. Thus, > unless some collaboration, perhaps the TICTOC working group, chose to > publish them as IDs, I will not commit that adventure myself. > = > First some nomenclature that may help in the following discussion. > Timestamps captured for the clock discipline are classed as hardstamps, > drivestamps and softstamps. Softstamps are captured during the course of > user-space processing; they may be corrupted by operating system and > device latencies, as well as transmission delays. Drivestamps are > captured during the packet interrupt routines, so are much less affected > by operating system scheduling and competition with other programs. > Hardstamps are captured by dedicated hardware means, typically in the > PHY layer of the network interface card (NIC). While the details vary, > the typical intercept point is the media independent interface (MII), > which monitors the frame level interface on a character by character > basis. The capture means is usuallt a field-programmable gate array > (FPGA) that parses the packeet, inserts timestamp data and recomputes > the UDP checksum. > = > The interleaved capability was originally not intended for NTP, but for > the Proximity-1 protocol specified by the Consultive Committee on Space > Data systems (CCSDS). The Proximity-1 protocol is designed for > communication between spacecraft in the vicinity of Mars and for future > missions in the vicinity of the Moon. Space data links are often > operated at very low data rates compared to typical Ethernet links. > Typical rates range from 1 kb/s to 256 kb/s with very different data > rates in each direction. Due to various queuing and transmission > operations, the output delay can reach 30 s, so it is imparities that > timestamps be captured close to the PHY layer. In the Proximity-1 > desing, hardstamps are captured upon the passage of the ASM code > combination at the beginning of each transmitted frame.. > = > Queuing and transmission delays are not the only contributors to space > data link delay. Reed-Solomon and convolutional encoding delays can be a > large contribution to the link delay; however, these delays are a > constant contribution to the lightwave transmission delay. These > contributions =96 up to many seconds =96 can dwarf the lightwave > transmission delays. > = > In the NTP interleaved design, drivestamps are captured in the device > interrupt routine - on input immediately after the frame has been > received and before copying to an input buffer; on output shortly after > the frame has been transmitted and before the buffer is released for the > following input or output frame. This can become rather awkward in the > case of NICs of the PCNET architecture, as data are copied directly from > user space to device buffers directed by DMA descriptors. Drivestamps > have been used on input for many years, but for output this is possible > only using the interleaved modes. The result avoids the latencies due to > the message digest computation, Autokey protocol data units, output > queuing and frame transmissions, typically some 10-40 microseconds. > = > It should be obvious from the documents that a primary motivation for > the NTP interleaved design was protection from network errors and > intruder attack. The detailed analysis and simulation are designed to > demonstrate resistance to common corruptions such as dropped or > duplicate packets and possible bogus attacks. The NTP design includes a > four-level security model, the lower two levels might be considered for > a PTP application. This is one of the most important difference between > the PTP and NTP protocol designs; however, the NTP design might be > considered overkill in a sheltered, isolated Ethernet network. > = > Careful observers may notice an interesting anomaly with the interleaved > broadcast mode. The preliminary volley intended to measure the roundtrip > time uses basic mode, not interleaved mode. The reason for this requires > some explanation. In times of old, the dominant concern was the 6-bone, > an international consortium of multicast application developers. In that > context with historic multicast configurations, including DVMRP and PIM, > the multicast spanning tree was far different than the unicast spanning > tree. Therefore, the preliminary volley was important to estimate the > offset of the multicast server to the multicast client and thus the > apparent one-way delay. In principle, with adroit protocolmanship, it > would be possible to change the protocol to measure the interleaved > roundtrip delay, which would be more appropriate for modern high-speed > Ethernet networks. > = > Karen O'Donoghue wrote: >> >> >> -------- Original Message -------- >> Subject: [TICTOC] reminder for remote participation in today's tictoc >> meeting >> Date: Thu, 31 Mar 2011 09:56:35 +0200 >> From: Karen O'Donoghue >> Reply-To: odonoghue@isoc.org >> Organization: ISOC >> To: tictoc@ietf.org, NTP Working Group >> >> >> >> Folks, >> >> This is a reminder that the tictoc working group will meet today from = >> 17:40 - 19:40 CEST (15:40 - 17:40 UTC). The tools agenda for the IETF = >> meeting (http://tools.ietf.org/agenda/80/) has links for the drafts, = >> presentations, jabber chat room, and audio streaming to facilitate = >> remote participation. >> >> Regards, >> Karen _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Thu Jun 9 15:30:27 2011 Return-Path: X-Original-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD8A221F846A for ; Thu, 9 Jun 2011 15:30:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tISF-wrnFjWC for ; Thu, 9 Jun 2011 15:30:26 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [IPv6:2001:4f8:fff7:1::7]) by ietfa.amsl.com (Postfix) with ESMTP id 6EFDC21F844E for ; Thu, 9 Jun 2011 15:30:09 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id 85EF286D777 for ; Thu, 9 Jun 2011 22:30:07 +0000 (UTC) X-Original-To: ntpwg@lists.ntp.org Delivered-To: ntpwg@lists.ntp.org Received: from mail1.ntp.org (mail1.ntp.org [IPv6:2001:4f8:fff7:1::5]) by lists.ntp.org (Postfix) with ESMTP id 5E0DC86D765 for ; Thu, 9 Jun 2011 20:38:45 +0000 (UTC) Received: from naeanrfkax02o.nmci.navy.mil ([138.162.5.138]) by mail1.ntp.org with esmtp (Exim 4.75 (FreeBSD)) (envelope-from ) id 1QUlzs-000FBD-KC for ntpwg@lists.ntp.org; Thu, 09 Jun 2011 20:38:45 +0000 X-AuditID: 8aa20589-b7c4eae000003e46-e2-4df12f3bc03d Received: from naeanrfkeg01v.nadsusea.nads.navy.mil (gate5-norfolk.nmci.navy.mil [138.162.0.45]) by (Symantec Mail Security) with SMTP id 97.62.15942.B3F21FD4; Thu, 9 Jun 2011 20:38:19 +0000 (GMT) Received: from naeanrfkeb04v.nadsusea.nads.navy.mil ([10.16.20.107]) by naeanrfkeg01v.nadsusea.nads.navy.mil with Microsoft SMTPSVC(6.0.3790.4675); Thu, 9 Jun 2011 16:38:26 -0400 Received: from naeanrfkeb03v.nadsusea.nads.navy.mil ([10.16.20.106]) by naeanrfkeb04v.nadsusea.nads.navy.mil with Microsoft SMTPSVC(6.0.3790.4675); Thu, 9 Jun 2011 16:38:25 -0400 Received: from naeamillez04v.nadsusea.nads.navy.mil ([10.16.20.64]) by naeanrfkeb03v.nadsusea.nads.navy.mil with Microsoft SMTPSVC(6.0.3790.4675); Thu, 9 Jun 2011 16:38:25 -0400 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 9 Jun 2011 16:38:24 -0400 Message-ID: In-Reply-To: <4DF0B423.2030504@ntp.org> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [TICTOC] [ntpwg] Fwd: Re: Fwd: reminder for remote participation in today's tictoc meeting Thread-Index: Acwmm++lgU0oHF2vTxGX2l02P6QKpAARsfPw References: <4DF03979.5070204@pobox.com> <4DF0B423.2030504@ntp.org> From: "Marlow, David T CIV NSWCDD, W64" To: "Danny Mayer" , X-OriginalArrivalTime: 09 Jun 2011 20:38:25.0429 (UTC) FILETIME=[2E5FAC50:01CC26E5] X-Brightmail-Tracker: AAAAAA== X-SA-Exim-Connect-IP: 138.162.5.138 X-SA-Exim-Rcpt-To: ntpwg@lists.ntp.org X-SA-Exim-Mail-From: david.marlow@navy.mil X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) Cc: NTP Working Group , tictoc@ietf.org Subject: Re: [ntpwg] [TICTOC] Fwd: Re: Fwd: reminder for remote participation in today's tictoc meeting X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Working Group for Network Time Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1979552832198649668==" Sender: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Errors-To: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org This is a multi-part message in MIME format. --===============1979552832198649668== Content-class: urn:content-classes:message Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_1812_01CC26C3.9414C890" This is a multi-part message in MIME format. ------=_NextPart_000_1812_01CC26C3.9414C890 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Danny and All, The work Tim Plunkett discussed at the last IETF meeting in Prague (draft-marlow-tictoc-computer-clock-accuracy-00.txt) included some results from preliminary experiments with NTP Interleave that is in NTP version 4.2.6. We got some modest improvements over previous experiments which used earlier NTP versions without Interleave. Further experimentation is needed, but we were wondering if others have data that Interleave provides a sufficient increase in performance (or another category) to standardize it? Dave -----Original Message----- From: tictoc-bounces@ietf.org [mailto:tictoc-bounces@ietf.org] On Behalf Of Danny Mayer Sent: Thursday, June 09, 2011 7:53 To: kodonog@pobox.com Cc: NTP Working Group; tictoc@ietf.org; David L. Mills Subject: Re: [TICTOC] [ntpwg] Fwd: Re: Fwd: reminder for remote participation in today's tictoc meeting It's not just interleave capability that needs to be added, but also: 1) mode 6 (public) command control packets which is documented in RFC 1305 but got dropped when obsoleting it; 2) add support for SHA-nnn to replace MD5 for FIPS compliance (see Rich Schmidt's bug report); 3) The work your former group has been doing that was presented at the last IETF meeting in Prague, if it's worth standardizing. I seem to remember a few other issues that we had discussed but I can't think of them right now. Danny On 6/8/2011 11:09 PM, Karen O'Donoghue wrote: > Folks, > > This came to me personally, and I neglected to send it on to the ntp and > tictoc wg lists. My apologies for the delay. The question before us is > whether or not the interleave capability should be properly documented > and where the resources will come from to complete the effort. > > Karen > > -------- Original Message -------- > Subject: Re: [ntpwg] Fwd: [TICTOC] reminder for remote participation in > today's tictoc meeting > Date: Tue, 12 Apr 2011 18:18:43 +0000 > From: David L. Mills > To: kodonog@pobox.com > > > > Karen, > > The following is in response to the ID you distributed. I offer it as a > candidate for distribution to th eWG members. > > Dave > > This internet draft describes experiments using the interleaved > broadcast mode recently incorporated in the NTP reference > implementation. The experiments do not include the interleaved symmetric > mode, which provides similar functionality in peer-to-peer > configurations. For reference, these modes, their relevance to PTP and > related information are discussed in detail in Chapters 15 through 17 of > the book "Network Time Synchronization - the Network Time Protocol on > Earth and in Space, Second Edition, CRC Press 2011, as cited on my web > page www.eedis.udel.edu/~mills. However, most of the information > relevant to the followings discussion can be found in the white papers > at www.eecis.udel.edu/~mills/ntp.html. Of particular interest are the > documents "Analysis and Simulation of the NTP On-Wire Protocol" and > "Security Analysis of the NTP Protocol." Both of these documents > represent an update since the book was published late last year. > > Readers may wonder why these documents have not been published as an > update to the protocol specification RFC-5905, which would have been the > expectation several years ago in the adolescent Internet. However, the > effort necessary to publish an ID with figures, tables and equations is > nowadays simply unacceptable. My experience with RFC-5905 and RFC-5906 > over the last five years of publishing effort is not sustainable. Thus, > unless some collaboration, perhaps the TICTOC working group, chose to > publish them as IDs, I will not commit that adventure myself. > > First some nomenclature that may help in the following discussion. > Timestamps captured for the clock discipline are classed as hardstamps, > drivestamps and softstamps. Softstamps are captured during the course of > user-space processing; they may be corrupted by operating system and > device latencies, as well as transmission delays. Drivestamps are > captured during the packet interrupt routines, so are much less affected > by operating system scheduling and competition with other programs. > Hardstamps are captured by dedicated hardware means, typically in the > PHY layer of the network interface card (NIC). While the details vary, > the typical intercept point is the media independent interface (MII), > which monitors the frame level interface on a character by character > basis. The capture means is usuallt a field-programmable gate array > (FPGA) that parses the packeet, inserts timestamp data and recomputes > the UDP checksum. > > The interleaved capability was originally not intended for NTP, but for > the Proximity-1 protocol specified by the Consultive Committee on Space > Data systems (CCSDS). The Proximity-1 protocol is designed for > communication between spacecraft in the vicinity of Mars and for future > missions in the vicinity of the Moon. Space data links are often > operated at very low data rates compared to typical Ethernet links. > Typical rates range from 1 kb/s to 256 kb/s with very different data > rates in each direction. Due to various queuing and transmission > operations, the output delay can reach 30 s, so it is imparities that > timestamps be captured close to the PHY layer. In the Proximity-1 > desing, hardstamps are captured upon the passage of the ASM code > combination at the beginning of each transmitted frame.. > > Queuing and transmission delays are not the only contributors to space > data link delay. Reed-Solomon and convolutional encoding delays can be a > large contribution to the link delay; however, these delays are a > constant contribution to the lightwave transmission delay. These > contributions - up to many seconds - can dwarf the lightwave > transmission delays. > > In the NTP interleaved design, drivestamps are captured in the device > interrupt routine - on input immediately after the frame has been > received and before copying to an input buffer; on output shortly after > the frame has been transmitted and before the buffer is released for the > following input or output frame. This can become rather awkward in the > case of NICs of the PCNET architecture, as data are copied directly from > user space to device buffers directed by DMA descriptors. Drivestamps > have been used on input for many years, but for output this is possible > only using the interleaved modes. The result avoids the latencies due to > the message digest computation, Autokey protocol data units, output > queuing and frame transmissions, typically some 10-40 microseconds. > > It should be obvious from the documents that a primary motivation for > the NTP interleaved design was protection from network errors and > intruder attack. The detailed analysis and simulation are designed to > demonstrate resistance to common corruptions such as dropped or > duplicate packets and possible bogus attacks. The NTP design includes a > four-level security model, the lower two levels might be considered for > a PTP application. This is one of the most important difference between > the PTP and NTP protocol designs; however, the NTP design might be > considered overkill in a sheltered, isolated Ethernet network. > > Careful observers may notice an interesting anomaly with the interleaved > broadcast mode. The preliminary volley intended to measure the roundtrip > time uses basic mode, not interleaved mode. The reason for this requires > some explanation. In times of old, the dominant concern was the 6-bone, > an international consortium of multicast application developers. In that > context with historic multicast configurations, including DVMRP and PIM, > the multicast spanning tree was far different than the unicast spanning > tree. Therefore, the preliminary volley was important to estimate the > offset of the multicast server to the multicast client and thus the > apparent one-way delay. In principle, with adroit protocolmanship, it > would be possible to change the protocol to measure the interleaved > roundtrip delay, which would be more appropriate for modern high-speed > Ethernet networks. > > Karen O'Donoghue wrote: >> >> >> -------- Original Message -------- >> Subject: [TICTOC] reminder for remote participation in today's tictoc >> meeting >> Date: Thu, 31 Mar 2011 09:56:35 +0200 >> From: Karen O'Donoghue >> Reply-To: odonoghue@isoc.org >> Organization: ISOC >> To: tictoc@ietf.org, NTP Working Group >> >> >> >> Folks, >> >> This is a reminder that the tictoc working group will meet today from >> 17:40 - 19:40 CEST (15:40 - 17:40 UTC). The tools agenda for the IETF >> meeting (http://tools.ietf.org/agenda/80/) has links for the drafts, >> presentations, jabber chat room, and audio streaming to facilitate >> remote participation. >> >> Regards, >> Karen _______________________________________________ TICTOC mailing list TICTOC@ietf.org https://www.ietf.org/mailman/listinfo/tictoc ------=_NextPart_000_1812_01CC26C3.9414C890 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIRXzCCA3Aw ggJYoAMCAQICAQUwDQYJKoZIhvcNAQEFBQAwWzELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4g R292ZXJubWVudDEMMAoGA1UECxMDRG9EMQwwCgYDVQQLEwNQS0kxFjAUBgNVBAMTDURvRCBSb290 IENBIDIwHhcNMDQxMjEzMTUwMDEwWhcNMjkxMjA1MTUwMDEwWjBbMQswCQYDVQQGEwJVUzEYMBYG A1UEChMPVS5TLiBHb3Zlcm5tZW50MQwwCgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEWMBQGA1UE AxMNRG9EIFJvb3QgQ0EgMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMAswfaNO6z/ PzzWcb64dCIH7HBBFfyrQOMHqsHD2J/+2kw6vz/I2Ch7SzYBwKxFJcPSDgqPhRhkED0aE3Aqb47X 3I2Ts0EPOCHNravCPSoF01cRNw3NjFH5k+PMRkkhjhS0zcsUPjjNcjHuqxLyZeo0LlZd/+5jdctt upE0/J7z9C0cvlDEQt9ZiP9qs/qobD3LVnFxBZa7n4DlgEVZZ0Gw68OtYKSAdQYXnA70Q+CZDhv7 f/WzzLKBgrH9MsG4vkGkZLVgOlpRMIzO3kEsGUdcSRBkuXSph0GvfW66wbihv2UxOgRn+bW7jpKK AGO4seaMOF+D/1DVO6Jda7IQzGMCAwEAAaM/MD0wHQYDVR0OBBYEFEl0uwxeunr+AlTve6DGlcYJ gHCWMAsGA1UdDwQEAwIBhjAPBgNVHRMBAf8EBTADAQH/MA0GCSqGSIb3DQEBBQUAA4IBAQCYkY0/ ici79cBpcyk7Nay6swh2PXAJkumERCEBfRR2G+5RbB2NFTctezFp9JpEuK9GzDT6I8sDJxnSgyF1 K+fgG5km3IRAleio0sz2WFxm7z9KlxCCHboKot1bBiudp2RO6y4BNaS0PxOtVeTVc6hpmxHxmPIx Hm9A1Ph4n46RoG9wBJBmqgYrzuF6krV94eDRluehOi3MsZ0fBUTth5nTTRpwOcEEDOV+2fGv1yAO 8SJ6JaRzmcw/pAcnlqiile2CuRbTnguHwsHyiPVi32jfx7xpUe2xXNxUVCkPCTmarAPB2wxNrm8K ehZJ8b+R0jiU0/aVLLdsyUK2jcqQjYXZMIIEJzCCAw+gAwIBAgICYqkwDQYJKoZIhvcNAQEFBQAw XTELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4gR292ZXJubWVudDEMMAoGA1UECxMDRG9EMQww CgYDVQQLEwNQS0kxGDAWBgNVBAMTD0RPRCBFTUFJTCBDQS0yMDAeFw0wODA4MjUwMDAwMDBaFw0x MTA4MjQyMzU5NTlaMHUxCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAK BgNVBAsTA0RvRDEMMAoGA1UECxMDUEtJMQwwCgYDVQQLEwNVU04xIjAgBgNVBAMTGU1BUkxPVy5E QVZJRC5ULjEyMjk1MTc3NDcwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKclyw8dyfR6AlaS 3GZgN6qGyFKyleGJtluaEG+wZOtzChGYY9om5legIH2gE3Mx7AdV9QhT06JfvB058x9WC6eNgUOf z29hPSYjvOGnwd2t1bN3mLZhui/EGzycxOGrcZBc7LwlJTmtTp9bUR8mwzzZQ8XATYQ2VAJh9vLB lbcJAgMBAAGjggFbMIIBVzAfBgNVHSMEGDAWgBSyv24AbblASS9gCvR41XmEJakxujA/BgNVHR8E ODA2MDSgMqAwhi5odHRwOi8vY3JsLmRpc2EubWlsL2dldGNybD9ET0QlMjBFTUFJTCUyMENBLTIw MA4GA1UdDwEB/wQEAwIFIDAWBgNVHSAEDzANMAsGCWCGSAFlAgELCTAdBgNVHQ4EFgQUblIt3o8n zT4ODrEDtpIbcG6z6wswbQYIKwYBBQUHAQEEYTBfMDsGCCsGAQUFBzAChi9odHRwOi8vY3JsLmRp c2EubWlsL2dldHNpZ24/RE9EJTIwRU1BSUwlMjBDQS0yMDAgBggrBgEFBQcwAYYUaHR0cDovL29j c3AuZGlzYS5taWwwIAYDVR0RBBkwF4EVZGF2aWQubWFybG93QG5hdnkubWlsMBsGA1UdCQQUMBIw EAYIKwYBBQUHCQQxBBMCVVMwDQYJKoZIhvcNAQEFBQADggEBAGij5yb7+ORwjGR///efjMjXEt69 mlC2WYd8yURLdQh8sFoL7vnenaVP/grCJRYx3dZ6orUgsy3fuFns+aScoaJOI9POcpq3+biScx8j yF+45Egm3cCa7mOsGHVxMFhVsQKyaBjpIhVHCW8UDr5uy4I3m2tTseSzjdHaKnOav2SuS6gRqWsu 2oM4PpnxKDPoUgAqrFvwL8EchHHhJjRdrTuRY5cB8U76DERyjbSKfaTkRxQbZhgZz6qe5fIb5pVU CXEhD7T2/BabUyVvLwQzitKu50Vy2y/hl51qNxswb80jOuZvjCHo/wxbcITUjIsb6SWZLUU3l9d5 kOh5n/0tDP4wggRyMIIDWqADAgECAgJiqzANBgkqhkiG9w0BAQUFADBdMQswCQYDVQQGEwJVUzEY MBYGA1UEChMPVS5TLiBHb3Zlcm5tZW50MQwwCgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEYMBYG A1UEAxMPRE9EIEVNQUlMIENBLTIwMB4XDTA4MDgyNTAwMDAwMFoXDTExMDgyNDIzNTk1OVowdTEL MAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4gR292ZXJubWVudDEMMAoGA1UECxMDRG9EMQwwCgYD VQQLEwNQS0kxDDAKBgNVBAsTA1VTTjEiMCAGA1UEAxMZTUFSTE9XLkRBVklELlQuMTIyOTUxNzc0 NzCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAzuIvWfvM234NwZA61e6685cHFdkujDC+EFap 1z8+KB3R6Qy9kCdDoT82xq3o3kkWPlCNGE+UmzkQPqzFjOs1Su7FvVoHOHD/ia61BdaeprPpD5Ue KdEFxWJWK7zpRo6+7p3rGD/MqVMKYwhi0nJx8LKkCFJJcUh9n3MWHzidzL0CAwEAAaOCAaYwggGi MB8GA1UdIwQYMBaAFLK/bgBtuUBJL2AK9HjVeYQlqTG6MD8GA1UdHwQ4MDYwNKAyoDCGLmh0dHA6 Ly9jcmwuZGlzYS5taWwvZ2V0Y3JsP0RPRCUyMEVNQUlMJTIwQ0EtMjAwDgYDVR0PAQH/BAQDAgbA MBYGA1UdIAQPMA0wCwYJYIZIAWUCAQsJMB0GA1UdDgQWBBTR+wwqoLEgNDHCcAt/4eWAd2VFeTBt BggrBgEFBQcBAQRhMF8wOwYIKwYBBQUHMAKGL2h0dHA6Ly9jcmwuZGlzYS5taWwvZ2V0c2lnbj9E T0QlMjBFTUFJTCUyMENBLTIwMCAGCCsGAQUFBzABhhRodHRwOi8vb2NzcC5kaXNhLm1pbDBABgNV HREEOTA3gRVkYXZpZC5tYXJsb3dAbmF2eS5taWygHgYKKwYBBAGCNxQCA6AQDA4xMjI5NTE3NzQ3 QG1pbDAbBgNVHQkEFDASMBAGCCsGAQUFBwkEMQQTAlVTMCkGA1UdJQQiMCAGCisGAQQBgjcUAgIG CCsGAQUFBwMCBggrBgEFBQcDBDANBgkqhkiG9w0BAQUFAAOCAQEAXB5mROeOH5MmltAiRLZ+EXfu S8Y/ljoxdylHrnvT+YY6KPg99DHB3p75lFXZaOK/7pi/lSYev7W0d28LQoJSHPyfgA5DQFNyt18U t+6VA157uMdyGw4dzQl0az9qevKX3Ssqa3vm0dR1kI46DVNRfHjZLsTyiOSfI6daOhOvUXyQ8Fok kmy3KxFloxGUyMFsI6rxMZps0YUwzOETZCQ9RU3lQy0aemB52q7tONA6KeRL+fKdeprlyh3cWOZL 3XBSNUDmws5NbQVkCUuJvR6rvDBmGm4KHAB+Y8yiouKKEyNIqNf+HGybMpw+CP2ygeV/qCSc4y+8 KGA2vqYcx2Kr4DCCBUYwggQuoAMCAQICASswDQYJKoZIhvcNAQEFBQAwWzELMAkGA1UEBhMCVVMx GDAWBgNVBAoTD1UuUy4gR292ZXJubWVudDEMMAoGA1UECxMDRG9EMQwwCgYDVQQLEwNQS0kxFjAU BgNVBAMTDURvRCBSb290IENBIDIwHhcNMDgwNDIzMjEwODU2WhcNMTQwNDIzMjAwODU2WjBdMQsw CQYDVQQGEwJVUzEYMBYGA1UEChMPVS5TLiBHb3Zlcm5tZW50MQwwCgYDVQQLEwNEb0QxDDAKBgNV BAsTA1BLSTEYMBYGA1UEAxMPRE9EIEVNQUlMIENBLTIwMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAtxqQiRyAC9uhuiXsLqP2LQGIVeYW0U+dyVOcpin5iEHx3Z0yJp8HMyG2R0ECIDyl 0krLu8uBT2FB0PbI7mimxvd4erQsUB3+izK2WjJ5kTBR8CFKmKkS0y50mU/m+tW4J4j4ySGgxbN9 t1aqe5dDnCA0ToGJOo48FhKMu6izjGDXebzv4Su0fJEEJ45zTkg0AuX7rrTOg53YleQU+DPfNqxO +OlSOddW5DLCTW5IN2/15UY3EmMyScJPi/40mcjs+Obfroagfz1IIGOkSS1BPv6dQnyBRuYdkuN0 0gIIVIhgK2UxqXOA+pf4ajbUgytk8M1hYeHCWJS2yuIxstkaYQIDAQABo4ICETCCAg0wDgYDVR0P AQH/BAQDAgGGMB8GA1UdIwQYMBaAFEl0uwxeunr+AlTve6DGlcYJgHCWMB0GA1UdDgQWBBSyv24A bblASS9gCvR41XmEJakxujAMBgNVHSQEBTADgAEAMBIGA1UdEwEB/wQIMAYBAf8CAQAwVwYDVR0g BFAwTjALBglghkgBZQIBCwUwCwYJYIZIAWUCAQsJMAsGCWCGSAFlAgELCjALBglghkgBZQIBCxIw CwYJYIZIAWUCAQsTMAsGCWCGSAFlAgELFDA/BgNVHR8EODA2MDSgMqAwhi5odHRwOi8vY3JsLmRp c2EubWlsL2dldGNybD9Eb0QlMjBSb290JTIwQ0ElMjAyMIH+BggrBgEFBQcBAQSB8TCB7jA/Bggr BgEFBQcwAoYzaHR0cDovL2NybC5kaXNhLm1pbC9nZXRJc3N1ZWRUbz9Eb0QlMjBSb290JTIwQ0El MjAyMCAGCCsGAQUFBzABhhRodHRwOi8vb2NzcC5kaXNhLm1pbDCBiAYIKwYBBQUHMAKGfGxkYXA6 Ly9jcmwuZ2RzLmRpc2EubWlsL2NuJTNkRG9EJTIwUm9vdCUyMENBJTIwMiUyY291JTNkUEtJJTJj b3UlM2REb0QlMmNvJTNkVS5TLiUyMEdvdmVybm1lbnQlMmNjJTNkVVM/Y0FDZXJ0aWZpY2F0ZTti aW5hcnkwDQYJKoZIhvcNAQEFBQADggEBAG0FZT/B2dXxsgbWCM2O5Yug5kYCfaWmZJsvExK0AZih 9Yw6gUsFI6btzeuwBStEMU4E121DHdopUav5wa+WdOFoHkhPTly8yrAkQ6LsQCsRAtsII1yVvDV2 NdBisXby2Tn/wLXYqNuuoWn6pf5d9D4FtQyF98w+0MKwRFsJw+aDXM4uS3UoqfjtWCyWS50mBr12 ho03JCRUHc/MF1EI8IaSfEe/t+37OF0Ubi7qU9Oq4a77JpD0+vTvWWt1by8oWZsfHr7Xnd6uVV0r FJ8WmgtwhvORQtMjaKLyvzY3rxS6gG9hRzK+h0x3eW6oWczEFxQ5I72uIZz9ubr4c9zgpxoxggKu MIICqgIBATBjMF0xCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNV BAsTA0RvRDEMMAoGA1UECxMDUEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwgQ0EtMjACAmKrMAkGBSsO AwIaBQCgggGhMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDYw OTIwMzc1M1owIwYJKoZIhvcNAQkEMRYEFIXKDfem+nFgdJxYrNRIlJkluMqrMFgGCSqGSIb3DQEJ DzFLMEkwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAoGCCqGSIb3DQIFMHIGCSsGAQQBgjcQBDFlMGMwXTELMAkGA1UEBhMCVVMxGDAW BgNVBAoTD1UuUy4gR292ZXJubWVudDEMMAoGA1UECxMDRG9EMQwwCgYDVQQLEwNQS0kxGDAWBgNV BAMTD0RPRCBFTUFJTCBDQS0yMAICYqkwdAYLKoZIhvcNAQkQAgsxZaBjMF0xCzAJBgNVBAYTAlVT MRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoGA1UECxMDUEtJMRgw FgYDVQQDEw9ET0QgRU1BSUwgQ0EtMjACAmKpMA0GCSqGSIb3DQEBAQUABIGAHAy/bJvVMEI38Y6D LJJCDTJ2ATh2PX1ip+/Z8EmzJT36ycQdrFobwht6Kqf+BONEON5sq5+v5YolRJabix+Bu9BPeJg/ GtHqdEWbv/FvGc16kDAI7JeeYl4E0Ia17RFxlfy8eQHG8QGi/eHA2cspr07mAQcI2SbIQx1YznFt wk0AAAAAAAA= ------=_NextPart_000_1812_01CC26C3.9414C890-- --===============1979552832198649668== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg --===============1979552832198649668==-- From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Thu Jun 9 16:14:06 2011 Return-Path: X-Original-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC85F1F0C5D for ; Thu, 9 Jun 2011 16:14:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.099 X-Spam-Level: X-Spam-Status: No, score=-105.099 tagged_above=-999 required=5 tests=[AWL=1.500, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HighmyG8tGe2 for ; Thu, 9 Jun 2011 16:14:03 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [IPv6:2001:4f8:fff7:1::7]) by ietfa.amsl.com (Postfix) with ESMTP id 1A2B81F0C4C for ; Thu, 9 Jun 2011 16:14:02 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id 7D20E86DBAC for ; Thu, 9 Jun 2011 23:14:00 +0000 (UTC) X-Original-To: ntpwg@lists.ntp.org Delivered-To: ntpwg@lists.ntp.org Received: from mail1.ntp.org (mail1.ntp.org [IPv6:2001:4f8:fff7:1::5]) by lists.ntp.org (Postfix) with ESMTP id 5110886D765 for ; Thu, 9 Jun 2011 22:12:21 +0000 (UTC) Received: from mail-vx0-f169.google.com ([209.85.220.169]) by mail1.ntp.org with esmtps (TLSv1:RC4-SHA:128) (Exim 4.75 (FreeBSD)) (envelope-from ) id 1QUnSR-000PXN-Ew for ntpwg@lists.ntp.org; Thu, 09 Jun 2011 22:12:21 +0000 Received: by vxk20 with SMTP id 20so2251212vxk.14 for ; Thu, 09 Jun 2011 15:12:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:reply-to:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=qAG/v3eE4sNiXnZNwQFGU1hE//Q2gHt8tqEVeiX/lnw=; b=s9KeMbqtiUGdpepqA6nZ9itRIlk2bAYPK2TqaveVPWkvsy5lKjdQYN9Gb0nr6EVr9B vnQ0Zb0Mm1sFDi5Yw3Tl8F0OwXz0yauSTwnsephNPSKArY+O25AxLRRdCsvI7XdMeHgR qm8yMX2aaMkg94PfUh/8fl/HaqA835/RxzXp8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:reply-to:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=S0w2nB0scpzwJ4+QcynVsh+5pAn/RiU7ItV94LXF+qp0g+oLdVObtgmqFfk/e3T4+F r7wcXUC2J8mmwBcO495X+QFvLVhgKV/UlabaTi4shD4NMDrVA3yxRWDn1BJphFHXKofB BJ51z7EVeaskkIJ1YwRbUTto5ViLHCNXF2u2Y= Received: by 10.52.107.132 with SMTP id hc4mr1835497vdb.30.1307657520878; Thu, 09 Jun 2011 15:12:00 -0700 (PDT) Received: from kodonog-mac.local ([64.202.138.67]) by mx.google.com with ESMTPS id l15sm756637vdt.22.2011.06.09.15.11.57 (version=SSLv3 cipher=OTHER); Thu, 09 Jun 2011 15:11:59 -0700 (PDT) Message-ID: <4DF1452C.1010704@pobox.com> Date: Thu, 09 Jun 2011 18:11:56 -0400 From: Karen O'Donoghue User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Danny Mayer References: <4DF03979.5070204@pobox.com> <4DF0B423.2030504@ntp.org> In-Reply-To: <4DF0B423.2030504@ntp.org> X-SA-Exim-Connect-IP: 209.85.220.169 X-SA-Exim-Rcpt-To: ntpwg@lists.ntp.org X-SA-Exim-Mail-From: kodonog@gmail.com X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) Cc: NTP Working Group , tictoc@ietf.org Subject: Re: [ntpwg] [TICTOC] Fwd: Re: Fwd: reminder for remote participation in today's tictoc meeting X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: kodonog@pobox.com List-Id: IETF Working Group for Network Time Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="windows-1252"; Format="flowed" Sender: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Errors-To: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Danny, You are absolutely correct. I was just referring to the forwarded = message from Dave Mills... Folks, there are a number of items that need to be done. I'd love to = have some volunteers to help work on these. Karen On 6/9/11 7:53 AM, Danny Mayer wrote: > It's not just interleave capability that needs to be added, but also: > > 1) mode 6 (public) command control packets which is documented in RFC > 1305 but got dropped when obsoleting it; > 2) add support for SHA-nnn to replace MD5 for FIPS compliance (see Rich > Schmidt's bug report); > 3) The work your former group has been doing that was presented at the > last IETF meeting in Prague, if it's worth standardizing. > > I seem to remember a few other issues that we had discussed but I can't > think of them right now. > > Danny > > On 6/8/2011 11:09 PM, Karen O'Donoghue wrote: >> Folks, >> >> This came to me personally, and I neglected to send it on to the ntp and >> tictoc wg lists. My apologies for the delay. The question before us is >> whether or not the interleave capability should be properly documented >> and where the resources will come from to complete the effort. >> >> Karen >> >> -------- Original Message -------- >> Subject: Re: [ntpwg] Fwd: [TICTOC] reminder for remote participation in >> today's tictoc meeting >> Date: Tue, 12 Apr 2011 18:18:43 +0000 >> From: David L. Mills >> To: kodonog@pobox.com >> >> >> >> Karen, >> >> The following is in response to the ID you distributed. I offer it as a >> candidate for distribution to th eWG members. >> >> Dave >> >> This internet draft describes experiments using the interleaved >> broadcast mode recently incorporated in the NTP reference >> implementation. The experiments do not include the interleaved symmetric >> mode, which provides similar functionality in peer-to-peer >> configurations. For reference, these modes, their relevance to PTP and >> related information are discussed in detail in Chapters 15 through 17 of >> the book "Network Time Synchronization - the Network Time Protocol on >> Earth and in Space, Second Edition, CRC Press 2011, as cited on my web >> page www.eedis.udel.edu/~mills. However, most of the information >> relevant to the followings discussion can be found in the white papers >> at www.eecis.udel.edu/~mills/ntp.html. Of particular interest are the >> documents "Analysis and Simulation of the NTP On-Wire Protocol" and >> "Security Analysis of the NTP Protocol." Both of these documents >> represent an update since the book was published late last year. >> >> Readers may wonder why these documents have not been published as an >> update to the protocol specification RFC-5905, which would have been the >> expectation several years ago in the adolescent Internet. However, the >> effort necessary to publish an ID with figures, tables and equations is >> nowadays simply unacceptable. My experience with RFC-5905 and RFC-5906 >> over the last five years of publishing effort is not sustainable. Thus, >> unless some collaboration, perhaps the TICTOC working group, chose to >> publish them as IDs, I will not commit that adventure myself. >> >> First some nomenclature that may help in the following discussion. >> Timestamps captured for the clock discipline are classed as hardstamps, >> drivestamps and softstamps. Softstamps are captured during the course of >> user-space processing; they may be corrupted by operating system and >> device latencies, as well as transmission delays. Drivestamps are >> captured during the packet interrupt routines, so are much less affected >> by operating system scheduling and competition with other programs. >> Hardstamps are captured by dedicated hardware means, typically in the >> PHY layer of the network interface card (NIC). While the details vary, >> the typical intercept point is the media independent interface (MII), >> which monitors the frame level interface on a character by character >> basis. The capture means is usuallt a field-programmable gate array >> (FPGA) that parses the packeet, inserts timestamp data and recomputes >> the UDP checksum. >> >> The interleaved capability was originally not intended for NTP, but for >> the Proximity-1 protocol specified by the Consultive Committee on Space >> Data systems (CCSDS). The Proximity-1 protocol is designed for >> communication between spacecraft in the vicinity of Mars and for future >> missions in the vicinity of the Moon. Space data links are often >> operated at very low data rates compared to typical Ethernet links. >> Typical rates range from 1 kb/s to 256 kb/s with very different data >> rates in each direction. Due to various queuing and transmission >> operations, the output delay can reach 30 s, so it is imparities that >> timestamps be captured close to the PHY layer. In the Proximity-1 >> desing, hardstamps are captured upon the passage of the ASM code >> combination at the beginning of each transmitted frame.. >> >> Queuing and transmission delays are not the only contributors to space >> data link delay. Reed-Solomon and convolutional encoding delays can be a >> large contribution to the link delay; however, these delays are a >> constant contribution to the lightwave transmission delay. These >> contributions =96 up to many seconds =96 can dwarf the lightwave >> transmission delays. >> >> In the NTP interleaved design, drivestamps are captured in the device >> interrupt routine - on input immediately after the frame has been >> received and before copying to an input buffer; on output shortly after >> the frame has been transmitted and before the buffer is released for the >> following input or output frame. This can become rather awkward in the >> case of NICs of the PCNET architecture, as data are copied directly from >> user space to device buffers directed by DMA descriptors. Drivestamps >> have been used on input for many years, but for output this is possible >> only using the interleaved modes. The result avoids the latencies due to >> the message digest computation, Autokey protocol data units, output >> queuing and frame transmissions, typically some 10-40 microseconds. >> >> It should be obvious from the documents that a primary motivation for >> the NTP interleaved design was protection from network errors and >> intruder attack. The detailed analysis and simulation are designed to >> demonstrate resistance to common corruptions such as dropped or >> duplicate packets and possible bogus attacks. The NTP design includes a >> four-level security model, the lower two levels might be considered for >> a PTP application. This is one of the most important difference between >> the PTP and NTP protocol designs; however, the NTP design might be >> considered overkill in a sheltered, isolated Ethernet network. >> >> Careful observers may notice an interesting anomaly with the interleaved >> broadcast mode. The preliminary volley intended to measure the roundtrip >> time uses basic mode, not interleaved mode. The reason for this requires >> some explanation. In times of old, the dominant concern was the 6-bone, >> an international consortium of multicast application developers. In that >> context with historic multicast configurations, including DVMRP and PIM, >> the multicast spanning tree was far different than the unicast spanning >> tree. Therefore, the preliminary volley was important to estimate the >> offset of the multicast server to the multicast client and thus the >> apparent one-way delay. In principle, with adroit protocolmanship, it >> would be possible to change the protocol to measure the interleaved >> roundtrip delay, which would be more appropriate for modern high-speed >> Ethernet networks. >> >> Karen O'Donoghue wrote: >>> >>> -------- Original Message -------- >>> Subject: [TICTOC] reminder for remote participation in today's tictoc >>> meeting >>> Date: Thu, 31 Mar 2011 09:56:35 +0200 >>> From: Karen O'Donoghue >>> Reply-To: odonoghue@isoc.org >>> Organization: ISOC >>> To: tictoc@ietf.org, NTP Working Group >>> >>> >>> >>> Folks, >>> >>> This is a reminder that the tictoc working group will meet today from >>> 17:40 - 19:40 CEST (15:40 - 17:40 UTC). The tools agenda for the IETF >>> meeting (http://tools.ietf.org/agenda/80/) has links for the drafts, >>> presentations, jabber chat room, and audio streaming to facilitate >>> remote participation. >>> >>> Regards, >>> Karen > _______________________________________________ > TICTOC mailing list > TICTOC@ietf.org > https://www.ietf.org/mailman/listinfo/tictoc _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Fri Jun 10 10:25:30 2011 Return-Path: X-Original-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74EBE11E80CC for ; Fri, 10 Jun 2011 10:25:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ykem3vyjtiwd for ; Fri, 10 Jun 2011 10:25:28 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [IPv6:2001:4f8:fff7:1::7]) by ietfa.amsl.com (Postfix) with ESMTP id 1C0E611E8077 for ; Fri, 10 Jun 2011 10:25:27 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id 6862586D776 for ; Fri, 10 Jun 2011 17:25:24 +0000 (UTC) X-Original-To: ntpwg@lists.ntp.org Delivered-To: ntpwg@lists.ntp.org Received: from mail1.ntp.org (mail1.ntp.org [IPv6:2001:4f8:fff7:1::5]) by lists.ntp.org (Postfix) with ESMTP id D4CFF86D761 for ; Fri, 10 Jun 2011 15:31:58 +0000 (UTC) Received: from elasmtp-masked.atl.sa.earthlink.net ([209.86.89.68]) by mail1.ntp.org with esmtp (Exim 4.75 (FreeBSD)) (envelope-from ) id 1QV3gY-000GCz-QG for ntpwg@lists.ntp.org; Fri, 10 Jun 2011 15:31:58 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=tuap5tK9u4av09/CpgppcHyUQGm7rHbJAPScQ790Rh/huw5lxp5MaGE2dqQi16gT; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [67.180.133.66] (helo=[192.168.1.101]) by elasmtp-masked.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1QV3gS-0005mC-6D for ntpwg@lists.ntp.org; Fri, 10 Jun 2011 11:31:40 -0400 Message-ID: <4DF238FA.50204@earthlink.net> Date: Fri, 10 Jun 2011 08:32:10 -0700 From: todd glassey User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: ntpwg@lists.ntp.org References: <4DF03979.5070204@pobox.com> <4DF0B423.2030504@ntp.org> <4DF1452C.1010704@pobox.com> In-Reply-To: <4DF1452C.1010704@pobox.com> X-Opacus-Archived: none X-Opacus-Archived: none X-ELNK-Trace: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec79441736638f7abb92f4580898804298c5350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 67.180.133.66 X-SA-Exim-Connect-IP: 209.86.89.68 X-SA-Exim-Rcpt-To: ntpwg@lists.ntp.org X-SA-Exim-Mail-From: tglassey@earthlink.net X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) Subject: Re: [ntpwg] [TICTOC] Fwd: Re: Fwd: reminder for remote participation in today's tictoc meeting X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Working Group for Network Time Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="windows-1252"; Format="flowed" Sender: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Errors-To: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org On 6/9/2011 3:11 PM, Karen O'Donoghue wrote: > Danny, > > You are absolutely correct. I was just referring to the forwarded = > message from Dave Mills... > > Folks, there are a number of items that need to be done. I'd love to = > have some volunteers to help work on these. > > Karen > > On 6/9/11 7:53 AM, Danny Mayer wrote: >> It's not just interleave capability that needs to be added, but also: >> >> 1) mode 6 (public) command control packets which is documented in RFC >> 1305 but got dropped when obsoleting it; >> 2) add support for SHA-nnn to replace MD5 for FIPS compliance (see Rich >> Schmidt's bug report); o I actually would like to add another interface for a HSM to handle the = specific cryptographic services. I have a couple of architectures in = mind which would allow several of the FIPS-140-2/Level 3 Token Systems = to be used with the model. >> 3) The work your former group has been doing that was presented at the >> last IETF meeting in Prague, if it's worth standardizing. >> >> I seem to remember a few other issues that we had discussed but I can't >> think of them right now. >> >> Danny >> >> On 6/8/2011 11:09 PM, Karen O'Donoghue wrote: >>> Folks, >>> >>> This came to me personally, and I neglected to send it on to the ntp = >>> and >>> tictoc wg lists. My apologies for the delay. The question before us is >>> whether or not the interleave capability should be properly documented >>> and where the resources will come from to complete the effort. >>> >>> Karen >>> >>> -------- Original Message -------- >>> Subject: Re: [ntpwg] Fwd: [TICTOC] reminder for remote = >>> participation in >>> today's tictoc meeting >>> Date: Tue, 12 Apr 2011 18:18:43 +0000 >>> From: David L. Mills >>> To: kodonog@pobox.com >>> >>> >>> >>> Karen, >>> >>> The following is in response to the ID you distributed. I offer it as a >>> candidate for distribution to th eWG members. >>> >>> Dave >>> >>> This internet draft describes experiments using the interleaved >>> broadcast mode recently incorporated in the NTP reference >>> implementation. The experiments do not include the interleaved = >>> symmetric >>> mode, which provides similar functionality in peer-to-peer >>> configurations. For reference, these modes, their relevance to PTP and >>> related information are discussed in detail in Chapters 15 through = >>> 17 of >>> the book "Network Time Synchronization - the Network Time Protocol on >>> Earth and in Space, Second Edition, CRC Press 2011, as cited on my web >>> page www.eedis.udel.edu/~mills. However, most of the information >>> relevant to the followings discussion can be found in the white papers >>> at www.eecis.udel.edu/~mills/ntp.html. Of particular interest are the >>> documents "Analysis and Simulation of the NTP On-Wire Protocol" and >>> "Security Analysis of the NTP Protocol." Both of these documents >>> represent an update since the book was published late last year. >>> >>> Readers may wonder why these documents have not been published as an >>> update to the protocol specification RFC-5905, which would have been = >>> the >>> expectation several years ago in the adolescent Internet. However, the >>> effort necessary to publish an ID with figures, tables and equations is >>> nowadays simply unacceptable. My experience with RFC-5905 and RFC-5906 >>> over the last five years of publishing effort is not sustainable. Thus, >>> unless some collaboration, perhaps the TICTOC working group, chose to >>> publish them as IDs, I will not commit that adventure myself. >>> >>> First some nomenclature that may help in the following discussion. >>> Timestamps captured for the clock discipline are classed as hardstamps, >>> drivestamps and softstamps. Softstamps are captured during the = >>> course of >>> user-space processing; they may be corrupted by operating system and >>> device latencies, as well as transmission delays. Drivestamps are >>> captured during the packet interrupt routines, so are much less = >>> affected >>> by operating system scheduling and competition with other programs. >>> Hardstamps are captured by dedicated hardware means, typically in the >>> PHY layer of the network interface card (NIC). While the details vary, >>> the typical intercept point is the media independent interface (MII), >>> which monitors the frame level interface on a character by character >>> basis. The capture means is usuallt a field-programmable gate array >>> (FPGA) that parses the packeet, inserts timestamp data and recomputes >>> the UDP checksum. >>> >>> The interleaved capability was originally not intended for NTP, but for >>> the Proximity-1 protocol specified by the Consultive Committee on Space >>> Data systems (CCSDS). The Proximity-1 protocol is designed for >>> communication between spacecraft in the vicinity of Mars and for future >>> missions in the vicinity of the Moon. Space data links are often >>> operated at very low data rates compared to typical Ethernet links. >>> Typical rates range from 1 kb/s to 256 kb/s with very different data >>> rates in each direction. Due to various queuing and transmission >>> operations, the output delay can reach 30 s, so it is imparities that >>> timestamps be captured close to the PHY layer. In the Proximity-1 >>> desing, hardstamps are captured upon the passage of the ASM code >>> combination at the beginning of each transmitted frame.. >>> >>> Queuing and transmission delays are not the only contributors to space >>> data link delay. Reed-Solomon and convolutional encoding delays can = >>> be a >>> large contribution to the link delay; however, these delays are a >>> constant contribution to the lightwave transmission delay. These >>> contributions =96 up to many seconds =96 can dwarf the lightwave >>> transmission delays. >>> >>> In the NTP interleaved design, drivestamps are captured in the device >>> interrupt routine - on input immediately after the frame has been >>> received and before copying to an input buffer; on output shortly after >>> the frame has been transmitted and before the buffer is released for = >>> the >>> following input or output frame. This can become rather awkward in the >>> case of NICs of the PCNET architecture, as data are copied directly = >>> from >>> user space to device buffers directed by DMA descriptors. Drivestamps >>> have been used on input for many years, but for output this is possible >>> only using the interleaved modes. The result avoids the latencies = >>> due to >>> the message digest computation, Autokey protocol data units, output >>> queuing and frame transmissions, typically some 10-40 microseconds. >>> >>> It should be obvious from the documents that a primary motivation for >>> the NTP interleaved design was protection from network errors and >>> intruder attack. The detailed analysis and simulation are designed to >>> demonstrate resistance to common corruptions such as dropped or >>> duplicate packets and possible bogus attacks. The NTP design includes a >>> four-level security model, the lower two levels might be considered for >>> a PTP application. This is one of the most important difference between >>> the PTP and NTP protocol designs; however, the NTP design might be >>> considered overkill in a sheltered, isolated Ethernet network. >>> >>> Careful observers may notice an interesting anomaly with the = >>> interleaved >>> broadcast mode. The preliminary volley intended to measure the = >>> roundtrip >>> time uses basic mode, not interleaved mode. The reason for this = >>> requires >>> some explanation. In times of old, the dominant concern was the 6-bone, >>> an international consortium of multicast application developers. In = >>> that >>> context with historic multicast configurations, including DVMRP and = >>> PIM, >>> the multicast spanning tree was far different than the unicast spanning >>> tree. Therefore, the preliminary volley was important to estimate the >>> offset of the multicast server to the multicast client and thus the >>> apparent one-way delay. In principle, with adroit protocolmanship, it >>> would be possible to change the protocol to measure the interleaved >>> roundtrip delay, which would be more appropriate for modern high-speed >>> Ethernet networks. >>> >>> Karen O'Donoghue wrote: >>>> >>>> -------- Original Message -------- >>>> Subject: [TICTOC] reminder for remote participation in today's = >>>> tictoc >>>> meeting >>>> Date: Thu, 31 Mar 2011 09:56:35 +0200 >>>> From: Karen O'Donoghue >>>> Reply-To: odonoghue@isoc.org >>>> Organization: ISOC >>>> To: tictoc@ietf.org, NTP Working Group >>>> >>>> >>>> >>>> Folks, >>>> >>>> This is a reminder that the tictoc working group will meet today from >>>> 17:40 - 19:40 CEST (15:40 - 17:40 UTC). The tools agenda for the IETF >>>> meeting (http://tools.ietf.org/agenda/80/) has links for the drafts, >>>> presentations, jabber chat room, and audio streaming to facilitate >>>> remote participation. >>>> >>>> Regards, >>>> Karen >> _______________________________________________ >> TICTOC mailing list >> TICTOC@ietf.org >> https://www.ietf.org/mailman/listinfo/tictoc > > _______________________________________________ > ntpwg mailing list > ntpwg@lists.ntp.org > http://lists.ntp.org/listinfo/ntpwg > -- = Todd S. Glassey This is from my personal email account and any materials from this account = come with personal disclaimers. _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Fri Jun 10 11:27:34 2011 Return-Path: X-Original-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A34F11E80CA for ; Fri, 10 Jun 2011 11:27:34 -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=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CbNzt343qbk1 for ; Fri, 10 Jun 2011 11:27:32 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [IPv6:2001:4f8:fff7:1::7]) by ietfa.amsl.com (Postfix) with ESMTP id 513E511E80A2 for ; Fri, 10 Jun 2011 11:27:29 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id D55CA86D83E for ; Fri, 10 Jun 2011 18:27:24 +0000 (UTC) X-Original-To: ntpwg@lists.ntp.org Delivered-To: ntpwg@lists.ntp.org Received: from mail1.ntp.org (mail1.ntp.org [IPv6:2001:4f8:fff7:1::5]) by lists.ntp.org (Postfix) with ESMTP id CC18186D761 for ; Fri, 10 Jun 2011 16:30:04 +0000 (UTC) Received: from louie.udel.edu ([128.4.40.12] helo=mail.eecis.udel.edu) by mail1.ntp.org with esmtp (Exim 4.75 (FreeBSD)) (envelope-from ) id 1QV4am-000N2a-6S for ntpwg@lists.ntp.org; Fri, 10 Jun 2011 16:30:04 +0000 Received: from [192.168.1.3] (pool-74-109-5-222.phlapa.fios.verizon.net [74.109.5.222]) (Authenticated sender: mills@mail.eecis.udel.edu) by mail.eecis.udel.edu (Postfix) with ESMTP id 484AF2B1; Fri, 10 Jun 2011 12:29:51 -0400 (EDT) Message-ID: <4DF2467C.3050601@udel.edu> Date: Fri, 10 Jun 2011 16:29:48 +0000 From: "David L. Mills" 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: kodonog@pobox.com References: <4DF03979.5070204@pobox.com> <4DF0B423.2030504@ntp.org> <4DF1452C.1010704@pobox.com> In-Reply-To: <4DF1452C.1010704@pobox.com> X-SA-Exim-Connect-IP: 128.4.40.12 X-SA-Exim-Rcpt-To: ntpwg@lists.ntp.org X-SA-Exim-Mail-From: mills@udel.edu X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) Cc: NTP Working Group , tictoc@ietf.org Subject: Re: [ntpwg] [TICTOC] Fwd: Re: Fwd: reminder for remote participation in today's tictoc meeting X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Working Group for Network Time Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="windows-1252"; Format="flowed" Sender: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Errors-To: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Karen, Danny's list does not involve a lot of work except the interleaved = issue. In my recent message I raised the issue that the current = calibration round does not use interleaved mode, so the roundtrip = measurement is not precise. I have updated the white paper onwire.html = at the NTP project site www.eecis.udel.edu/~mills/ntp.html to fix this. = Note that the revised code is not in the reference implementation. The = reason for that is that the revised description is vulnerable to a = wiretap attack, while the original code is not. Therefore, there is a = choice between best accuracy and best defense against the bad guys. As for additional experiments on interlaaved performance, there is data = in the book on LAN measurements. Additional experiments are easy to do, = especially as the output delay is revealed on the ntpq billboards. While = probably not of primary interest, the improvement when Autokey extension = fields are involved is dramatic. The PTB folks have expressed interest in the Autokey facilities and have = found a middleman vulnerability that may be hard to fix. I have updated = the whit paper security.html at the NTP project site and have uncovered = another middleman vulnerability having to do with the identity = exchanges. This one is easy to fix, as outline in the document. = Additional discussion on the cookie vulnerability would be welcome. Dave Dave Karen O'Donoghue wrote: > Danny, > > You are absolutely correct. I was just referring to the forwarded = > message from Dave Mills... > > Folks, there are a number of items that need to be done. I'd love to = > have some volunteers to help work on these. > > Karen > > On 6/9/11 7:53 AM, Danny Mayer wrote: > >> It's not just interleave capability that needs to be added, but also: >> >> 1) mode 6 (public) command control packets which is documented in RFC >> 1305 but got dropped when obsoleting it; >> 2) add support for SHA-nnn to replace MD5 for FIPS compliance (see Rich >> Schmidt's bug report); >> 3) The work your former group has been doing that was presented at the >> last IETF meeting in Prague, if it's worth standardizing. >> >> I seem to remember a few other issues that we had discussed but I can't >> think of them right now. >> >> Danny >> >> On 6/8/2011 11:09 PM, Karen O'Donoghue wrote: >> >>> Folks, >>> >>> This came to me personally, and I neglected to send it on to the ntp = >>> and >>> tictoc wg lists. My apologies for the delay. The question before us is >>> whether or not the interleave capability should be properly documented >>> and where the resources will come from to complete the effort. >>> >>> Karen >>> >>> -------- Original Message -------- >>> Subject: Re: [ntpwg] Fwd: [TICTOC] reminder for remote = >>> participation in >>> today's tictoc meeting >>> Date: Tue, 12 Apr 2011 18:18:43 +0000 >>> From: David L. Mills >>> To: kodonog@pobox.com >>> >>> >>> >>> Karen, >>> >>> The following is in response to the ID you distributed. I offer it as a >>> candidate for distribution to th eWG members. >>> >>> Dave >>> >>> This internet draft describes experiments using the interleaved >>> broadcast mode recently incorporated in the NTP reference >>> implementation. The experiments do not include the interleaved = >>> symmetric >>> mode, which provides similar functionality in peer-to-peer >>> configurations. For reference, these modes, their relevance to PTP and >>> related information are discussed in detail in Chapters 15 through = >>> 17 of >>> the book "Network Time Synchronization - the Network Time Protocol on >>> Earth and in Space, Second Edition, CRC Press 2011, as cited on my web >>> page www.eedis.udel.edu/~mills. However, most of the information >>> relevant to the followings discussion can be found in the white papers >>> at www.eecis.udel.edu/~mills/ntp.html. Of particular interest are the >>> documents "Analysis and Simulation of the NTP On-Wire Protocol" and >>> "Security Analysis of the NTP Protocol." Both of these documents >>> represent an update since the book was published late last year. >>> >>> Readers may wonder why these documents have not been published as an >>> update to the protocol specification RFC-5905, which would have been = >>> the >>> expectation several years ago in the adolescent Internet. However, the >>> effort necessary to publish an ID with figures, tables and equations is >>> nowadays simply unacceptable. My experience with RFC-5905 and RFC-5906 >>> over the last five years of publishing effort is not sustainable. Thus, >>> unless some collaboration, perhaps the TICTOC working group, chose to >>> publish them as IDs, I will not commit that adventure myself. >>> >>> First some nomenclature that may help in the following discussion. >>> Timestamps captured for the clock discipline are classed as hardstamps, >>> drivestamps and softstamps. Softstamps are captured during the = >>> course of >>> user-space processing; they may be corrupted by operating system and >>> device latencies, as well as transmission delays. Drivestamps are >>> captured during the packet interrupt routines, so are much less = >>> affected >>> by operating system scheduling and competition with other programs. >>> Hardstamps are captured by dedicated hardware means, typically in the >>> PHY layer of the network interface card (NIC). While the details vary, >>> the typical intercept point is the media independent interface (MII), >>> which monitors the frame level interface on a character by character >>> basis. The capture means is usuallt a field-programmable gate array >>> (FPGA) that parses the packeet, inserts timestamp data and recomputes >>> the UDP checksum. >>> >>> The interleaved capability was originally not intended for NTP, but for >>> the Proximity-1 protocol specified by the Consultive Committee on Space >>> Data systems (CCSDS). The Proximity-1 protocol is designed for >>> communication between spacecraft in the vicinity of Mars and for future >>> missions in the vicinity of the Moon. Space data links are often >>> operated at very low data rates compared to typical Ethernet links. >>> Typical rates range from 1 kb/s to 256 kb/s with very different data >>> rates in each direction. Due to various queuing and transmission >>> operations, the output delay can reach 30 s, so it is imparities that >>> timestamps be captured close to the PHY layer. In the Proximity-1 >>> desing, hardstamps are captured upon the passage of the ASM code >>> combination at the beginning of each transmitted frame.. >>> >>> Queuing and transmission delays are not the only contributors to space >>> data link delay. Reed-Solomon and convolutional encoding delays can = >>> be a >>> large contribution to the link delay; however, these delays are a >>> constant contribution to the lightwave transmission delay. These >>> contributions =96 up to many seconds =96 can dwarf the lightwave >>> transmission delays. >>> >>> In the NTP interleaved design, drivestamps are captured in the device >>> interrupt routine - on input immediately after the frame has been >>> received and before copying to an input buffer; on output shortly after >>> the frame has been transmitted and before the buffer is released for = >>> the >>> following input or output frame. This can become rather awkward in the >>> case of NICs of the PCNET architecture, as data are copied directly = >>> from >>> user space to device buffers directed by DMA descriptors. Drivestamps >>> have been used on input for many years, but for output this is possible >>> only using the interleaved modes. The result avoids the latencies = >>> due to >>> the message digest computation, Autokey protocol data units, output >>> queuing and frame transmissions, typically some 10-40 microseconds. >>> >>> It should be obvious from the documents that a primary motivation for >>> the NTP interleaved design was protection from network errors and >>> intruder attack. The detailed analysis and simulation are designed to >>> demonstrate resistance to common corruptions such as dropped or >>> duplicate packets and possible bogus attacks. The NTP design includes a >>> four-level security model, the lower two levels might be considered for >>> a PTP application. This is one of the most important difference between >>> the PTP and NTP protocol designs; however, the NTP design might be >>> considered overkill in a sheltered, isolated Ethernet network. >>> >>> Careful observers may notice an interesting anomaly with the = >>> interleaved >>> broadcast mode. The preliminary volley intended to measure the = >>> roundtrip >>> time uses basic mode, not interleaved mode. The reason for this = >>> requires >>> some explanation. In times of old, the dominant concern was the 6-bone, >>> an international consortium of multicast application developers. In = >>> that >>> context with historic multicast configurations, including DVMRP and = >>> PIM, >>> the multicast spanning tree was far different than the unicast spanning >>> tree. Therefore, the preliminary volley was important to estimate the >>> offset of the multicast server to the multicast client and thus the >>> apparent one-way delay. In principle, with adroit protocolmanship, it >>> would be possible to change the protocol to measure the interleaved >>> roundtrip delay, which would be more appropriate for modern high-speed >>> Ethernet networks. >>> >>> Karen O'Donoghue wrote: >>> >>>> >>>> -------- Original Message -------- >>>> Subject: [TICTOC] reminder for remote participation in today's = >>>> tictoc >>>> meeting >>>> Date: Thu, 31 Mar 2011 09:56:35 +0200 >>>> From: Karen O'Donoghue >>>> Reply-To: odonoghue@isoc.org >>>> Organization: ISOC >>>> To: tictoc@ietf.org, NTP Working Group >>>> >>>> >>>> >>>> Folks, >>>> >>>> This is a reminder that the tictoc working group will meet today from >>>> 17:40 - 19:40 CEST (15:40 - 17:40 UTC). The tools agenda for the IETF >>>> meeting (http://tools.ietf.org/agenda/80/) has links for the drafts, >>>> presentations, jabber chat room, and audio streaming to facilitate >>>> remote participation. >>>> >>>> Regards, >>>> Karen >>> >> _______________________________________________ >> TICTOC mailing list >> TICTOC@ietf.org >> https://www.ietf.org/mailman/listinfo/tictoc > > _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Tue Jun 14 13:53:58 2011 Return-Path: X-Original-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 979C021F8529 for ; Tue, 14 Jun 2011 13:53:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.372 X-Spam-Level: X-Spam-Status: No, score=-104.372 tagged_above=-999 required=5 tests=[AWL=2.227, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CNlU8RLAJ8bk for ; Tue, 14 Jun 2011 13:53:54 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [IPv6:2001:4f8:fff7:1::7]) by ietfa.amsl.com (Postfix) with ESMTP id E1F6921F852B for ; Tue, 14 Jun 2011 13:53:53 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id C21EA86D765 for ; Tue, 14 Jun 2011 20:53:50 +0000 (UTC) X-Original-To: ntpwg@lists.ntp.org Delivered-To: ntpwg@lists.ntp.org Received: from mail1.ntp.org (mail1.ntp.org [IPv6:2001:4f8:fff7:1::5]) by lists.ntp.org (Postfix) with ESMTP id 5D80786D761 for ; Fri, 10 Jun 2011 21:28:35 +0000 (UTC) Received: from rfc-editor.org ([2001:1890:1112:1::2f]) by mail1.ntp.org with esmtp (Exim 4.75 (FreeBSD)) (envelope-from ) id 1QV9Fg-0002P2-NY for ntpwg@lists.ntp.org; Fri, 10 Jun 2011 21:28:35 +0000 Received: by rfc-editor.org (Postfix, from userid 30) id 1C7E298C50E; Fri, 10 Jun 2011 14:28:18 -0700 (PDT) To: mills@udel.edu, jrmii@isc.org, jack.burbank@jhuapl.edu, william.kasch@jhuapl.edu, rdroms.ietf@gmail.com, jari.arkko@piuha.net, odonoghue@isoc.org, brian@innovationslab.net From: RFC Errata System Message-Id: <20110610212818.1C7E298C50E@rfc-editor.org> Date: Fri, 10 Jun 2011 14:28:18 -0700 (PDT) X-SA-Exim-Connect-IP: 2001:1890:1112:1::2f X-SA-Exim-Rcpt-To: ntpwg@lists.ntp.org X-SA-Exim-Mail-From: wwwrun@rfc-editor.org X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) X-Mailman-Approved-At: Tue, 14 Jun 2011 20:35:16 +0000 Cc: ntpwg@lists.ntp.org, christian@quelltextlich.at, rfc-editor@rfc-editor.org Subject: [ntpwg] [Editorial Errata Reported] RFC5905 (2826) X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Working Group for Network Time Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Errors-To: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org The following errata report has been submitted for RFC5905, "Network Time Protocol Version 4: Protocol and Algorithms Specification". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5905&eid=2826 -------------------------------------- Type: Editorial Reported by: Christian Aistleitner Section: 6 Original Text ------------- [...] and a 64-bit fraction field resolving .05 attosecond (i.e., 0.5e-18). Corrected Text -------------- [...] and a 64-bit fraction field resolving .05 attosecond (i.e., 0.05e-18). Notes ----- "atto" is the prefix for 1e-18. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5905 (draft-ietf-ntp-ntpv4-proto-13) -------------------------------------- Title : Network Time Protocol Version 4: Protocol and Algorithms Specification Publication Date : June 2010 Author(s) : D. Mills, J. Martin, Ed., J. Burbank, W. Kasch Category : PROPOSED STANDARD Source : Network Time Protocol Area : Internet Stream : IETF Verifying Party : IESG _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Thu Jun 30 06:40:02 2011 Return-Path: X-Original-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44E9211E8157 for ; Thu, 30 Jun 2011 06:40:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.098 X-Spam-Level: X-Spam-Status: No, score=-105.098 tagged_above=-999 required=5 tests=[AWL=1.500, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2bvND4htTeRZ for ; Thu, 30 Jun 2011 06:40:01 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [IPv6:2001:4f8:fff7:1::7]) by ietfa.amsl.com (Postfix) with ESMTP id 4BA9011E8155 for ; Thu, 30 Jun 2011 06:39:56 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id 6D8D786D77D for ; Thu, 30 Jun 2011 13:39:45 +0000 (UTC) X-Original-To: ntpwg@lists.ntp.org Delivered-To: ntpwg@lists.ntp.org Received: from mail1.ntp.org (mail1.ntp.org [IPv6:2001:4f8:fff7:1::5]) by lists.ntp.org (Postfix) with ESMTP id 5699D86D760 for ; Thu, 30 Jun 2011 13:34:05 +0000 (UTC) Received: from mail-yi0-f41.google.com ([209.85.218.41]) by mail1.ntp.org with esmtps (TLSv1:RC4-SHA:128) (Exim 4.75 (FreeBSD)) (envelope-from ) id 1QcHNR-000JPZ-R5 for ntpwg@lists.ntp.org; Thu, 30 Jun 2011 13:34:05 +0000 Received: by yia13 with SMTP id 13so1141209yia.14 for ; Thu, 30 Jun 2011 06:33:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:reply-to:user-agent:mime-version:to :subject:content-type; bh=wqD2q+x2+9ynoyR0QMhqd9gsSzvqutMe0aRfapeuCfo=; b=CiGh8JxhQ5iJt4OxLfXrWp2SvqWQP3y0Yq1pgTmqF0eLx+C4ztPqvm9B3F7ebB9j4A fSLTTU3WYiEAbw0xM91ji2aiA8LIFWb0BXaYX82qRA1tyB3eW7ReNT/0dtkfgXEV89er iH/S/qx/id1UdjY/rkTFEW1sT2YwTGc96BuAE= Received: by 10.150.219.20 with SMTP id r20mr1860896ybg.403.1309440827216; Thu, 30 Jun 2011 06:33:47 -0700 (PDT) Received: from kodonog-mac.local ([12.46.250.203]) by mx.google.com with ESMTPS id i9sm1927632ybe.11.2011.06.30.06.33.44 (version=SSLv3 cipher=OTHER); Thu, 30 Jun 2011 06:33:45 -0700 (PDT) Message-ID: <4E0C7B31.5080603@pobox.com> Date: Thu, 30 Jun 2011 09:33:37 -0400 From: Karen O'Donoghue User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: NTP Working Group , tictoc@ietf.org X-SA-Exim-Connect-IP: 209.85.218.41 X-SA-Exim-Rcpt-To: ntpwg@lists.ntp.org X-SA-Exim-Mail-From: kodonog@gmail.com X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) Subject: [ntpwg] Fwd: Please help the Nomcom X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: kodonog@pobox.com List-Id: IETF Working Group for Network Time Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0096444149133858313==" Sender: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Errors-To: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org This is a multi-part message in MIME format. --===============0096444149133858313== Content-Type: multipart/alternative; boundary="------------090906010704000007030106" This is a multi-part message in MIME format. --------------090906010704000007030106 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit -------- Original Message -------- Subject: Please help the Nomcom Date: Fri, 24 Jun 2011 11:35:13 -0700 (PDT) From: NomCom Chair To: Working Group Chairs Hi WG chairs, We have had a good response to the first call for volunteers but the rate at which new volunteers are coming in is slowing down. The Nomcom process is best served by a large pool of volunteers drawn from a wide spectrum of IETF attendees. Where else would we find this wide spectrum if not in the WG mailing lists. I would really appreciate it if you can forward the message onto your working group mailing lists. The latest volunteer status and the second call for volunteers can be found at https://datatracker.ietf.org/ann/nomcom/2964/ Thanks in advance for your help. Suresh Krishnan Nomcom Chair 2011-2012 Email: nomcom-chair@ietf.org, suresh.krishnan@ericsson.com --------------090906010704000007030106 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

-------- Original Message --------
Subject: Please help the Nomcom
Date: Fri, 24 Jun 2011 11:35:13 -0700 (PDT)
From: NomCom Chair <nomcom-chair@ietf.org>
To: Working Group Chairs <wgchairs@ietf.org> 


Hi WG chairs,
  We have had a good response to the first call for volunteers but the 
rate at which new volunteers are coming in is slowing down. The Nomcom 
process is best served by a large pool of volunteers drawn from a wide 
spectrum of IETF attendees. Where else would we find this wide spectrum
if not in the WG mailing lists.

I would really appreciate it if you can forward the message onto your
working group mailing lists. 

The latest volunteer status and the second call for volunteers can be
found at
https://datatracker.ietf.org/ann/nomcom/2964/

Thanks in advance for your help.

Suresh Krishnan
Nomcom Chair 2011-2012
Email: nomcom-chair@ietf.org, suresh.krishnan@ericsson.com
--------------090906010704000007030106-- --===============0096444149133858313== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg --===============0096444149133858313==--