From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Thu Aug 1 13:43:15 2013 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 56AC511E816F for ; Thu, 1 Aug 2013 13:43: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=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QIeYaQ73Nkox for ; Thu, 1 Aug 2013 13:43:10 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [IPv6:2001:4f8:fff7:1::7]) by ietfa.amsl.com (Postfix) with ESMTP id 0AE6911E8167 for ; Thu, 1 Aug 2013 13:43:06 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id AE3C686DAA7 for ; Thu, 1 Aug 2013 20:43:03 +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 4DB2386D33D for ; Thu, 1 Aug 2013 20:42:51 +0000 (UTC) Received: from louie.udel.edu ([128.4.40.12] helo=mail.eecis.udel.edu) by mail1.ntp.org with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1V4zhM-0000ax-Jk for ntpwg@lists.ntp.org; Thu, 01 Aug 2013 20:42:50 +0000 Received: from [192.168.1.2] (pool-74-109-13-78.phlapa.fios.verizon.net [74.109.13.78]) (Authenticated sender: mills@mail.eecis.udel.edu) by mail.eecis.udel.edu (Postfix) with ESMTP id 2E31966D; Thu, 1 Aug 2013 16:42:11 -0400 (EDT) Message-ID: <51FAC820.3090401@udel.edu> Date: Thu, 01 Aug 2013 20:42:08 +0000 From: "David L. Mills" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: NTP Working Group 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: "tictoc@ietf.org" Subject: [ntpwg] security ID submitted for review X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.14 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="===============7338677642388690904==" Errors-To: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Sender: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org This is a multi-part message in MIME format. --===============7338677642388690904== Content-Type: multipart/alternative; boundary="------------040509030609050009080808" This is a multi-part message in MIME format. --------------040509030609050009080808 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Guys, Here are some general comments on the ID. I apologize if they are a little rough as I have to dictate this message instead of my usual polished wordsmithing. format. The ID does not specify an extension field format. Presumably, the extension field format described in RFC 5906 is adequate with new message types as required. However, in keeping with long Internet tradition, it must be possible to determine correct format without interpreting the header or extension fields. In addition, it must be possible to verify message integrity without interpreting the extension fields. In particular, the private key for the message authentication code (MAC) , if used, must be known beforehand. This is where the "cookie snatcher" issue comes up as described in previous messages. In particular, an important constraint for normal operation is that extension fields are not used unless required for cookie determination. Glaring vulnerability exists when using extension fields, as the key value is public and must be known in advance. This invites a cut-and-paste attack, as well as header changes, even if subsequently detected by the on-wire protocol. certificate. Both RFC 5906 and the ID require the server certificate. The server certificate can be conveyed, either off-line, or directly or indirectly via a certificate trail as described in RFC 5906 or the ID. If obtained via the trail, there is a hazzard due to a middle-man attack and masquerade. A solution proposed in RFC 5906 uses an identity scheme such as IFF. There may be an equivalent, or better schemes available now. protocol. Most of the discussion following the ID announcement is from protocol weenies, affectionately known as protomeister. When the Autokey scheme was first defined in 1996, the signature time required ranged up to one second on the computers of the time. Therefore, a clogging hazzard existed in the form of a replay attack. This is why the timestamp was included in the extension field format to suppress duplicates. Most of the extension fields were computed and signed off-line. Nevertheless, a clogging vulnerability remains in the cookie request message. This requires the server to do two public key incriptions and two hash functions. Today, this overhead may no longer be considered excessive; however, this may not be true for public time servers with thousands and thousands of clients. In broadcast mode, the protocols described in RFC 5906 and the ID are messy and with several possible vulnerabilities. Here is a suggestion that might be useful. Define a new broadcast packet format as the NTP header followed by one extension field representing the MAC. The extension field represents the signature of the header computed using the private key of the server and can be verified by the client using the public key in the server certificate. Originally, this was considered an unacceptable dilution of accuracy due to the variability of the signature computing time and the length of the signature. However, at least in modern NTP, the interleaved broadcast mode can be used to correct for this overhead. This assumes that the overhead for either the server or client is reduced using fast modern processors. As mentioned previously, in NTP symmetric mode the current protocol in RFC 5906 should be changed to use Diffie-Hellman key agreement. This is so easy to do that it can be incorporated separately in the standard. While the interleaved mode is useful in symmetric and broadcast modes, it can't be used when the server does not maintain state separately for each client. However, as in the orginal NTP design many years ago, the output delay can be computed for each transmitted server packet. The output delay can be averaged and used to augment the transmit timestamp or retrieve using an extension field. Note that this message does not address the cookie snatcher issue discussed by our German protomeisters, who have concocted a brillient solution. Many of the issues discussed are relevant to both NTP and PTP, although the on-wire protocol details may be different. I hope this discussion is useful in either context. Dave --------------040509030609050009080808 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Guys,

Here are some general comments on the ID.  I apologize if they are a little rough as I have to dictate this message instead of my usual polished wordsmithing.

format.
The ID does not specify an extension field format.  Presumably, the extension field format described in RFC 5906 is adequate with new message types as required.  However, in keeping with long Internet tradition, it must be possible to determine correct format without interpreting the header or extension fields.  In addition, it must be possible to verify message integrity without interpreting the extension fields.  In particular, the private key for the message authentication code (MAC) , if used, must be known beforehand.  This is where the "cookie snatcher" issue comes up as described in previous messages.  In particular, an important constraint for normal operation is that extension fields are not used unless required for cookie determination.

Glaring vulnerability exists when using extension fields, as the key value is public and must be known in advance.  This invites a cut-and-paste attack, as well as header changes, even if subsequently detected by the on-wire protocol.


certificate.
Both RFC 5906 and the ID require the server certificate.  The server certificate can be conveyed, either off-line, or directly or indirectly via a certificate trail as described in RFC 5906 or the ID.  If obtained via the trail, there is a hazzard due to a middle-man attack and masquerade.  A solution proposed in RFC 5906 uses an identity scheme such as IFF.  There may be an equivalent, or better schemes available now.

protocol.
Most of the discussion following the ID announcement is from protocol weenies, affectionately known as protomeister.  When the Autokey scheme was first defined in 1996,  the signature time required ranged up to one second on the computers of the time.  Therefore, a clogging hazzard existed in the form of  a replay attack.  This is why the timestamp was included in the extension field format to suppress duplicates.  Most of the extension fields were computed and signed off-line.  Nevertheless, a clogging vulnerability remains in the cookie request message.  This requires the server to do two public key incriptions and two hash functions. Today, this overhead may no longer  be considered  excessive; however, this may not be true for public time servers with thousands and thousands of clients.

In broadcast mode, the protocols described in RFC 5906 and the ID are messy and with several possible vulnerabilities.  Here is a suggestion that might be useful.  Define a new broadcast packet format as the NTP header followed by one extension field representing the MAC.  The extension field represents the signature of the header computed using the private key of the server and can be verified by the client using the public key in the server certificate.  Originally, this was considered an unacceptable dilution of accuracy due to the variability of the signature computing time and the length of the signature.  However, at least in modern NTP, the interleaved broadcast mode can be used to correct for this overhead.  This assumes that the overhead for either the server or client is reduced using fast modern processors.

As mentioned previously, in NTP symmetric mode the current protocol in RFC 5906 should be changed to use Diffie-Hellman key agreement.  This is so easy to do that it can be incorporated separately in the standard.

While the interleaved mode is useful in symmetric and broadcast modes, it can't be used when the server does not maintain state separately for each client.  However, as in the orginal NTP design many years ago, the output delay can be computed for each transmitted server packet.  The output delay can be averaged and used to augment  the transmit timestamp or retrieve using an extension field.

Note that this message does not address the cookie snatcher issue discussed by our German protomeisters, who have concocted a brillient solution.  Many of the issues discussed are relevant to both NTP and PTP, although the on-wire protocol details may be different.  I hope this discussion is useful in either context.

Dave


 --------------040509030609050009080808-- --===============7338677642388690904== 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 --===============7338677642388690904==-- From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Sat Aug 3 10:40:42 2013 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 D01EB11E8118 for ; Sat, 3 Aug 2013 10:40:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.524 X-Spam-Level: X-Spam-Status: No, score=-5.524 tagged_above=-999 required=5 tests=[AWL=1.075, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VMjNyvQTI10d for ; Sat, 3 Aug 2013 10:40: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 960C311E80AD for ; Sat, 3 Aug 2013 10:40:34 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id 0EEEC86D763 for ; Sat, 3 Aug 2013 17:40:29 +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 3D66E86D333 for ; Sat, 3 Aug 2013 17:40:13 +0000 (UTC) Received: from juliette.telenet-ops.be ([195.130.137.74]) by mail1.ntp.org with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1V5foI-000NdZ-VH for ntpwg@lists.ntp.org; Sat, 03 Aug 2013 17:40:13 +0000 Received: from intrepid.roeckx.be ([94.226.199.45]) by juliette.telenet-ops.be with bizsmtp id 8Hg81m0150zFtyu06Hg8Y8; Sat, 03 Aug 2013 19:40:09 +0200 Received: by intrepid.roeckx.be (Postfix, from userid 1000) id 6C9DDEB001; Sat, 3 Aug 2013 19:40:08 +0200 (CEST) Date: Sat, 3 Aug 2013 19:40:08 +0200 From: Kurt Roeckx To: "David L. Mills" Message-ID: <20130803174008.GA17578@roeckx.be> References: <51FAC820.3090401@udel.edu> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <51FAC820.3090401@udel.edu> User-Agent: Mutt/1.5.21 (2010-09-15) X-SA-Exim-Connect-IP: 195.130.137.74 X-SA-Exim-Rcpt-To: ntpwg@lists.ntp.org X-SA-Exim-Mail-From: kurt@roeckx.be 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] security ID submitted for review X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.14 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 Errors-To: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Sender: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org On Thu, Aug 01, 2013 at 08:42:08PM +0000, David L. Mills wrote: > Guys, > > Here are some general comments on the ID. I apologize if they are a > little rough as I have to dictate this message instead of my usual > polished wordsmithing. > > format. > The ID does not specify an extension field format. The draft only seems to specify the the general idea of how it should work and doesn't seem to go into detail how this should work at the protocol level. I assume he first wants to know if the solution is something that can work and that others see as a good solution before he works out the details. > In particular, the private key for the message > authentication code (MAC) , if used, must be known beforehand. This > is where the "cookie snatcher" issue comes up as described in > previous messages. In particular, an important constraint for > normal operation is that extension fields are not used unless > required for cookie determination. I'm not sure I understand your remark. As far as I know the "cookie snatcher" you talk about is the normal "man in the middle" attack. As I understand we would change the verification by replacing it by the normal X.509 verification as done for instance SSL/TLS. I assume you meant public key and note private key. > Glaring vulnerability exists when using extension fields, as the key > value is public and must be known in advance. This invites a > cut-and-paste attack, as well as header changes, even if > subsequently detected by the on-wire protocol. I've seen this cut-and-paste attack mentioned before, but I've never really understood it. As I understand things, the MAC is generated over the NTP + extensions. I don't see how you can take the extension from 1 packet into an other and still have a valid MAC. Or are you saying that you do something with a packet even when it doesn't have a valid MAC? > certificate. > Both RFC 5906 and the ID require the server certificate. The server > certificate can be conveyed, either off-line, or directly or > indirectly via a certificate trail as described in RFC 5906 or the > ID. If obtained via the trail, there is a hazzard due to a > middle-man attack and masquerade. I really don't understand how such a man in the middle attack can work. Either the certificate + the chain validate, or they don't. It is of course important to you check that the CommonName in the certificate matches the server you're trying to reach, and that the root CA is in your list of trusted CAs. But there really isn't anything new or hard about this. > In broadcast mode, the protocols described in RFC 5906 and the ID > are messy and with several possible vulnerabilities. Here is a > suggestion that might be useful. Define a new broadcast packet > format as the NTP header followed by one extension field > representing the MAC. The extension field represents the signature > of the header computed using the private key of the server and can > be verified by the client using the public key in the server > certificate. Originally, this was considered an unacceptable > dilution of accuracy due to the variability of the signature > computing time and the length of the signature. However, at least > in modern NTP, the interleaved broadcast mode can be used to correct > for this overhead. This assumes that the overhead for either the > server or client is reduced using fast modern processors. I think that in all cases where it's no problem to keep track of all clients you should use the interleaved mode, and we can use something like the Diffie-Hellman key agreement for those. But there clearly is also a need for servers that can't keep the state of each client, and we need something else for that. So maybe we need to define 2 ways of working. Kurt _______________________________________________ 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 Aug 6 18:02:31 2013 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 4109721F9D5D for ; Tue, 6 Aug 2013 18:02:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oDWNq5UBEndS for ; Tue, 6 Aug 2013 18:02:22 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by ietfa.amsl.com (Postfix) with ESMTP id 2C96A21F9D5F for ; Tue, 6 Aug 2013 18:02:21 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id E47BD86D58E for ; Wed, 7 Aug 2013 01:02:20 +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 9FC9D86D333 for ; Wed, 7 Aug 2013 01:02:00 +0000 (UTC) Received: from louie.udel.edu ([128.4.40.12] helo=mail.eecis.udel.edu) by mail1.ntp.org with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1V6s8R-0008xn-H1 for ntpwg@lists.ntp.org; Wed, 07 Aug 2013 01:02:00 +0000 Received: from [192.168.1.2] (pool-74-109-13-78.phlapa.fios.verizon.net [74.109.13.78]) (Authenticated sender: mills@mail.eecis.udel.edu) by mail.eecis.udel.edu (Postfix) with ESMTP id 51D9A1071; Tue, 6 Aug 2013 21:01:50 -0400 (EDT) Message-ID: <52019C7B.9070602@udel.edu> Date: Wed, 07 Aug 2013 01:01:47 +0000 From: "David L. Mills" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kurt Roeckx References: <51FAC820.3090401@udel.edu> <20130803174008.GA17578@roeckx.be> In-Reply-To: <20130803174008.GA17578@roeckx.be> 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] security ID submitted for review X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.14 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="===============5458946058449597757==" Errors-To: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Sender: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org This is a multi-part message in MIME format. --===============5458946058449597757== Content-Type: multipart/alternative; boundary="------------040201000803070007040309" This is a multi-part message in MIME format. --------------040201000803070007040309 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Kurt, Thanks for your reply. As a window of history, the Autokey protocol was devised during several walks in Regents Park, London, in 1996. I thought the most significant hazzard was the replay of client messages requiring extensive server cryptographic computations. At that time, I did not think that a middle-man attack would be significant. Both of those assumptions are probably inadvisable today. One problem with Autokey is the assumption that secret keys for each client can be manufactured using packet header fields and a hash of a server private value. A middle-man can manipulate the header fields compromising the client private key. There does not seem to be a solution for this problem other than requiring server state. There are two problems with requiring a server state variable associated with each client. The first is how to reliably match the server state with the client packet. For public time servers with thousands of clients, the storage of something like a client certificate for each client could be prohibitive. The storage could be dynamically allocated as a field in the MRU list maintained in the current NTP implimentation; however, the MRU list for several hundred entries has a lifetime of only 15 seconds, at NIST, for example. In the current Autokey design, the MAC computation covers the header and all extension fields. However, the key used for the MAC computation in packets with extension fields is not private. Therefore, in a cut-and-paste attack, an intruder could mix and match extension fields and simply recalculate the MAC. RFC 5906 defines the extension field including the filestamp and timestamp. The filestamp was designed to reliably associate the cryptographic media with the current version, as it can be frequently changed. This might not be useful in current designs. The timestamp field was designed to detect replays requiring expensive cryptographic computations which could take up to a second. However, the "call gap" (minimum headway) provisions nicely deflect such attacks, so the timestamp field might not be useful in current designs. Lastly, in the current design, each extension field is separately signed at the time the data were constructed. In current designs the signature might be computed at the time of transmission. The more I think of it, the better I like a design where the existing MAC is replaced by a single extension field computed as the signature of the header. I previously suggested this for broadcast mode, but I think this could be useful in other modes as well. It would be hightly interesting to determine the overhead for such a signature using modern processors. An experiment could be designed for the current NTP implementation. It would consist of an adaptor routine that matches an OpenSSL signature routine to the authencrypt/authdecrypt interface routine. I would do this myself, but with my current vision condition, it would not be practical. For someone with knowledge of the NTP programming style, this would be an interesting weekend project. In theis proposed design a busy server could be presented with thousands of signed client requests, each requiring a signed server response. However, the server might ignore the client request signature on the expectation that the server response could be reliably determined. Actually, the NTP on-wire protocol is very good for this. As an aside, the protocol analysis and simulation described in the white paper at the NTP project page could be done for PTP as well. Dave Kurt Roeckx wrote: >On Thu, Aug 01, 2013 at 08:42:08PM +0000, David L. Mills wrote: > > >>Guys, >> >>Here are some general comments on the ID. I apologize if they are a >>little rough as I have to dictate this message instead of my usual >>polished wordsmithing. >> >>format. >>The ID does not specify an extension field format. >> >> > >The draft only seems to specify the the general idea of how it >should work and doesn't seem to go into detail how this should >work at the protocol level. I assume he first wants to know if >the solution is something that can work and that others see >as a good solution before he works out the details. > > > >>In particular, the private key for the message >>authentication code (MAC) , if used, must be known beforehand. This >>is where the "cookie snatcher" issue comes up as described in >>previous messages. In particular, an important constraint for >>normal operation is that extension fields are not used unless >>required for cookie determination. >> >> > >I'm not sure I understand your remark. As far as I know the >"cookie snatcher" you talk about is the normal "man in the middle" >attack. As I understand we would change the verification by >replacing it by the normal X.509 verification as done for instance >SSL/TLS. > >I assume you meant public key and note private key. > > > >>Glaring vulnerability exists when using extension fields, as the key >>value is public and must be known in advance. This invites a >>cut-and-paste attack, as well as header changes, even if >>subsequently detected by the on-wire protocol. >> >> > >I've seen this cut-and-paste attack mentioned before, but I've >never really understood it. As I understand things, the MAC >is generated over the NTP + extensions. I don't see how you >can take the extension from 1 packet into an other and still >have a valid MAC. Or are you saying that you do something >with a packet even when it doesn't have a valid MAC? > > > >>certificate. >>Both RFC 5906 and the ID require the server certificate. The server >>certificate can be conveyed, either off-line, or directly or >>indirectly via a certificate trail as described in RFC 5906 or the >>ID. If obtained via the trail, there is a hazzard due to a >>middle-man attack and masquerade. >> >> > >I really don't understand how such a man in the middle attack >can work. Either the certificate + the chain validate, or they >don't. It is of course important to you check that the CommonName >in the certificate matches the server you're trying to reach, >and that the root CA is in your list of trusted CAs. But there >really isn't anything new or hard about this. > > > >>In broadcast mode, the protocols described in RFC 5906 and the ID >>are messy and with several possible vulnerabilities. Here is a >>suggestion that might be useful. Define a new broadcast packet >>format as the NTP header followed by one extension field >>representing the MAC. The extension field represents the signature >>of the header computed using the private key of the server and can >>be verified by the client using the public key in the server >>certificate. Originally, this was considered an unacceptable >>dilution of accuracy due to the variability of the signature >>computing time and the length of the signature. However, at least >>in modern NTP, the interleaved broadcast mode can be used to correct >>for this overhead. This assumes that the overhead for either the >>server or client is reduced using fast modern processors. >> >> > >I think that in all cases where it's no problem to keep track of >all clients you should use the interleaved mode, and we can use >something like the Diffie-Hellman key agreement for those. > >But there clearly is also a need for servers that can't keep >the state of each client, and we need something else for that. >So maybe we need to define 2 ways of working. > > > >Kurt > > > --------------040201000803070007040309 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Kurt,

Thanks for your reply.  As a window of history, the Autokey protocol was devised during several walks in Regents Park, London, in 1996.  I thought the most significant hazzard was the replay of client messages requiring extensive server cryptographic computations.  At that time, I did not think that a middle-man attack would be significant.  Both of those assumptions are probably inadvisable today. 

One problem with Autokey is the assumption that secret keys for each client can be manufactured using packet header fields and a hash of a server private value.  A middle-man can manipulate the header fields compromising the client private key.  There does not seem to be a solution for this problem other than requiring server state.

There are two problems with requiring a server state variable associated with each client.  The first is how to reliably match the server state with the client packet.  For public time servers with thousands of clients, the storage of something like a client certificate for each client could be prohibitive.  The storage could be dynamically allocated as a field in the MRU list maintained in the current NTP implimentation; however, the MRU list for several hundred entries has a lifetime of only 15 seconds, at NIST, for example. 

In the current Autokey design, the MAC computation covers the header and all extension fields.  However, the key used for the MAC computation in packets with extension fields is not private.  Therefore, in a cut-and-paste attack, an intruder could mix and match extension fields and simply recalculate the MAC. 

RFC 5906 defines the extension field including the filestamp and timestamp.  The filestamp was designed to reliably associate the cryptographic media with the current version, as it can be frequently changed.  This might not be useful in current designs.  The timestamp field was designed to detect replays requiring expensive cryptographic computations which could take up to a second.  However, the "call gap" (minimum headway) provisions nicely deflect such attacks, so the timestamp field might not be useful in current designs.   Lastly, in the current design, each extension field is separately signed  at the time the data were constructed.  In current designs the signature might be computed at the time of transmission.

The more I think of it, the better I like a design where the existing MAC is replaced by a single extension field computed as the signature of the header.  I previously suggested this for broadcast mode, but I think this could be useful in other modes as well.  It would be hightly interesting to determine the overhead for such a signature using modern processors.  An experiment could be designed for the current NTP implementation.  It would consist of an adaptor routine that matches an OpenSSL signature routine to the authencrypt/authdecrypt interface routine.  I would do this myself, but with my current vision condition, it would not be practical.  For someone with knowledge of the NTP programming style, this would be an interesting weekend project.

In theis proposed design a busy server could be presented with thousands of signed client requests, each requiring  a signed server response.  However, the server might ignore the client request signature on the expectation that the  server response could be reliably determined.  Actually, the NTP on-wire protocol is very good for this.  As an aside, the protocol analysis and simulation described in the white paper at the NTP project page could be done for PTP as well.

Dave

Kurt Roeckx wrote: 
On Thu, Aug 01, 2013 at 08:42:08PM +0000, David L. Mills wrote:
  
Guys,

Here are some general comments on the ID.  I apologize if they are a
little rough as I have to dictate this message instead of my usual
polished wordsmithing.

format.
The ID does not specify an extension field format.
    

The draft only seems to specify the the general idea of how it
should work and doesn't seem to go into detail how this should
work at the protocol level.  I assume he first wants to know if
the solution is something that can work and that others see
as a good solution before he works out the details.

  
In particular, the private key for the message
authentication code (MAC) , if used, must be known beforehand.  This
is where the "cookie snatcher" issue comes up as described in
previous messages.  In particular, an important constraint for
normal operation is that extension fields are not used unless
required for cookie determination.
    

I'm not sure I understand your remark.  As far as I know the
"cookie snatcher" you talk about is the normal "man in the middle"
attack.  As I understand we would change the verification by
replacing it by the normal X.509 verification as done for instance
SSL/TLS.

I assume you meant public key and note private key.

  
Glaring vulnerability exists when using extension fields, as the key
value is public and must be known in advance.  This invites a
cut-and-paste attack, as well as header changes, even if
subsequently detected by the on-wire protocol.
    

I've seen this cut-and-paste attack mentioned before, but I've
never really understood it.  As I understand things, the MAC
is generated over the NTP + extensions.  I don't see how you
can take the extension from 1 packet into an other and still
have a valid MAC.  Or are you saying that you do something
with a packet even when it doesn't have a valid MAC?

  
certificate.
Both RFC 5906 and the ID require the server certificate.  The server
certificate can be conveyed, either off-line, or directly or
indirectly via a certificate trail as described in RFC 5906 or the
ID.  If obtained via the trail, there is a hazzard due to a
middle-man attack and masquerade.
    

I really don't understand how such a man in the middle attack
can work.  Either the certificate + the chain validate, or they
don't.  It is of course important to you check that the CommonName
in the certificate matches the server you're trying to reach,
and that the root CA is in your list of trusted CAs.  But there
really isn't anything new or hard about this.

  
In broadcast mode, the protocols described in RFC 5906 and the ID
are messy and with several possible vulnerabilities.  Here is a
suggestion that might be useful.  Define a new broadcast packet
format as the NTP header followed by one extension field
representing the MAC.  The extension field represents the signature
of the header computed using the private key of the server and can
be verified by the client using the public key in the server
certificate.  Originally, this was considered an unacceptable
dilution of accuracy due to the variability of the signature
computing time and the length of the signature.  However, at least
in modern NTP, the interleaved broadcast mode can be used to correct
for this overhead.  This assumes that the overhead for either the
server or client is reduced using fast modern processors.
    

I think that in all cases where it's no problem to keep track of
all clients you should use the interleaved mode, and we can use
something like the Diffie-Hellman key agreement for those.

But there clearly is also a need for servers that can't keep
the state of each client, and we need something else for that.
So maybe we need to define 2 ways of working.



Kurt

--------------040201000803070007040309-- --===============5458946058449597757== 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 --===============5458946058449597757==-- From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Wed Aug 7 03:23:49 2013 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 C633021E80BE for ; Wed, 7 Aug 2013 03:23:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.932 X-Spam-Level: X-Spam-Status: No, score=-4.932 tagged_above=-999 required=5 tests=[AWL=1.667, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KLWYOXjslfkB for ; Wed, 7 Aug 2013 03:23:44 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [IPv6:2001:4f8:fff7:1::7]) by ietfa.amsl.com (Postfix) with ESMTP id 784A221E80D9 for ; Wed, 7 Aug 2013 03:23:44 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id 4345D86DAB2 for ; Wed, 7 Aug 2013 10:23:44 +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 BA5BB86D529 for ; Wed, 7 Aug 2013 10:23:30 +0000 (UTC) Received: from gerard.telenet-ops.be ([195.130.132.48]) by mail1.ntp.org with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1V70ts-000Gdu-EM for ntpwg@lists.ntp.org; Wed, 07 Aug 2013 10:23:30 +0000 Received: from intrepid.roeckx.be ([94.226.199.45]) by gerard.telenet-ops.be with bizsmtp id 9mPQ1m00G0zFtyu0HmPQkB; Wed, 07 Aug 2013 12:23:26 +0200 Received: by intrepid.roeckx.be (Postfix, from userid 1000) id 19564EB1C9; Wed, 7 Aug 2013 12:23:24 +0200 (CEST) Date: Wed, 7 Aug 2013 12:23:24 +0200 From: Kurt Roeckx To: "David L. Mills" Message-ID: <20130807102324.GA17618@roeckx.be> References: <51FAC820.3090401@udel.edu> <20130803174008.GA17578@roeckx.be> <52019C7B.9070602@udel.edu> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <52019C7B.9070602@udel.edu> User-Agent: Mutt/1.5.21 (2010-09-15) X-SA-Exim-Connect-IP: 195.130.132.48 X-SA-Exim-Rcpt-To: ntpwg@lists.ntp.org X-SA-Exim-Mail-From: kurt@roeckx.be 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] security ID submitted for review X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.14 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 Errors-To: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Sender: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Hi Dave, On Wed, Aug 07, 2013 at 01:01:47AM +0000, David L. Mills wrote: > Kurt, > > Thanks for your reply. As a window of history, the Autokey protocol > was devised during several walks in Regents Park, London, in 1996. > I thought the most significant hazzard was the replay of client > messages requiring extensive server cryptographic computations. At > that time, I did not think that a middle-man attack would be > significant. Both of those assumptions are probably inadvisable > today. > > One problem with Autokey is the assumption that secret keys for each > client can be manufactured using packet header fields and a hash of > a server private value. A middle-man can manipulate the header > fields compromising the client private key. There does not seem to > be a solution for this problem other than requiring server state. This proposal also generates a cookie based on the something the client sends and a secret in the server, which is then encrypted using the client's public key. The ID does not mention that this message is signed by the server, but Stephen's mail said it was. This part is important to avoid the man in the middle attack. So as result the client got a unique secret for him, and only the client and the server known it. It can also be sure that it really comes from the server, so that there can be no man in the middle attack. And the server doesn't need to keep state since it can calculate it again based on what the client sends him. > In the current Autokey design, the MAC computation covers the header > and all extension fields. However, the key used for the MAC > computation in packets with extension fields is not private. > Therefore, in a cut-and-paste attack, an intruder could mix and > match extension fields and simply recalculate the MAC. If the key is not private, by adding extentions to a packet an attacker can just generate anything he wants? > RFC 5906 defines the extension field including the filestamp and > timestamp. The filestamp was designed to reliably associate the > cryptographic media with the current version, as it can be > frequently changed. This might not be useful in current designs. > The timestamp field was designed to detect replays requiring > expensive cryptographic computations which could take up to a > second. However, the "call gap" (minimum headway) provisions nicely > deflect such attacks, so the timestamp field might not be useful in > current designs. Lastly, in the current design, each extension > field is separately signed at the time the data were constructed. > In current designs the signature might be computed at the time of I'm not sure I understand what you're trying to say. I'm not sure what the filestamps are used for. But I assume that for instance for the leap seconds you send when it was last updates. I guess you can sign this once and always send this signed in an extension, even when you're otherwise not using any encryption. Since you already signed it, the overhead of adding that extension is small. The problem I see with only sending the MAC over the ntp headers and not over the extensions is that the extensions can be removed or added and the client can't tell. So it could for instance be replaced with an old version of the extension. I think it's important that the MAC covers everything. Kurt _______________________________________________ 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 Wed Aug 7 04:46:05 2013 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 AEBBC21F9A40 for ; Wed, 7 Aug 2013 04:46:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.098 X-Spam-Level: X-Spam-Status: No, score=-5.098 tagged_above=-999 required=5 tests=[AWL=1.501, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5SxHklmj32Vo for ; Wed, 7 Aug 2013 04:46:00 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [IPv6:2001:4f8:fff7:1::7]) by ietfa.amsl.com (Postfix) with ESMTP id B32E121F9D0D for ; Wed, 7 Aug 2013 04:45:59 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id 82D6186D773 for ; Wed, 7 Aug 2013 11:45:49 +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 A15A286D529 for ; Wed, 7 Aug 2013 11:45:38 +0000 (UTC) Received: from jacques.telenet-ops.be ([195.130.132.50]) by mail1.ntp.org with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1V72BM-000H4H-RY for ntpwg@lists.ntp.org; Wed, 07 Aug 2013 11:45:38 +0000 Received: from intrepid.roeckx.be ([94.226.199.45]) by jacques.telenet-ops.be with bizsmtp id 9nlX1m00R0zFtyu0JnlXda; Wed, 07 Aug 2013 13:45:32 +0200 Received: by intrepid.roeckx.be (Postfix, from userid 1000) id 9F804EB1C9; Wed, 7 Aug 2013 13:45:30 +0200 (CEST) Date: Wed, 7 Aug 2013 13:45:30 +0200 From: Kurt Roeckx To: "David L. Mills" Message-ID: <20130807114530.GA20391@roeckx.be> References: <51FAC820.3090401@udel.edu> <20130803174008.GA17578@roeckx.be> <52019C7B.9070602@udel.edu> <20130807102324.GA17618@roeckx.be> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20130807102324.GA17618@roeckx.be> User-Agent: Mutt/1.5.21 (2010-09-15) X-SA-Exim-Connect-IP: 195.130.132.50 X-SA-Exim-Rcpt-To: ntpwg@lists.ntp.org X-SA-Exim-Mail-From: kurt@roeckx.be 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] security ID submitted for review X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.14 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 Errors-To: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Sender: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org On Wed, Aug 07, 2013 at 12:23:24PM +0200, Kurt Roeckx wrote: > The problem I see with only sending the MAC over the ntp headers > and not over the extensions is that the extensions can be removed > or added and the client can't tell. So it could for instance > be replaced with an old version of the extension. I think it's > important that the MAC covers everything. You could of course also add a timestamp indicating when the signature of the extension expires. I think we should do that in any case. Then I'm not sure if there is still a need to to sign the whole packet. Can all extensions be signed? Is there a need to sign them all? Kurt _______________________________________________ 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 Wed Aug 7 05:20:14 2013 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 142EF21F9BD8 for ; Wed, 7 Aug 2013 05:20:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.423 X-Spam-Level: X-Spam-Status: No, score=-4.423 tagged_above=-999 required=5 tests=[AWL=2.175, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mmUlcSESqdqd for ; Wed, 7 Aug 2013 05:20:09 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by ietfa.amsl.com (Postfix) with ESMTP id 634E121F9CC0 for ; Wed, 7 Aug 2013 05:20:09 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id 340CF86D768 for ; Wed, 7 Aug 2013 12:20:01 +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 4C5E386D529 for ; Wed, 7 Aug 2013 12:19:51 +0000 (UTC) Received: from mx1.bs.ptb.de ([192.53.103.106]) by mail1.ntp.org with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1V72iP-000HF3-An for ntpwg@lists.ntp.org; Wed, 07 Aug 2013 12:19:51 +0000 Received: from mx1.bs.ptb.de (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id EF793CE67F1; Wed, 7 Aug 2013 14:19:37 +0200 (CEST) Received: from rose.bs.ptb.de (rose.bs.ptb.de [141.25.85.201]) by mx1.bs.ptb.de (Postfix) with ESMTP id D3BF2CE2DEB; Wed, 7 Aug 2013 14:19:37 +0200 (CEST) In-Reply-To: <20130803174008.GA17578@roeckx.be> References: <51FAC820.3090401@udel.edu> <20130803174008.GA17578@roeckx.be> To: Kurt Roeckx MIME-Version: 1.0 X-KeepSent: CF046B68:1B709B01-C1257BC0:002ECD08; type=4; name=$KeepSent X-Mailer: IBM Notes Release 9.0 March 08, 2013 Message-ID: From: dieter.sibold@ptb.de Date: Wed, 7 Aug 2013 14:19:33 +0200 X-MIMETrack: S/MIME Sign by Notes Client on Dieter Sibold/PTB(Release 9.0|March 08, 2013) at 07.08.2013 14:19:34, Serialize by Notes Client on Dieter Sibold/PTB(Release 9.0|March 08, 2013) at 07.08.2013 14:19:34, Serialize complete at 07.08.2013 14:19:34, Itemize by Notes Client on Dieter Sibold/PTB(Release 9.0|March 08, 2013) at 07.08.2013 14:19:36, S/MIME Sign complete at 07.08.2013 14:19:36, Serialize by Router on ROSE/PTB(Release 8.5.3FP3HF370 | April 24, 2013) at 08/07/2013 14:19:36, Serialize complete at 08/07/2013 14:19:36 X-SA-Exim-Connect-IP: 192.53.103.106 X-SA-Exim-Rcpt-To: ntpwg@lists.ntp.org X-SA-Exim-Mail-From: dieter.sibold@ptb.de 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] security ID submitted for review X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.14 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="===============3118256893408297054==" Errors-To: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Sender: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org This is an S/MIME signed message. --===============3118256893408297054== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary=-------z50770_boundary_sign This is an S/MIME signed message. ---------z50770_boundary_sign Content-Type: multipart/alternative; boundary="=_alternative 0043B5D4C1257BC0_=" Dies ist eine mehrteilige Nachricht im MIME-Format. --=_alternative 0043B5D4C1257BC0_= Content-Type: text/plain; charset="US-ASCII" Hello Dave and Kurt, thanks for your comments: As Kurt already pointed out. Currently the ID specifies only the design of the security protocol. We believe that we need to be clear about the design questions before specifying the technical details. The private key of the client is not needed for the MAC. Instead the calculation of the MAC includes the cookie and the whole NTP packet (i.e. the extension fields also). The cookie is calculated from the server seed and the client's public key, which the client attaches to each time request (which requires a new extension field as pointed out in the draft). During cookie exchange the server encrypts the cookie with the client's public key before transmission. An adversary is therefore not able to abuse a cookie which he requests in behalf of the client. As Kurt pointed out the certificate exchange works as in a standard PKI. I emphasize that this is different to autokey. In autokey the chain of trust and time are equal whereas in this ID chain of trust and time might be disjunct. Regarding the broadcast mode. I agree with Dave that the use of TESLA for the broadcast mode adds additional complexity. It also has the disadvantage that the authenticity of a packet can only be verified in retrospect. But I don't see security vulnerabilities. Dave's suggestion to use a combination of interleave mode with asymmetric cryptography is interesting. We should consider this. The argument that asymmetric cryptography might be feasible because of modern power of CPUs is okay for traditional computer systems but I'm not sure whether this assumption also applies for small devices with constrained resources. Regards Dieter ---------------------------------- Physikalisch-Technische Bundesanstalt Dr. Dieter Sibold Q.42 - Serversysteme und Datenhaltung QM-Verantwortlicher der Stelle IT-Infrastruktur Bundesallee 100 D-38116 Braunschweig Tel: +49-531-592-84 20 E-Mail: dieter.sibold@ptb.de Von: Kurt Roeckx An: "David L. Mills" Kopie: NTP Working Group , "tictoc@ietf.org" Datum: 03.08.2013 20:04 Betreff: Re: [ntpwg] security ID submitted for review Gesendet von: ntpwg-bounces+dieter.sibold=ptb.de@lists.ntp.org On Thu, Aug 01, 2013 at 08:42:08PM +0000, David L. Mills wrote: > Guys, > > Here are some general comments on the ID. I apologize if they are a > little rough as I have to dictate this message instead of my usual > polished wordsmithing. > > format. > The ID does not specify an extension field format. The draft only seems to specify the the general idea of how it should work and doesn't seem to go into detail how this should work at the protocol level. I assume he first wants to know if the solution is something that can work and that others see as a good solution before he works out the details. > In particular, the private key for the message > authentication code (MAC) , if used, must be known beforehand. This > is where the "cookie snatcher" issue comes up as described in > previous messages. In particular, an important constraint for > normal operation is that extension fields are not used unless > required for cookie determination. I'm not sure I understand your remark. As far as I know the "cookie snatcher" you talk about is the normal "man in the middle" attack. As I understand we would change the verification by replacing it by the normal X.509 verification as done for instance SSL/TLS. I assume you meant public key and note private key. > Glaring vulnerability exists when using extension fields, as the key > value is public and must be known in advance. This invites a > cut-and-paste attack, as well as header changes, even if > subsequently detected by the on-wire protocol. I've seen this cut-and-paste attack mentioned before, but I've never really understood it. As I understand things, the MAC is generated over the NTP + extensions. I don't see how you can take the extension from 1 packet into an other and still have a valid MAC. Or are you saying that you do something with a packet even when it doesn't have a valid MAC? > certificate. > Both RFC 5906 and the ID require the server certificate. The server > certificate can be conveyed, either off-line, or directly or > indirectly via a certificate trail as described in RFC 5906 or the > ID. If obtained via the trail, there is a hazzard due to a > middle-man attack and masquerade. I really don't understand how such a man in the middle attack can work. Either the certificate + the chain validate, or they don't. It is of course important to you check that the CommonName in the certificate matches the server you're trying to reach, and that the root CA is in your list of trusted CAs. But there really isn't anything new or hard about this. > In broadcast mode, the protocols described in RFC 5906 and the ID > are messy and with several possible vulnerabilities. Here is a > suggestion that might be useful. Define a new broadcast packet > format as the NTP header followed by one extension field > representing the MAC. The extension field represents the signature > of the header computed using the private key of the server and can > be verified by the client using the public key in the server > certificate. Originally, this was considered an unacceptable > dilution of accuracy due to the variability of the signature > computing time and the length of the signature. However, at least > in modern NTP, the interleaved broadcast mode can be used to correct > for this overhead. This assumes that the overhead for either the > server or client is reduced using fast modern processors. I think that in all cases where it's no problem to keep track of all clients you should use the interleaved mode, and we can use something like the Diffie-Hellman key agreement for those. But there clearly is also a need for servers that can't keep the state of each client, and we need something else for that. So maybe we need to define 2 ways of working. Kurt _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg --=_alternative 0043B5D4C1257BC0_= Content-Type: text/html; charset="US-ASCII" Hello Dave and Kurt,

thanks for your comments:

As Kurt already pointed out. Currently the ID specifies only the design of the security protocol. We believe that we need to be clear about the design questions before specifying the technical details.

The private key of the client is not needed for the MAC. Instead the calculation of the MAC includes the cookie and the whole NTP packet (i.e. the extension fields also). The cookie is calculated from the server seed and the client's public key, which the client attaches to each time request (which requires a new extension field as pointed out in the draft). During cookie exchange the server encrypts the cookie with the client's public key before transmission. An adversary is therefore not able to abuse a cookie which he requests in behalf of the client.

As Kurt pointed out the certificate exchange works as in a standard PKI. I emphasize that this is different to autokey. In autokey the chain of trust and time are equal whereas in this ID chain of trust and time might be disjunct.

Regarding the broadcast mode. I agree with Dave that the use of TESLA for the broadcast mode adds additional complexity.  It also has the disadvantage that the authenticity of a packet can only be verified in retrospect. But I don't see security vulnerabilities. Dave's suggestion to use a combination of interleave mode with asymmetric cryptography is interesting. We should consider this. The argument that asymmetric cryptography might be feasible because of modern power of CPUs is okay for traditional computer systems but I'm not sure whether this assumption also applies for small devices with constrained resources.

Regards
Dieter


----------------------------------
Physikalisch-Technische Bundesanstalt
Dr. Dieter Sibold
Q.42 - Serversysteme und Datenhaltung
QM-Verantwortlicher der Stelle IT-Infrastruktur
Bundesallee 100
D-38116 Braunschweig
Tel: +49-531-592-84 20
E-Mail: dieter.sibold@ptb.de



Von:        Kurt Roeckx <kurt@roeckx.be>
An:        "David L. Mills" <mills@udel.edu>
Kopie:        NTP Working Group <ntpwg@lists.ntp.org>, "tictoc@ietf.org" <tictoc@ietf.org>
Datum:        03.08.2013 20:04
Betreff:        Re: [ntpwg] security ID submitted for review
Gesendet von:        ntpwg-bounces+dieter.sibold=ptb.de@lists.ntp.org



On Thu, Aug 01, 2013 at 08:42:08PM +0000, David L. Mills wrote:
> Guys,
>
> Here are some general comments on the ID.  I apologize if they are a
> little rough as I have to dictate this message instead of my usual
> polished wordsmithing.
>
> format.
> The ID does not specify an extension field format.

The draft only seems to specify the the general idea of how it
should work and doesn't seem to go into detail how this should
work at the protocol level.  I assume he first wants to know if
the solution is something that can work and that others see
as a good solution before he works out the details.

> In particular, the private key for the message
> authentication code (MAC) , if used, must be known beforehand.  This
> is where the "cookie snatcher" issue comes up as described in
> previous messages.  In particular, an important constraint for
> normal operation is that extension fields are not used unless
> required for cookie determination.

I'm not sure I understand your remark.  As far as I know the
"cookie snatcher" you talk about is the normal "man in the middle"
attack.  As I understand we would change the verification by
replacing it by the normal X.509 verification as done for instance
SSL/TLS.

I assume you meant public key and note private key.

> Glaring vulnerability exists when using extension fields, as the key
> value is public and must be known in advance.  This invites a
> cut-and-paste attack, as well as header changes, even if
> subsequently detected by the on-wire protocol.

I've seen this cut-and-paste attack mentioned before, but I've
never really understood it.  As I understand things, the MAC
is generated over the NTP + extensions.  I don't see how you
can take the extension from 1 packet into an other and still
have a valid MAC.  Or are you saying that you do something
with a packet even when it doesn't have a valid MAC?

> certificate.
> Both RFC 5906 and the ID require the server certificate.  The server
> certificate can be conveyed, either off-line, or directly or
> indirectly via a certificate trail as described in RFC 5906 or the
> ID.  If obtained via the trail, there is a hazzard due to a
> middle-man attack and masquerade.

I really don't understand how such a man in the middle attack
can work.  Either the certificate + the chain validate, or they
don't.  It is of course important to you check that the CommonName
in the certificate matches the server you're trying to reach,
and that the root CA is in your list of trusted CAs.  But there
really isn't anything new or hard about this.

> In broadcast mode, the protocols described in RFC 5906 and the ID
> are messy and with several possible vulnerabilities.  Here is a
> suggestion that might be useful.  Define a new broadcast packet
> format as the NTP header followed by one extension field
> representing the MAC.  The extension field represents the signature
> of the header computed using the private key of the server and can
> be verified by the client using the public key in the server
> certificate.  Originally, this was considered an unacceptable
> dilution of accuracy due to the variability of the signature
> computing time and the length of the signature.  However, at least
> in modern NTP, the interleaved broadcast mode can be used to correct
> for this overhead.  This assumes that the overhead for either the
> server or client is reduced using fast modern processors.

I think that in all cases where it's no problem to keep track of
all clients you should use the interleaved mode, and we can use
something like the Diffie-Hellman key agreement for those.

But there clearly is also a need for servers that can't keep
the state of each client, and we need something else for that.
So maybe we need to define 2 ways of working.



Kurt

_______________________________________________
ntpwg mailing list
ntpwg@lists.ntp.org
http://lists.ntp.org/listinfo/ntpwg
--=_alternative 0043B5D4C1257BC0_=-- ---------z50770_boundary_sign Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIImgAIBATELMAkGBSsOAwIaBQAwCwYJKoZIhvcNAQcBoIIjkjCCA58w ggKHoAMCAQICASYwDQYJKoZIhvcNAQEFBQAwcTELMAkGA1UEBhMCREUxHDAaBgNVBAoTE0RldXRz Y2hlIFRlbGVrb20gQUcxHzAdBgNVBAsTFlQtVGVsZVNlYyBUcnVzdCBDZW50ZXIxIzAhBgNVBAMT GkRldXRzY2hlIFRlbGVrb20gUm9vdCBDQSAyMB4XDTk5MDcwOTEyMTEwMFoXDTE5MDcwOTIzNTkw MFowcTELMAkGA1UEBhMCREUxHDAaBgNVBAoTE0RldXRzY2hlIFRlbGVrb20gQUcxHzAdBgNVBAsT FlQtVGVsZVNlYyBUcnVzdCBDZW50ZXIxIzAhBgNVBAMTGkRldXRzY2hlIFRlbGVrb20gUm9vdCBD QSAyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAqwujNeCLKRSxFIWvPBDkOW81XUqu 3ephjZVJ9G9koxpgZqSpQCKE2dSl5XiTDmgBrblNXDrO07ioQkDfz6O6gllqkhusHJraCCslJ/lp I0fx4Ossepv1EwLQfjR8wp48AFmr9doM9TI8K6xQ2tbD3oOUyqgMmTIOCEhWW2r72uFYWAFJX3JB PBUGAY5draq4k7TNnuun6GotUjTbOu9cdVHa2/Mx+e5xmDLEVBVEDPmbVe2t3xgIoKOGiknuUwWP GUzV3lh5m9JqHEKrxdWnz2gPluThYZh2YciRfNY+AOKRUIfhnQrmrZfSHcY6fcu82gM01Y5bAfVq B7cWtm5KfwIDAQABo0IwQDAdBgNVHQ4EFgQUMcN5G7r1U9cX4Il6LRdsCrMrnTMwDwYDVR0TBAgw BgEB/wIBBTAOBgNVHQ8BAf8EBAMCAQYwDQYJKoZIhvcNAQEFBQADggEBAJRkWa05ZOcp6xP+WsOL E1fIBCTwdHfAYONn++mJpoO/loJ8btTDPe+egG67KbSYerE7VOs5F0d+Go4L/B8xWTEEss4X8yzH YjZV4iLYiVW0mEiqZPrWHDbYRHhaWiM6V5f1ejBPrp9qTEsrjqAD4z7gqdTSe9KzqOJyPK2e/4BZ 5JtFtPY7sM05GZgy5eohYZDkMSGONLH3LzVKhRDa54o3Ib5ZY+DyhYgxU9RUFIVwefQuBncndS8f uIr5/sW62Dbkg+znZbe/Y1rzRq+BlDfUQYzWI9Yez/VoG0Rjolq6pzVZoeVwBZsOI1eZlAptujlj KIaS8xiE2PvRzwVWZFcwggOfMIICh6ADAgECAgEmMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYT AkRFMRwwGgYDVQQKExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1 c3QgQ2VudGVyMSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw05OTA3MDkx MjExMDBaFw0xOTA3MDkyMzU5MDBaMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNEZXV0c2NoZSBU ZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVyMSMwIQYDVQQDExpEZXV0 c2NoZSBUZWxla29tIFJvb3QgQ0EgMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKsL ozXgiykUsRSFrzwQ5DlvNV1Krt3qYY2VSfRvZKMaYGakqUAihNnUpeV4kw5oAa25TVw6ztO4qEJA 38+juoJZapIbrBya2ggrJSf5aSNH8eDrLHqb9RMC0H40fMKePABZq/XaDPUyPCusUNrWw96DlMqo DJkyDghIVltq+9rhWFgBSV9yQTwVBgGOXa2quJO0zZ7rp+hqLVI02zrvXHVR2tvzMfnucZgyxFQV RAz5m1Xtrd8YCKCjhopJ7lMFjxlM1d5YeZvSahxCq8XVp89oD5bk4WGYdmHIkXzWPgDikVCH4Z0K 5q2X0h3GOn3LvNoDNNWOWwH1age3FrZuSn8CAwEAAaNCMEAwHQYDVR0OBBYEFDHDeRu69VPXF+CJ ei0XbAqzK50zMA8GA1UdEwQIMAYBAf8CAQUwDgYDVR0PAQH/BAQDAgEGMA0GCSqGSIb3DQEBBQUA A4IBAQCUZFmtOWTnKesT/lrDixNXyAQk8HR3wGDjZ/vpiaaDv5aCfG7Uwz3vnoBuuym0mHqxO1Tr ORdHfhqOC/wfMVkxBLLOF/Msx2I2VeIi2IlVtJhIqmT61hw22ER4WlojOleX9XowT66fakxLK46g A+M+4KnU0nvSs6jicjytnv+AWeSbRbT2O7DNORmYMuXqIWGQ5DEhjjSx9y81SoUQ2ueKNyG+WWPg 8oWIMVPUVBSFcHn0LgZ3J3UvH7iK+f7Futg25IPs52W3v2Na80avgZQ31EGM1iPWHs/1aBtEY6Ja uqc1WaHlcAWbDiNXmZQKbbo5YyiGkvMYhNj70c8FVmRXMIIEITCCAwmgAwIBAgICAMcwDQYJKoZI hvcNAQEFBQAwcTELMAkGA1UEBhMCREUxHDAaBgNVBAoTE0RldXRzY2hlIFRlbGVrb20gQUcxHzAd BgNVBAsTFlQtVGVsZVNlYyBUcnVzdCBDZW50ZXIxIzAhBgNVBAMTGkRldXRzY2hlIFRlbGVrb20g Um9vdCBDQSAyMB4XDTA2MTIxOTEwMjkwMFoXDTE5MDYzMDIzNTkwMFowWjELMAkGA1UEBhMCREUx EzARBgNVBAoTCkRGTi1WZXJlaW4xEDAOBgNVBAsTB0RGTi1QS0kxJDAiBgNVBAMTG0RGTi1WZXJl aW4gUENBIEdsb2JhbCAtIEcwMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAOmbw2eF +Q2u9Y1Uw5ZQNT1i6W5M7ZTXAFuVInTUIOs0j9bswDEEC5mB4qYU0lKgKCOEi3SJBF5b4OJ4wXjL FssoNTl7LZBF0O2gAHp8v0oOGwDDhulcKzERewzzgiRDjBw4i2poAJru3E94q9LGE5t2re7eJujv Aa90D8EJovZrzr3TzRQwT/Xl46TIYpuCGgMnMA0CZWBN7dEJIyqWNVgn03bGcbaQHcTt/zWGfW8z s9sPxRHCioOhlF1Ba9jSEPVM/cpRrNm975KDu9rrixZWVkPP4dUTPaYfJzDNSVTbyRM0mnF1xWzq pwuY+SGdJ68+ozk5SGqMrcmZ+8MS8r0CAwEAAaOB2TCB1jBwBgNVHR8EaTBnMGWgY6Bhhl9odHRw Oi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNybD8tY3Js X2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjAdBgNVHQ4EFgQUSbfGz+g9H3/qRHsT KffxCnA+3mQwHwYDVR0jBBgwFoAUMcN5G7r1U9cX4Il6LRdsCrMrnTMwDgYDVR0PAQH/BAQDAgEG MBIGA1UdEwEB/wQIMAYBAf8CAQIwDQYJKoZIhvcNAQEFBQADggEBADvhWnfASBfcqRjsga9aifC9 KJKmylkYEnDsKPLnrn+WLOfyXRkx9hMrdL29gLK592fJOaJ5O+EREe5reJEzfjtfJid1U2WOM2Pu z3PDsJIjSSFQdSOhHxjilIU9PzPpdyCNor3moYUpQPY/czJYDQlrptqFbMA/u41mZFYkTq4NPzI1 AVvpjILZcllPsYaF8XSFVuXD+Fzzje5Hs1MFcOflTYppgyjhEwmGnl7I6lgeDB/5pNRaBGj9KD6L ArZYtfahLDdXAGerI2iNY6XvmWtc/UtW9qtAhzTUEZJs7IfFCgsHM3K0bwwdVCzYUcfMvzDTQ3Lx Mr+MzkljqAD38hwwggQhMIIDCaADAgECAgIAxzANBgkqhkiG9w0BAQUFADBxMQswCQYDVQQGEwJE RTEcMBoGA1UEChMTRGV1dHNjaGUgVGVsZWtvbSBBRzEfMB0GA1UECxMWVC1UZWxlU2VjIFRydXN0 IENlbnRlcjEjMCEGA1UEAxMaRGV1dHNjaGUgVGVsZWtvbSBSb290IENBIDIwHhcNMDYxMjE5MTAy OTAwWhcNMTkwNjMwMjM1OTAwWjBaMQswCQYDVQQGEwJERTETMBEGA1UEChMKREZOLVZlcmVpbjEQ MA4GA1UECxMHREZOLVBLSTEkMCIGA1UEAxMbREZOLVZlcmVpbiBQQ0EgR2xvYmFsIC0gRzAxMIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA6ZvDZ4X5Da71jVTDllA1PWLpbkztlNcAW5Ui dNQg6zSP1uzAMQQLmYHiphTSUqAoI4SLdIkEXlvg4njBeMsWyyg1OXstkEXQ7aAAeny/Sg4bAMOG 6VwrMRF7DPOCJEOMHDiLamgAmu7cT3ir0sYTm3at7t4m6O8Br3QPwQmi9mvOvdPNFDBP9eXjpMhi m4IaAycwDQJlYE3t0QkjKpY1WCfTdsZxtpAdxO3/NYZ9bzOz2w/FEcKKg6GUXUFr2NIQ9Uz9ylGs 2b3vkoO72uuLFlZWQ8/h1RM9ph8nMM1JVNvJEzSacXXFbOqnC5j5IZ0nrz6jOTlIaoytyZn7wxLy vQIDAQABo4HZMIHWMHAGA1UdHwRpMGcwZaBjoGGGX2h0dHA6Ly9wa2kudGVsZXNlYy5kZS9jZ2kt YmluL3NlcnZpY2UvYWZfRG93bmxvYWRBUkwuY3JsPy1jcmxfZm9ybWF0PVhfNTA5Ji1pc3N1ZXI9 RFRfUk9PVF9DQV8yMB0GA1UdDgQWBBRJt8bP6D0ff+pEexMp9/EKcD7eZDAfBgNVHSMEGDAWgBQx w3kbuvVT1xfgiXotF2wKsyudMzAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIBAjAN BgkqhkiG9w0BAQUFAAOCAQEAO+Fad8BIF9ypGOyBr1qJ8L0okqbKWRgScOwo8ueuf5Ys5/JdGTH2 Eyt0vb2Asrn3Z8k5onk74RER7mt4kTN+O18mJ3VTZY4zY+7Pc8OwkiNJIVB1I6EfGOKUhT0/M+l3 II2iveahhSlA9j9zMlgNCWum2oVswD+7jWZkViROrg0/MjUBW+mMgtlyWU+xhoXxdIVW5cP4XPON 7kezUwVw5+VNimmDKOETCYaeXsjqWB4MH/mk1FoEaP0oPosCtli19qEsN1cAZ6sjaI1jpe+Za1z9 S1b2q0CHNNQRkmzsh8UKCwczcrRvDB1ULNhRx8y/MNNDcvEyv4zOSWOoAPfyHDCCBO8wggPXoAMC AQICBA0hCk0wDQYJKoZIhvcNAQEFBQAwWjELMAkGA1UEBhMCREUxEzARBgNVBAoTCkRGTi1WZXJl aW4xEDAOBgNVBAsTB0RGTi1QS0kxJDAiBgNVBAMTG0RGTi1WZXJlaW4gUENBIEdsb2JhbCAtIEcw MTAeFw0wODEwMjQwODUyMTNaFw0xOTA2MzAwMDAwMDBaMGkxCzAJBgNVBAYTAkRFMS4wLAYDVQQK EyVQaHlzaWthbGlzY2gtVGVjaG5pc2NoZSBCdW5kZXNhbnN0YWx0MQ8wDQYDVQQDEwZQVEIgQ0Ex GTAXBgkqhkiG9w0BCQEWCnBraUBwdGIuZGUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQC8CsKDOSrDYswBi5TfxUlODIYEL4+n66/DnYua0jowQyIWvTFjpITNhwMbfPk1KiFmKx2cvtu7 wR7swUPdNlfWNUGJ7/9Q0AmpdsedTMTyFslgJHnJ1v1aojOhPk/MbTuolZuVuJ1ytlVwJAR5/1XU JpHJ9e6qJJM6CJuo4Ms/3w3uMwgibPaKlSAx2gbI6BKH+p2zlIzoJSDAx64njZClg2i32uLUgoDB 7KEghrdMA2y7nqxzL4Vzb5dY5+y4iZ54txqK7ock+TpfnlBP6RZoChB/qonIle/xv+fqXWeZMhTY BjYHkSc7+shP4Nb4wnLvv8c77uu3BrOe6e1cyDK3AgMBAAGjggGsMIIBqDASBgNVHRMBAf8ECDAG AQH/AgEBMAsGA1UdDwQEAwIBBjAdBgNVHQ4EFgQUxIDQbigVaDFa7HBfeI7hMEM46jQwHwYDVR0j BBgwFoAUSbfGz+g9H3/qRHsTKffxCnA+3mQwFQYDVR0RBA4wDIEKcGtpQHB0Yi5kZTCBiAYDVR0f BIGAMH4wPaA7oDmGN2h0dHA6Ly9jZHAxLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2Ny bC9jYWNybC5jcmwwPaA7oDmGN2h0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2Ev cHViL2NybC9jYWNybC5jcmwwgaIGCCsGAQUFBwEBBIGVMIGSMEcGCCsGAQUFBzAChjtodHRwOi8v Y2RwMS5wY2EuZGZuLmRlL2dsb2JhbC1yb290LWNhL3B1Yi9jYWNlcnQvY2FjZXJ0LmNydDBHBggr BgEFBQcwAoY7aHR0cDovL2NkcDIucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY2FjZXJ0 L2NhY2VydC5jcnQwDQYJKoZIhvcNAQEFBQADggEBAJ3KSKdj6GjgE6pSuE74pBcKLfmC2Phy1Gfj 83Lzx9leQX67sL6uTIV5NTQgQDsjTlqyxRQJ5eYhj+ZjwfVS02pDdD+trg2iGp1WdFFsqyhts+oS M4SpRUuZ83FHEieuWq9teT7bcWPUzckYy4k17u9LAp7+V1h7s6aOpk9RCyA1sSlFTP33O9tpLwXq KpXHK+zG9JOV7kPDHYLAi2Krw5LB91EBSyXWLu7xK4i6prEUGRWVblckx116ikhBFy3cNr2NGfhh KiOCphAeIFPCCxOEvRk/LkZRnZaMnHQsUHVuAs2SBB08coYSjF7/NZAXprZlpI2KZiUfeo6JU9bS UbowggTvMIID16ADAgECAgQNIQpNMA0GCSqGSIb3DQEBBQUAMFoxCzAJBgNVBAYTAkRFMRMwEQYD VQQKEwpERk4tVmVyZWluMRAwDgYDVQQLEwdERk4tUEtJMSQwIgYDVQQDExtERk4tVmVyZWluIFBD QSBHbG9iYWwgLSBHMDEwHhcNMDgxMDI0MDg1MjEzWhcNMTkwNjMwMDAwMDAwWjBpMQswCQYDVQQG EwJERTEuMCwGA1UEChMlUGh5c2lrYWxpc2NoLVRlY2huaXNjaGUgQnVuZGVzYW5zdGFsdDEPMA0G A1UEAxMGUFRCIENBMRkwFwYJKoZIhvcNAQkBFgpwa2lAcHRiLmRlMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAvArCgzkqw2LMAYuU38VJTgyGBC+Pp+uvw52LmtI6MEMiFr0xY6SEzYcD G3z5NSohZisdnL7bu8Ee7MFD3TZX1jVBie//UNAJqXbHnUzE8hbJYCR5ydb9WqIzoT5PzG07qJWb lbidcrZVcCQEef9V1CaRyfXuqiSTOgibqODLP98N7jMIImz2ipUgMdoGyOgSh/qds5SM6CUgwMeu J42QpYNot9ri1IKAweyhIIa3TANsu56scy+Fc2+XWOfsuImeeLcaiu6HJPk6X55QT+kWaAoQf6qJ yJXv8b/n6l1nmTIU2AY2B5EnO/rIT+DW+MJy77/HO+7rtwaznuntXMgytwIDAQABo4IBrDCCAagw EgYDVR0TAQH/BAgwBgEB/wIBATALBgNVHQ8EBAMCAQYwHQYDVR0OBBYEFMSA0G4oFWgxWuxwX3iO 4TBDOOo0MB8GA1UdIwQYMBaAFEm3xs/oPR9/6kR7Eyn38QpwPt5kMBUGA1UdEQQOMAyBCnBraUBw dGIuZGUwgYgGA1UdHwSBgDB+MD2gO6A5hjdodHRwOi8vY2RwMS5wY2EuZGZuLmRlL2dsb2JhbC1y b290LWNhL3B1Yi9jcmwvY2FjcmwuY3JsMD2gO6A5hjdodHRwOi8vY2RwMi5wY2EuZGZuLmRlL2ds b2JhbC1yb290LWNhL3B1Yi9jcmwvY2FjcmwuY3JsMIGiBggrBgEFBQcBAQSBlTCBkjBHBggrBgEF BQcwAoY7aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY2FjZXJ0L2Nh Y2VydC5jcnQwRwYIKwYBBQUHMAKGO2h0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3Qt Y2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MA0GCSqGSIb3DQEBBQUAA4IBAQCdykinY+ho4BOqUrhO +KQXCi35gtj4ctRn4/Ny88fZXkF+u7C+rkyFeTU0IEA7I05assUUCeXmIY/mY8H1UtNqQ3Q/ra4N ohqdVnRRbKsobbPqEjOEqUVLmfNxRxInrlqvbXk+23Fj1M3JGMuJNe7vSwKe/ldYe7OmjqZPUQsg NbEpRUz99zvbaS8F6iqVxyvsxvSTle5Dwx2CwItiq8OSwfdRAUsl1i7u8SuIuqaxFBkVlW5XJMdd eopIQRct3Da9jRn4YSojgqYQHiBTwgsThL0ZPy5GUZ2WjJx0LFB1bgLNkgQdPHKGEoxe/zWQF6a2 ZaSNimYlH3qOiVPW0lG6MIIFCjCCA/KgAwIBAgIHE3VRA4JzBjANBgkqhkiG9w0BAQUFADBpMQsw CQYDVQQGEwJERTEuMCwGA1UEChMlUGh5c2lrYWxpc2NoLVRlY2huaXNjaGUgQnVuZGVzYW5zdGFs dDEPMA0GA1UEAxMGUFRCIENBMRkwFwYJKoZIhvcNAQkBFgpwa2lAcHRiLmRlMB4XDTEyMDMwNjA5 MDU1NVoXDTE1MDMwNjA5MDU1NVowaDELMAkGA1UEBhMCREUxLjAsBgNVBAoTJVBoeXNpa2FsaXNj aC1UZWNobmlzY2hlIEJ1bmRlc2Fuc3RhbHQxDTALBgNVBAsTBFEuNDIxGjAYBgNVBAMTEURyLiBE aWV0ZXIgU2lib2xkMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3A4qPUWvMdRKdf6n 8n4ILMz17CkFLSBykOfvNqK0Xki5G1uEN0Lm4B9OznfnLLetkncla3k/LUVI7CfjFoYM/CS3BfQg gO9sTHi9oTyusMCm+to0JeEJ5oIijmGzIPLRGTXjQP1Hy/HFcRHvSbGNGK2S6hOBiM7Upn1bnZLc 3Y8Cd0SW9Dk0ZB1LfBi4sy+cqzTi0YU5LTfg2blwWJPoZW1zxCerdPMnoAu+EcD3naDjjR6K0A6H 0KIMmb3JsGBW7Uz7yyAllmF3QUpFGL2I6vHdSYBqIaxxv7qsly6juExhZqsxKpyZYeECs+W2fz8B Nzf2nxGHlGDqvzje5gEpUQIDAQABo4IBtjCCAbIwCQYDVR0TBAIwADALBgNVHQ8EBAMCBeAwKQYD VR0lBCIwIAYIKwYBBQUHAwIGCCsGAQUFBwMEBgorBgEEAYI3FAICMB0GA1UdDgQWBBSMITESopjC ckNxeIcM6c7MrI80gzAfBgNVHSMEGDAWgBTEgNBuKBVoMVrscF94juEwQzjqNDAfBgNVHREEGDAW gRRkaWV0ZXIuc2lib2xkQHB0Yi5kZTB3BgNVHR8EcDBuMDWgM6Axhi9odHRwOi8vY2RwMS5wY2Eu ZGZuLmRlL3B0Yi1jYS9wdWIvY3JsL2NhY3JsLmNybDA1oDOgMYYvaHR0cDovL2NkcDIucGNhLmRm bi5kZS9wdGItY2EvcHViL2NybC9jYWNybC5jcmwwgZIGCCsGAQUFBwEBBIGFMIGCMD8GCCsGAQUF BzAChjNodHRwOi8vY2RwMS5wY2EuZGZuLmRlL3B0Yi1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQw PwYIKwYBBQUHMAKGM2h0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvcHRiLWNhL3B1Yi9jYWNlcnQvY2Fj ZXJ0LmNydDANBgkqhkiG9w0BAQUFAAOCAQEADZnBfu/SYDcvnobrn/SPrQkf/b9cXJOiZDDTsT5C TG6M9tP6vp6Ng1JmecoDHesQG4zOBMGo2Bop9lQiXfEXAQlmJL1aE/F+bdFoJ8OLd1+CQOdciKwY ndt+fXP6eZNUPE366bOYM9EFOU0HxjyzJSaZO7aa+POXFeA8teX/KmWuCvLbPAedZBIbj9lcZMwa c1zoLgoHOk+jywDfbNnU8y8KFW6lZ/rpL8L2VUqIVBrdoUkau4Hc2LJ3bRYfU8Usx29sJHMOrW3c k4E63FoujxLVLl9uxsdEN20TJQaY9RsVzTnOJmqa2mLlcG6EkUGOivnP24Wueo2Go+8rT+LuEzCC BQowggPyoAMCAQICBxN1UQOCcwYwDQYJKoZIhvcNAQEFBQAwaTELMAkGA1UEBhMCREUxLjAsBgNV BAoTJVBoeXNpa2FsaXNjaC1UZWNobmlzY2hlIEJ1bmRlc2Fuc3RhbHQxDzANBgNVBAMTBlBUQiBD QTEZMBcGCSqGSIb3DQEJARYKcGtpQHB0Yi5kZTAeFw0xMjAzMDYwOTA1NTVaFw0xNTAzMDYwOTA1 NTVaMGgxCzAJBgNVBAYTAkRFMS4wLAYDVQQKEyVQaHlzaWthbGlzY2gtVGVjaG5pc2NoZSBCdW5k ZXNhbnN0YWx0MQ0wCwYDVQQLEwRRLjQyMRowGAYDVQQDExFEci4gRGlldGVyIFNpYm9sZDCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANwOKj1FrzHUSnX+p/J+CCzM9ewpBS0gcpDn7zai tF5IuRtbhDdC5uAfTs535yy3rZJ3JWt5Py1FSOwn4xaGDPwktwX0IIDvbEx4vaE8rrDApvraNCXh CeaCIo5hsyDy0Rk140D9R8vxxXER70mxjRitkuoTgYjO1KZ9W52S3N2PAndElvQ5NGQdS3wYuLMv nKs04tGFOS034Nm5cFiT6GVtc8Qnq3TzJ6ALvhHA952g440eitAOh9CiDJm9ybBgVu1M+8sgJZZh d0FKRRi9iOrx3UmAaiGscb+6rJcuo7hMYWarMSqcmWHhArPltn8/ATc39p8Rh5Rg6r843uYBKVEC AwEAAaOCAbYwggGyMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgXgMCkGA1UdJQQiMCAGCCsGAQUFBwMC BggrBgEFBQcDBAYKKwYBBAGCNxQCAjAdBgNVHQ4EFgQUjCExEqKYwnJDcXiHDOnOzKyPNIMwHwYD VR0jBBgwFoAUxIDQbigVaDFa7HBfeI7hMEM46jQwHwYDVR0RBBgwFoEUZGlldGVyLnNpYm9sZEBw dGIuZGUwdwYDVR0fBHAwbjA1oDOgMYYvaHR0cDovL2NkcDEucGNhLmRmbi5kZS9wdGItY2EvcHVi L2NybC9jYWNybC5jcmwwNaAzoDGGL2h0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvcHRiLWNhL3B1Yi9j cmwvY2FjcmwuY3JsMIGSBggrBgEFBQcBAQSBhTCBgjA/BggrBgEFBQcwAoYzaHR0cDovL2NkcDEu cGNhLmRmbi5kZS9wdGItY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MD8GCCsGAQUFBzAChjNodHRw Oi8vY2RwMi5wY2EuZGZuLmRlL3B0Yi1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwDQYJKoZIhvcN AQEFBQADggEBAA2ZwX7v0mA3L56G65/0j60JH/2/XFyTomQw07E+QkxujPbT+r6ejYNSZnnKAx3r EBuMzgTBqNgaKfZUIl3xFwEJZiS9WhPxfm3RaCfDi3dfgkDnXIisGJ3bfn1z+nmTVDxN+umzmDPR BTlNB8Y8syUmmTu2mvjzlxXgPLXl/yplrgry2zwHnWQSG4/ZXGTMGnNc6C4KBzpPo8sA32zZ1PMv ChVupWf66S/C9lVKiFQa3aFJGruB3Niyd20WH1PFLMdvbCRzDq1t3JOBOtxaLo8S1S5fbsbHRDdt EyUGmPUbFc05ziZqmtpi5XBuhJFBjor5z9uFrnqNhqPvK0/i7hMxggLJMIICxQIBATB0MGkxCzAJ BgNVBAYTAkRFMS4wLAYDVQQKEyVQaHlzaWthbGlzY2gtVGVjaG5pc2NoZSBCdW5kZXNhbnN0YWx0 MQ8wDQYDVQQDEwZQVEIgQ0ExGTAXBgkqhkiG9w0BCQEWCnBraUBwdGIuZGUCBxN1UQOCcwYwCQYF Kw4DAhoFAKCCASowGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMw ODA3MTIxOTM2WjAjBgkqhkiG9w0BCQQxFgQUkRXNHBj7wtf/0iYZDkgo+QKeoT4wQwYJKoZIhvcN AQkPMTYwNDAHBgUrDgMCHTAOBggqhkiG9w0DAgICAIAwCgYIKoZIhvcNAwcwDQYIKoZIhvcNAwIC ASgwgYUGCyqGSIb3DQEJEAILMXagdDBpMQswCQYDVQQGEwJERTEuMCwGA1UEChMlUGh5c2lrYWxp c2NoLVRlY2huaXNjaGUgQnVuZGVzYW5zdGFsdDEPMA0GA1UEAxMGUFRCIENBMRkwFwYJKoZIhvcN AQkBFgpwa2lAcHRiLmRlAgcTdVEDgnMGMA0GCSqGSIb3DQEBAQUABIIBAL5az++AsFnfl/qCwGh9 DWdZW0VgtBwsZKqG/jbNTokOo694M5yd3O4+BKHkM0pjEec4eftgfUwbBH2Rde8hXQP2Amu2DeEe /4jldYcVbe3UbhebwddZD5a7RU276S3icRAR2aDDEIHT5zYnuu9U9CKPX3SQ+4ozpSbEHmShnTLZ ZUNNSNz5cOwfEu8D+S6uOYfTlAI/AQTr+iEnrm9vIjsf1asARZ+OfCeRWgC9xNZmTBZGnZ1qyqlO D2xxwR7GzSGgIdY7FTF5BcO3iO/TvtqaUE5SQL7WMYRuWx+H+2PHuB7vC1ImJvS5YXMZBJfQ/RUs 8fGQ7tYoQV+ic+D07pgAAAAA ---------z50770_boundary_sign-- --===============3118256893408297054== 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 --===============3118256893408297054==-- From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Wed Aug 7 05:45:52 2013 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 AC7C011E8118 for ; Wed, 7 Aug 2013 05:45:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.148 X-Spam-Level: X-Spam-Status: No, score=-5.148 tagged_above=-999 required=5 tests=[AWL=1.450, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FX1Iivxejw-R for ; Wed, 7 Aug 2013 05:45:47 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by ietfa.amsl.com (Postfix) with ESMTP id C34AB21E8118 for ; Wed, 7 Aug 2013 05:45:45 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id B732C86DAA9 for ; Wed, 7 Aug 2013 12:45: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 ADAB386D529; Wed, 7 Aug 2013 12:45:37 +0000 (UTC) Received: from mx1.bs.ptb.de ([192.53.103.106]) by mail1.ntp.org with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1V737M-000HRM-AJ; Wed, 07 Aug 2013 12:45:37 +0000 Received: from mx1.bs.ptb.de (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id A71EECE709A; Wed, 7 Aug 2013 14:45:22 +0200 (CEST) Received: from rose.bs.ptb.de (rose.bs.ptb.de [141.25.85.201]) by mx1.bs.ptb.de (Postfix) with ESMTP id 916E9CE7082; Wed, 7 Aug 2013 14:45:22 +0200 (CEST) In-Reply-To: <20130807102324.GA17618@roeckx.be> References: <51FAC820.3090401@udel.edu> <20130803174008.GA17578@roeckx.be> <52019C7B.9070602@udel.edu> <20130807102324.GA17618@roeckx.be> To: Kurt Roeckx MIME-Version: 1.0 X-KeepSent: 0D16CB83:CE739C1F-C1257BC0:0045BC00; type=4; name=$KeepSent X-Mailer: IBM Notes Release 9.0 March 08, 2013 Message-ID: From: dieter.sibold@ptb.de Date: Wed, 7 Aug 2013 14:45:18 +0200 X-MIMETrack: S/MIME Sign by Notes Client on Dieter Sibold/PTB(Release 9.0|March 08, 2013) at 07.08.2013 14:45:18, Serialize by Notes Client on Dieter Sibold/PTB(Release 9.0|March 08, 2013) at 07.08.2013 14:45:18, Serialize complete at 07.08.2013 14:45:18, Itemize by Notes Client on Dieter Sibold/PTB(Release 9.0|March 08, 2013) at 07.08.2013 14:45:20, S/MIME Sign complete at 07.08.2013 14:45:20, Serialize by Router on ROSE/PTB(Release 8.5.3FP3HF370 | April 24, 2013) at 08/07/2013 14:45:22, Serialize complete at 08/07/2013 14:45:22 X-SA-Exim-Connect-IP: 192.53.103.106 X-SA-Exim-Rcpt-To: ntpwg-bounces+dieter.sibold=ptb.de@lists.ntp.org, ntpwg@lists.ntp.org X-SA-Exim-Mail-From: dieter.sibold@ptb.de X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) Cc: NTP Working Group , "tictoc@ietf.org" , ntpwg-bounces+dieter.sibold=ptb.de@lists.ntp.org Subject: Re: [ntpwg] security ID submitted for review X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.14 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="===============7411222343171078228==" Errors-To: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Sender: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org This is an S/MIME signed message. --===============7411222343171078228== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary=-------z21885_boundary_sign This is an S/MIME signed message. ---------z21885_boundary_sign Content-Type: multipart/alternative; boundary="=_alternative 004610DEC1257BC0_=" Dies ist eine mehrteilige Nachricht im MIME-Format. --=_alternative 004610DEC1257BC0_= Content-Type: text/plain; charset="US-ASCII" Hello Kurt, thanks for your comments. Your are right that the draft currently does not specifies that the server has to sign the message during cookie message exchange. We shall add this to the next version of the draft. Dieter ---------------------------------- Physikalisch-Technische Bundesanstalt Dr. Dieter Sibold Q.42 - Serversysteme und Datenhaltung QM-Verantwortlicher der Stelle IT-Infrastruktur Bundesallee 100 D-38116 Braunschweig Tel: +49-531-592-84 20 E-Mail: dieter.sibold@ptb.de Von: Kurt Roeckx An: "David L. Mills" Kopie: NTP Working Group , "tictoc@ietf.org" Datum: 07.08.2013 12:23 Betreff: Re: [ntpwg] security ID submitted for review Gesendet von: ntpwg-bounces+dieter.sibold=ptb.de@lists.ntp.org Hi Dave, On Wed, Aug 07, 2013 at 01:01:47AM +0000, David L. Mills wrote: > Kurt, > > Thanks for your reply. As a window of history, the Autokey protocol > was devised during several walks in Regents Park, London, in 1996. > I thought the most significant hazzard was the replay of client > messages requiring extensive server cryptographic computations. At > that time, I did not think that a middle-man attack would be > significant. Both of those assumptions are probably inadvisable > today. > > One problem with Autokey is the assumption that secret keys for each > client can be manufactured using packet header fields and a hash of > a server private value. A middle-man can manipulate the header > fields compromising the client private key. There does not seem to > be a solution for this problem other than requiring server state. This proposal also generates a cookie based on the something the client sends and a secret in the server, which is then encrypted using the client's public key. The ID does not mention that this message is signed by the server, but Stephen's mail said it was. This part is important to avoid the man in the middle attack. So as result the client got a unique secret for him, and only the client and the server known it. It can also be sure that it really comes from the server, so that there can be no man in the middle attack. And the server doesn't need to keep state since it can calculate it again based on what the client sends him. > In the current Autokey design, the MAC computation covers the header > and all extension fields. However, the key used for the MAC > computation in packets with extension fields is not private. > Therefore, in a cut-and-paste attack, an intruder could mix and > match extension fields and simply recalculate the MAC. If the key is not private, by adding extentions to a packet an attacker can just generate anything he wants? > RFC 5906 defines the extension field including the filestamp and > timestamp. The filestamp was designed to reliably associate the > cryptographic media with the current version, as it can be > frequently changed. This might not be useful in current designs. > The timestamp field was designed to detect replays requiring > expensive cryptographic computations which could take up to a > second. However, the "call gap" (minimum headway) provisions nicely > deflect such attacks, so the timestamp field might not be useful in > current designs. Lastly, in the current design, each extension > field is separately signed at the time the data were constructed. > In current designs the signature might be computed at the time of I'm not sure I understand what you're trying to say. I'm not sure what the filestamps are used for. But I assume that for instance for the leap seconds you send when it was last updates. I guess you can sign this once and always send this signed in an extension, even when you're otherwise not using any encryption. Since you already signed it, the overhead of adding that extension is small. The problem I see with only sending the MAC over the ntp headers and not over the extensions is that the extensions can be removed or added and the client can't tell. So it could for instance be replaced with an old version of the extension. I think it's important that the MAC covers everything. Kurt _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg --=_alternative 004610DEC1257BC0_= Content-Type: text/html; charset="US-ASCII" Hello Kurt,

thanks for your comments. Your are right that the draft currently does not specifies that the server has to sign the message during cookie message exchange. We shall add this to the next version of the draft.

Dieter


----------------------------------
Physikalisch-Technische Bundesanstalt
Dr. Dieter Sibold
Q.42 - Serversysteme und Datenhaltung
QM-Verantwortlicher der Stelle IT-Infrastruktur
Bundesallee 100
D-38116 Braunschweig
Tel: +49-531-592-84 20
E-Mail: dieter.sibold@ptb.de



Von:        Kurt Roeckx <kurt@roeckx.be>
An:        "David L. Mills" <mills@udel.edu>
Kopie:        NTP Working Group <ntpwg@lists.ntp.org>, "tictoc@ietf.org" <tictoc@ietf.org>
Datum:        07.08.2013 12:23
Betreff:        Re: [ntpwg] security ID submitted for review
Gesendet von:        ntpwg-bounces+dieter.sibold=ptb.de@lists.ntp.org



Hi Dave,

On Wed, Aug 07, 2013 at 01:01:47AM +0000, David L. Mills wrote:
> Kurt,
>
> Thanks for your reply.  As a window of history, the Autokey protocol
> was devised during several walks in Regents Park, London, in 1996.
> I thought the most significant hazzard was the replay of client
> messages requiring extensive server cryptographic computations.  At
> that time, I did not think that a middle-man attack would be
> significant.  Both of those assumptions are probably inadvisable
> today.
>
> One problem with Autokey is the assumption that secret keys for each
> client can be manufactured using packet header fields and a hash of
> a server private value.  A middle-man can manipulate the header
> fields compromising the client private key.  There does not seem to
> be a solution for this problem other than requiring server state.

This proposal also generates a cookie based on the something the
client sends and a secret in the server, which is then encrypted
using the client's public key.

The ID does not mention that this message is signed by the server,
but Stephen's mail said it was.  This part is important to avoid
the man in the middle attack.

So as result the client got a unique secret for him, and only
the client and the server known it.  It can also be sure that
it really comes from the server, so that there can be no man
in the middle attack.  And the server doesn't need to keep
state since it can calculate it again based on what the client
sends him.

> In the current Autokey design, the MAC computation covers the header
> and all extension fields.  However, the key used for the MAC
> computation in packets with extension fields is not private.
> Therefore, in a cut-and-paste attack, an intruder could mix and
> match extension fields and simply recalculate the MAC.

If the key is not private, by adding extentions to a packet an
attacker can just generate anything he wants?

> RFC 5906 defines the extension field including the filestamp and
> timestamp.  The filestamp was designed to reliably associate the
> cryptographic media with the current version, as it can be
> frequently changed.  This might not be useful in current designs.
> The timestamp field was designed to detect replays requiring
> expensive cryptographic computations which could take up to a
> second.  However, the "call gap" (minimum headway) provisions nicely
> deflect such attacks, so the timestamp field might not be useful in
> current designs.   Lastly, in the current design, each extension
> field is separately signed  at the time the data were constructed.
> In current designs the signature might be computed at the time of

I'm not sure I understand what you're trying to say.

I'm not sure what the filestamps are used for.  But I assume
that for instance for the leap seconds you send when it was
last updates.  I guess you can sign this once and always send
this signed in an extension, even when you're otherwise not
using any encryption.  Since you already signed it, the overhead
of adding that extension is small.

The problem I see with only sending the MAC over the ntp headers
and not over the extensions is that the extensions can be removed
or added and the client can't tell.  So it could for instance
be replaced with an old version of the extension. I think it's
important that the MAC covers everything.


Kurt

_______________________________________________
ntpwg mailing list
ntpwg@lists.ntp.org
http://lists.ntp.org/listinfo/ntpwg
--=_alternative 004610DEC1257BC0_=-- ---------z21885_boundary_sign Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIImgAIBATELMAkGBSsOAwIaBQAwCwYJKoZIhvcNAQcBoIIjkjCCA58w ggKHoAMCAQICASYwDQYJKoZIhvcNAQEFBQAwcTELMAkGA1UEBhMCREUxHDAaBgNVBAoTE0RldXRz Y2hlIFRlbGVrb20gQUcxHzAdBgNVBAsTFlQtVGVsZVNlYyBUcnVzdCBDZW50ZXIxIzAhBgNVBAMT GkRldXRzY2hlIFRlbGVrb20gUm9vdCBDQSAyMB4XDTk5MDcwOTEyMTEwMFoXDTE5MDcwOTIzNTkw MFowcTELMAkGA1UEBhMCREUxHDAaBgNVBAoTE0RldXRzY2hlIFRlbGVrb20gQUcxHzAdBgNVBAsT FlQtVGVsZVNlYyBUcnVzdCBDZW50ZXIxIzAhBgNVBAMTGkRldXRzY2hlIFRlbGVrb20gUm9vdCBD QSAyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAqwujNeCLKRSxFIWvPBDkOW81XUqu 3ephjZVJ9G9koxpgZqSpQCKE2dSl5XiTDmgBrblNXDrO07ioQkDfz6O6gllqkhusHJraCCslJ/lp I0fx4Ossepv1EwLQfjR8wp48AFmr9doM9TI8K6xQ2tbD3oOUyqgMmTIOCEhWW2r72uFYWAFJX3JB PBUGAY5draq4k7TNnuun6GotUjTbOu9cdVHa2/Mx+e5xmDLEVBVEDPmbVe2t3xgIoKOGiknuUwWP GUzV3lh5m9JqHEKrxdWnz2gPluThYZh2YciRfNY+AOKRUIfhnQrmrZfSHcY6fcu82gM01Y5bAfVq B7cWtm5KfwIDAQABo0IwQDAdBgNVHQ4EFgQUMcN5G7r1U9cX4Il6LRdsCrMrnTMwDwYDVR0TBAgw BgEB/wIBBTAOBgNVHQ8BAf8EBAMCAQYwDQYJKoZIhvcNAQEFBQADggEBAJRkWa05ZOcp6xP+WsOL E1fIBCTwdHfAYONn++mJpoO/loJ8btTDPe+egG67KbSYerE7VOs5F0d+Go4L/B8xWTEEss4X8yzH YjZV4iLYiVW0mEiqZPrWHDbYRHhaWiM6V5f1ejBPrp9qTEsrjqAD4z7gqdTSe9KzqOJyPK2e/4BZ 5JtFtPY7sM05GZgy5eohYZDkMSGONLH3LzVKhRDa54o3Ib5ZY+DyhYgxU9RUFIVwefQuBncndS8f uIr5/sW62Dbkg+znZbe/Y1rzRq+BlDfUQYzWI9Yez/VoG0Rjolq6pzVZoeVwBZsOI1eZlAptujlj KIaS8xiE2PvRzwVWZFcwggOfMIICh6ADAgECAgEmMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYT AkRFMRwwGgYDVQQKExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1 c3QgQ2VudGVyMSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw05OTA3MDkx MjExMDBaFw0xOTA3MDkyMzU5MDBaMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNEZXV0c2NoZSBU ZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVyMSMwIQYDVQQDExpEZXV0 c2NoZSBUZWxla29tIFJvb3QgQ0EgMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKsL ozXgiykUsRSFrzwQ5DlvNV1Krt3qYY2VSfRvZKMaYGakqUAihNnUpeV4kw5oAa25TVw6ztO4qEJA 38+juoJZapIbrBya2ggrJSf5aSNH8eDrLHqb9RMC0H40fMKePABZq/XaDPUyPCusUNrWw96DlMqo DJkyDghIVltq+9rhWFgBSV9yQTwVBgGOXa2quJO0zZ7rp+hqLVI02zrvXHVR2tvzMfnucZgyxFQV RAz5m1Xtrd8YCKCjhopJ7lMFjxlM1d5YeZvSahxCq8XVp89oD5bk4WGYdmHIkXzWPgDikVCH4Z0K 5q2X0h3GOn3LvNoDNNWOWwH1age3FrZuSn8CAwEAAaNCMEAwHQYDVR0OBBYEFDHDeRu69VPXF+CJ ei0XbAqzK50zMA8GA1UdEwQIMAYBAf8CAQUwDgYDVR0PAQH/BAQDAgEGMA0GCSqGSIb3DQEBBQUA A4IBAQCUZFmtOWTnKesT/lrDixNXyAQk8HR3wGDjZ/vpiaaDv5aCfG7Uwz3vnoBuuym0mHqxO1Tr ORdHfhqOC/wfMVkxBLLOF/Msx2I2VeIi2IlVtJhIqmT61hw22ER4WlojOleX9XowT66fakxLK46g A+M+4KnU0nvSs6jicjytnv+AWeSbRbT2O7DNORmYMuXqIWGQ5DEhjjSx9y81SoUQ2ueKNyG+WWPg 8oWIMVPUVBSFcHn0LgZ3J3UvH7iK+f7Futg25IPs52W3v2Na80avgZQ31EGM1iPWHs/1aBtEY6Ja uqc1WaHlcAWbDiNXmZQKbbo5YyiGkvMYhNj70c8FVmRXMIIEITCCAwmgAwIBAgICAMcwDQYJKoZI hvcNAQEFBQAwcTELMAkGA1UEBhMCREUxHDAaBgNVBAoTE0RldXRzY2hlIFRlbGVrb20gQUcxHzAd BgNVBAsTFlQtVGVsZVNlYyBUcnVzdCBDZW50ZXIxIzAhBgNVBAMTGkRldXRzY2hlIFRlbGVrb20g Um9vdCBDQSAyMB4XDTA2MTIxOTEwMjkwMFoXDTE5MDYzMDIzNTkwMFowWjELMAkGA1UEBhMCREUx EzARBgNVBAoTCkRGTi1WZXJlaW4xEDAOBgNVBAsTB0RGTi1QS0kxJDAiBgNVBAMTG0RGTi1WZXJl aW4gUENBIEdsb2JhbCAtIEcwMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAOmbw2eF +Q2u9Y1Uw5ZQNT1i6W5M7ZTXAFuVInTUIOs0j9bswDEEC5mB4qYU0lKgKCOEi3SJBF5b4OJ4wXjL FssoNTl7LZBF0O2gAHp8v0oOGwDDhulcKzERewzzgiRDjBw4i2poAJru3E94q9LGE5t2re7eJujv Aa90D8EJovZrzr3TzRQwT/Xl46TIYpuCGgMnMA0CZWBN7dEJIyqWNVgn03bGcbaQHcTt/zWGfW8z s9sPxRHCioOhlF1Ba9jSEPVM/cpRrNm975KDu9rrixZWVkPP4dUTPaYfJzDNSVTbyRM0mnF1xWzq pwuY+SGdJ68+ozk5SGqMrcmZ+8MS8r0CAwEAAaOB2TCB1jBwBgNVHR8EaTBnMGWgY6Bhhl9odHRw Oi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNybD8tY3Js X2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjAdBgNVHQ4EFgQUSbfGz+g9H3/qRHsT KffxCnA+3mQwHwYDVR0jBBgwFoAUMcN5G7r1U9cX4Il6LRdsCrMrnTMwDgYDVR0PAQH/BAQDAgEG MBIGA1UdEwEB/wQIMAYBAf8CAQIwDQYJKoZIhvcNAQEFBQADggEBADvhWnfASBfcqRjsga9aifC9 KJKmylkYEnDsKPLnrn+WLOfyXRkx9hMrdL29gLK592fJOaJ5O+EREe5reJEzfjtfJid1U2WOM2Pu z3PDsJIjSSFQdSOhHxjilIU9PzPpdyCNor3moYUpQPY/czJYDQlrptqFbMA/u41mZFYkTq4NPzI1 AVvpjILZcllPsYaF8XSFVuXD+Fzzje5Hs1MFcOflTYppgyjhEwmGnl7I6lgeDB/5pNRaBGj9KD6L ArZYtfahLDdXAGerI2iNY6XvmWtc/UtW9qtAhzTUEZJs7IfFCgsHM3K0bwwdVCzYUcfMvzDTQ3Lx Mr+MzkljqAD38hwwggQhMIIDCaADAgECAgIAxzANBgkqhkiG9w0BAQUFADBxMQswCQYDVQQGEwJE RTEcMBoGA1UEChMTRGV1dHNjaGUgVGVsZWtvbSBBRzEfMB0GA1UECxMWVC1UZWxlU2VjIFRydXN0 IENlbnRlcjEjMCEGA1UEAxMaRGV1dHNjaGUgVGVsZWtvbSBSb290IENBIDIwHhcNMDYxMjE5MTAy OTAwWhcNMTkwNjMwMjM1OTAwWjBaMQswCQYDVQQGEwJERTETMBEGA1UEChMKREZOLVZlcmVpbjEQ MA4GA1UECxMHREZOLVBLSTEkMCIGA1UEAxMbREZOLVZlcmVpbiBQQ0EgR2xvYmFsIC0gRzAxMIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA6ZvDZ4X5Da71jVTDllA1PWLpbkztlNcAW5Ui dNQg6zSP1uzAMQQLmYHiphTSUqAoI4SLdIkEXlvg4njBeMsWyyg1OXstkEXQ7aAAeny/Sg4bAMOG 6VwrMRF7DPOCJEOMHDiLamgAmu7cT3ir0sYTm3at7t4m6O8Br3QPwQmi9mvOvdPNFDBP9eXjpMhi m4IaAycwDQJlYE3t0QkjKpY1WCfTdsZxtpAdxO3/NYZ9bzOz2w/FEcKKg6GUXUFr2NIQ9Uz9ylGs 2b3vkoO72uuLFlZWQ8/h1RM9ph8nMM1JVNvJEzSacXXFbOqnC5j5IZ0nrz6jOTlIaoytyZn7wxLy vQIDAQABo4HZMIHWMHAGA1UdHwRpMGcwZaBjoGGGX2h0dHA6Ly9wa2kudGVsZXNlYy5kZS9jZ2kt YmluL3NlcnZpY2UvYWZfRG93bmxvYWRBUkwuY3JsPy1jcmxfZm9ybWF0PVhfNTA5Ji1pc3N1ZXI9 RFRfUk9PVF9DQV8yMB0GA1UdDgQWBBRJt8bP6D0ff+pEexMp9/EKcD7eZDAfBgNVHSMEGDAWgBQx w3kbuvVT1xfgiXotF2wKsyudMzAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIBAjAN BgkqhkiG9w0BAQUFAAOCAQEAO+Fad8BIF9ypGOyBr1qJ8L0okqbKWRgScOwo8ueuf5Ys5/JdGTH2 Eyt0vb2Asrn3Z8k5onk74RER7mt4kTN+O18mJ3VTZY4zY+7Pc8OwkiNJIVB1I6EfGOKUhT0/M+l3 II2iveahhSlA9j9zMlgNCWum2oVswD+7jWZkViROrg0/MjUBW+mMgtlyWU+xhoXxdIVW5cP4XPON 7kezUwVw5+VNimmDKOETCYaeXsjqWB4MH/mk1FoEaP0oPosCtli19qEsN1cAZ6sjaI1jpe+Za1z9 S1b2q0CHNNQRkmzsh8UKCwczcrRvDB1ULNhRx8y/MNNDcvEyv4zOSWOoAPfyHDCCBO8wggPXoAMC AQICBA0hCk0wDQYJKoZIhvcNAQEFBQAwWjELMAkGA1UEBhMCREUxEzARBgNVBAoTCkRGTi1WZXJl aW4xEDAOBgNVBAsTB0RGTi1QS0kxJDAiBgNVBAMTG0RGTi1WZXJlaW4gUENBIEdsb2JhbCAtIEcw MTAeFw0wODEwMjQwODUyMTNaFw0xOTA2MzAwMDAwMDBaMGkxCzAJBgNVBAYTAkRFMS4wLAYDVQQK EyVQaHlzaWthbGlzY2gtVGVjaG5pc2NoZSBCdW5kZXNhbnN0YWx0MQ8wDQYDVQQDEwZQVEIgQ0Ex GTAXBgkqhkiG9w0BCQEWCnBraUBwdGIuZGUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQC8CsKDOSrDYswBi5TfxUlODIYEL4+n66/DnYua0jowQyIWvTFjpITNhwMbfPk1KiFmKx2cvtu7 wR7swUPdNlfWNUGJ7/9Q0AmpdsedTMTyFslgJHnJ1v1aojOhPk/MbTuolZuVuJ1ytlVwJAR5/1XU JpHJ9e6qJJM6CJuo4Ms/3w3uMwgibPaKlSAx2gbI6BKH+p2zlIzoJSDAx64njZClg2i32uLUgoDB 7KEghrdMA2y7nqxzL4Vzb5dY5+y4iZ54txqK7ock+TpfnlBP6RZoChB/qonIle/xv+fqXWeZMhTY BjYHkSc7+shP4Nb4wnLvv8c77uu3BrOe6e1cyDK3AgMBAAGjggGsMIIBqDASBgNVHRMBAf8ECDAG AQH/AgEBMAsGA1UdDwQEAwIBBjAdBgNVHQ4EFgQUxIDQbigVaDFa7HBfeI7hMEM46jQwHwYDVR0j BBgwFoAUSbfGz+g9H3/qRHsTKffxCnA+3mQwFQYDVR0RBA4wDIEKcGtpQHB0Yi5kZTCBiAYDVR0f BIGAMH4wPaA7oDmGN2h0dHA6Ly9jZHAxLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2Ny bC9jYWNybC5jcmwwPaA7oDmGN2h0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2Ev cHViL2NybC9jYWNybC5jcmwwgaIGCCsGAQUFBwEBBIGVMIGSMEcGCCsGAQUFBzAChjtodHRwOi8v Y2RwMS5wY2EuZGZuLmRlL2dsb2JhbC1yb290LWNhL3B1Yi9jYWNlcnQvY2FjZXJ0LmNydDBHBggr BgEFBQcwAoY7aHR0cDovL2NkcDIucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY2FjZXJ0 L2NhY2VydC5jcnQwDQYJKoZIhvcNAQEFBQADggEBAJ3KSKdj6GjgE6pSuE74pBcKLfmC2Phy1Gfj 83Lzx9leQX67sL6uTIV5NTQgQDsjTlqyxRQJ5eYhj+ZjwfVS02pDdD+trg2iGp1WdFFsqyhts+oS M4SpRUuZ83FHEieuWq9teT7bcWPUzckYy4k17u9LAp7+V1h7s6aOpk9RCyA1sSlFTP33O9tpLwXq KpXHK+zG9JOV7kPDHYLAi2Krw5LB91EBSyXWLu7xK4i6prEUGRWVblckx116ikhBFy3cNr2NGfhh KiOCphAeIFPCCxOEvRk/LkZRnZaMnHQsUHVuAs2SBB08coYSjF7/NZAXprZlpI2KZiUfeo6JU9bS UbowggTvMIID16ADAgECAgQNIQpNMA0GCSqGSIb3DQEBBQUAMFoxCzAJBgNVBAYTAkRFMRMwEQYD VQQKEwpERk4tVmVyZWluMRAwDgYDVQQLEwdERk4tUEtJMSQwIgYDVQQDExtERk4tVmVyZWluIFBD QSBHbG9iYWwgLSBHMDEwHhcNMDgxMDI0MDg1MjEzWhcNMTkwNjMwMDAwMDAwWjBpMQswCQYDVQQG EwJERTEuMCwGA1UEChMlUGh5c2lrYWxpc2NoLVRlY2huaXNjaGUgQnVuZGVzYW5zdGFsdDEPMA0G A1UEAxMGUFRCIENBMRkwFwYJKoZIhvcNAQkBFgpwa2lAcHRiLmRlMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAvArCgzkqw2LMAYuU38VJTgyGBC+Pp+uvw52LmtI6MEMiFr0xY6SEzYcD G3z5NSohZisdnL7bu8Ee7MFD3TZX1jVBie//UNAJqXbHnUzE8hbJYCR5ydb9WqIzoT5PzG07qJWb lbidcrZVcCQEef9V1CaRyfXuqiSTOgibqODLP98N7jMIImz2ipUgMdoGyOgSh/qds5SM6CUgwMeu J42QpYNot9ri1IKAweyhIIa3TANsu56scy+Fc2+XWOfsuImeeLcaiu6HJPk6X55QT+kWaAoQf6qJ yJXv8b/n6l1nmTIU2AY2B5EnO/rIT+DW+MJy77/HO+7rtwaznuntXMgytwIDAQABo4IBrDCCAagw EgYDVR0TAQH/BAgwBgEB/wIBATALBgNVHQ8EBAMCAQYwHQYDVR0OBBYEFMSA0G4oFWgxWuxwX3iO 4TBDOOo0MB8GA1UdIwQYMBaAFEm3xs/oPR9/6kR7Eyn38QpwPt5kMBUGA1UdEQQOMAyBCnBraUBw dGIuZGUwgYgGA1UdHwSBgDB+MD2gO6A5hjdodHRwOi8vY2RwMS5wY2EuZGZuLmRlL2dsb2JhbC1y b290LWNhL3B1Yi9jcmwvY2FjcmwuY3JsMD2gO6A5hjdodHRwOi8vY2RwMi5wY2EuZGZuLmRlL2ds b2JhbC1yb290LWNhL3B1Yi9jcmwvY2FjcmwuY3JsMIGiBggrBgEFBQcBAQSBlTCBkjBHBggrBgEF BQcwAoY7aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY2FjZXJ0L2Nh Y2VydC5jcnQwRwYIKwYBBQUHMAKGO2h0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3Qt Y2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MA0GCSqGSIb3DQEBBQUAA4IBAQCdykinY+ho4BOqUrhO +KQXCi35gtj4ctRn4/Ny88fZXkF+u7C+rkyFeTU0IEA7I05assUUCeXmIY/mY8H1UtNqQ3Q/ra4N ohqdVnRRbKsobbPqEjOEqUVLmfNxRxInrlqvbXk+23Fj1M3JGMuJNe7vSwKe/ldYe7OmjqZPUQsg NbEpRUz99zvbaS8F6iqVxyvsxvSTle5Dwx2CwItiq8OSwfdRAUsl1i7u8SuIuqaxFBkVlW5XJMdd eopIQRct3Da9jRn4YSojgqYQHiBTwgsThL0ZPy5GUZ2WjJx0LFB1bgLNkgQdPHKGEoxe/zWQF6a2 ZaSNimYlH3qOiVPW0lG6MIIFCjCCA/KgAwIBAgIHE3VRA4JzBjANBgkqhkiG9w0BAQUFADBpMQsw CQYDVQQGEwJERTEuMCwGA1UEChMlUGh5c2lrYWxpc2NoLVRlY2huaXNjaGUgQnVuZGVzYW5zdGFs dDEPMA0GA1UEAxMGUFRCIENBMRkwFwYJKoZIhvcNAQkBFgpwa2lAcHRiLmRlMB4XDTEyMDMwNjA5 MDU1NVoXDTE1MDMwNjA5MDU1NVowaDELMAkGA1UEBhMCREUxLjAsBgNVBAoTJVBoeXNpa2FsaXNj aC1UZWNobmlzY2hlIEJ1bmRlc2Fuc3RhbHQxDTALBgNVBAsTBFEuNDIxGjAYBgNVBAMTEURyLiBE aWV0ZXIgU2lib2xkMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3A4qPUWvMdRKdf6n 8n4ILMz17CkFLSBykOfvNqK0Xki5G1uEN0Lm4B9OznfnLLetkncla3k/LUVI7CfjFoYM/CS3BfQg gO9sTHi9oTyusMCm+to0JeEJ5oIijmGzIPLRGTXjQP1Hy/HFcRHvSbGNGK2S6hOBiM7Upn1bnZLc 3Y8Cd0SW9Dk0ZB1LfBi4sy+cqzTi0YU5LTfg2blwWJPoZW1zxCerdPMnoAu+EcD3naDjjR6K0A6H 0KIMmb3JsGBW7Uz7yyAllmF3QUpFGL2I6vHdSYBqIaxxv7qsly6juExhZqsxKpyZYeECs+W2fz8B Nzf2nxGHlGDqvzje5gEpUQIDAQABo4IBtjCCAbIwCQYDVR0TBAIwADALBgNVHQ8EBAMCBeAwKQYD VR0lBCIwIAYIKwYBBQUHAwIGCCsGAQUFBwMEBgorBgEEAYI3FAICMB0GA1UdDgQWBBSMITESopjC ckNxeIcM6c7MrI80gzAfBgNVHSMEGDAWgBTEgNBuKBVoMVrscF94juEwQzjqNDAfBgNVHREEGDAW gRRkaWV0ZXIuc2lib2xkQHB0Yi5kZTB3BgNVHR8EcDBuMDWgM6Axhi9odHRwOi8vY2RwMS5wY2Eu ZGZuLmRlL3B0Yi1jYS9wdWIvY3JsL2NhY3JsLmNybDA1oDOgMYYvaHR0cDovL2NkcDIucGNhLmRm bi5kZS9wdGItY2EvcHViL2NybC9jYWNybC5jcmwwgZIGCCsGAQUFBwEBBIGFMIGCMD8GCCsGAQUF BzAChjNodHRwOi8vY2RwMS5wY2EuZGZuLmRlL3B0Yi1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQw PwYIKwYBBQUHMAKGM2h0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvcHRiLWNhL3B1Yi9jYWNlcnQvY2Fj ZXJ0LmNydDANBgkqhkiG9w0BAQUFAAOCAQEADZnBfu/SYDcvnobrn/SPrQkf/b9cXJOiZDDTsT5C TG6M9tP6vp6Ng1JmecoDHesQG4zOBMGo2Bop9lQiXfEXAQlmJL1aE/F+bdFoJ8OLd1+CQOdciKwY ndt+fXP6eZNUPE366bOYM9EFOU0HxjyzJSaZO7aa+POXFeA8teX/KmWuCvLbPAedZBIbj9lcZMwa c1zoLgoHOk+jywDfbNnU8y8KFW6lZ/rpL8L2VUqIVBrdoUkau4Hc2LJ3bRYfU8Usx29sJHMOrW3c k4E63FoujxLVLl9uxsdEN20TJQaY9RsVzTnOJmqa2mLlcG6EkUGOivnP24Wueo2Go+8rT+LuEzCC BQowggPyoAMCAQICBxN1UQOCcwYwDQYJKoZIhvcNAQEFBQAwaTELMAkGA1UEBhMCREUxLjAsBgNV BAoTJVBoeXNpa2FsaXNjaC1UZWNobmlzY2hlIEJ1bmRlc2Fuc3RhbHQxDzANBgNVBAMTBlBUQiBD QTEZMBcGCSqGSIb3DQEJARYKcGtpQHB0Yi5kZTAeFw0xMjAzMDYwOTA1NTVaFw0xNTAzMDYwOTA1 NTVaMGgxCzAJBgNVBAYTAkRFMS4wLAYDVQQKEyVQaHlzaWthbGlzY2gtVGVjaG5pc2NoZSBCdW5k ZXNhbnN0YWx0MQ0wCwYDVQQLEwRRLjQyMRowGAYDVQQDExFEci4gRGlldGVyIFNpYm9sZDCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANwOKj1FrzHUSnX+p/J+CCzM9ewpBS0gcpDn7zai tF5IuRtbhDdC5uAfTs535yy3rZJ3JWt5Py1FSOwn4xaGDPwktwX0IIDvbEx4vaE8rrDApvraNCXh CeaCIo5hsyDy0Rk140D9R8vxxXER70mxjRitkuoTgYjO1KZ9W52S3N2PAndElvQ5NGQdS3wYuLMv nKs04tGFOS034Nm5cFiT6GVtc8Qnq3TzJ6ALvhHA952g440eitAOh9CiDJm9ybBgVu1M+8sgJZZh d0FKRRi9iOrx3UmAaiGscb+6rJcuo7hMYWarMSqcmWHhArPltn8/ATc39p8Rh5Rg6r843uYBKVEC AwEAAaOCAbYwggGyMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgXgMCkGA1UdJQQiMCAGCCsGAQUFBwMC BggrBgEFBQcDBAYKKwYBBAGCNxQCAjAdBgNVHQ4EFgQUjCExEqKYwnJDcXiHDOnOzKyPNIMwHwYD VR0jBBgwFoAUxIDQbigVaDFa7HBfeI7hMEM46jQwHwYDVR0RBBgwFoEUZGlldGVyLnNpYm9sZEBw dGIuZGUwdwYDVR0fBHAwbjA1oDOgMYYvaHR0cDovL2NkcDEucGNhLmRmbi5kZS9wdGItY2EvcHVi L2NybC9jYWNybC5jcmwwNaAzoDGGL2h0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvcHRiLWNhL3B1Yi9j cmwvY2FjcmwuY3JsMIGSBggrBgEFBQcBAQSBhTCBgjA/BggrBgEFBQcwAoYzaHR0cDovL2NkcDEu cGNhLmRmbi5kZS9wdGItY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MD8GCCsGAQUFBzAChjNodHRw Oi8vY2RwMi5wY2EuZGZuLmRlL3B0Yi1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwDQYJKoZIhvcN AQEFBQADggEBAA2ZwX7v0mA3L56G65/0j60JH/2/XFyTomQw07E+QkxujPbT+r6ejYNSZnnKAx3r EBuMzgTBqNgaKfZUIl3xFwEJZiS9WhPxfm3RaCfDi3dfgkDnXIisGJ3bfn1z+nmTVDxN+umzmDPR BTlNB8Y8syUmmTu2mvjzlxXgPLXl/yplrgry2zwHnWQSG4/ZXGTMGnNc6C4KBzpPo8sA32zZ1PMv ChVupWf66S/C9lVKiFQa3aFJGruB3Niyd20WH1PFLMdvbCRzDq1t3JOBOtxaLo8S1S5fbsbHRDdt EyUGmPUbFc05ziZqmtpi5XBuhJFBjor5z9uFrnqNhqPvK0/i7hMxggLJMIICxQIBATB0MGkxCzAJ BgNVBAYTAkRFMS4wLAYDVQQKEyVQaHlzaWthbGlzY2gtVGVjaG5pc2NoZSBCdW5kZXNhbnN0YWx0 MQ8wDQYDVQQDEwZQVEIgQ0ExGTAXBgkqhkiG9w0BCQEWCnBraUBwdGIuZGUCBxN1UQOCcwYwCQYF Kw4DAhoFAKCCASowGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMw ODA3MTI0NTIwWjAjBgkqhkiG9w0BCQQxFgQU1vTQ0xUEY/ygpIEM7Yr6VkbSAsMwQwYJKoZIhvcN AQkPMTYwNDAHBgUrDgMCHTAOBggqhkiG9w0DAgICAIAwCgYIKoZIhvcNAwcwDQYIKoZIhvcNAwIC ASgwgYUGCyqGSIb3DQEJEAILMXagdDBpMQswCQYDVQQGEwJERTEuMCwGA1UEChMlUGh5c2lrYWxp c2NoLVRlY2huaXNjaGUgQnVuZGVzYW5zdGFsdDEPMA0GA1UEAxMGUFRCIENBMRkwFwYJKoZIhvcN AQkBFgpwa2lAcHRiLmRlAgcTdVEDgnMGMA0GCSqGSIb3DQEBAQUABIIBAEBUrBRGiNQiYClCDbXK qnWJ8OphOv0d6s479Gl/t+1mTwD5VjwdDypr+plJRXHqAMzPiXjrtP2o8MOhiDd2bEfQJmnVv0PK f5hymRUnZYFEBEyJBGui6yP0UVDOar73Wf5q2nenkInT56bkFhYXQy768ib/681KryOpFepHXkmb gtOQIF5DMJOqJGVNPb47/793UC82objV7LjLij5IwMYKc5Q5uRB29y2C8FTTlXU5k8UbYusvIpmJ 0XyrByrAuHizfAzbD7ksXvq2gXzf4f2QG6epn5eiz+ghGtiPdPTU0+nIQ0p54PTk+LukXp9KrZvk VsjTe2Z1o6g658GgXpoAAAAA ---------z21885_boundary_sign-- --===============7411222343171078228== 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 --===============7411222343171078228==-- From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Wed Aug 7 08:16:58 2013 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 4CAA821E813B for ; Wed, 7 Aug 2013 08:16:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.199 X-Spam-Level: X-Spam-Status: No, score=-5.199 tagged_above=-999 required=5 tests=[AWL=1.400, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IEk0ydJxWB-x for ; Wed, 7 Aug 2013 08:16:53 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by ietfa.amsl.com (Postfix) with ESMTP id 557C911E8142 for ; Wed, 7 Aug 2013 08:16:49 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id 468AD86DADB for ; Wed, 7 Aug 2013 15:16:49 +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 612E486D422 for ; Wed, 7 Aug 2013 15:16:40 +0000 (UTC) Received: from jacques.telenet-ops.be ([195.130.132.50]) by mail1.ntp.org with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1V75Tb-000IED-67 for ntpwg@lists.ntp.org; Wed, 07 Aug 2013 15:16:40 +0000 Received: from intrepid.roeckx.be ([94.226.199.45]) by jacques.telenet-ops.be with bizsmtp id 9rGd1m00o0zFtyu0JrGdxs; Wed, 07 Aug 2013 17:16:37 +0200 Received: by intrepid.roeckx.be (Postfix, from userid 1000) id 2C9B0EB20B; Wed, 7 Aug 2013 17:16:37 +0200 (CEST) Date: Wed, 7 Aug 2013 17:16:37 +0200 From: Kurt Roeckx To: NTP Working Group , "tictoc@ietf.org" Message-ID: <20130807151637.GA31292@roeckx.be> References: <51FAC820.3090401@udel.edu> <20130803174008.GA17578@roeckx.be> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20130803174008.GA17578@roeckx.be> User-Agent: Mutt/1.5.21 (2010-09-15) X-SA-Exim-Connect-IP: 195.130.132.50 X-SA-Exim-Rcpt-To: ntpwg@lists.ntp.org X-SA-Exim-Mail-From: kurt@roeckx.be X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) Subject: Re: [ntpwg] security ID submitted for review X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.14 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 Errors-To: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Sender: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org On Sat, Aug 03, 2013 at 07:40:08PM +0200, Kurt Roeckx wrote: > > I really don't understand how such a man in the middle attack > can work. Either the certificate + the chain validate, or they > don't. It is of course important to you check that the CommonName > in the certificate matches the server you're trying to reach, > and that the root CA is in your list of trusted CAs. But there > really isn't anything new or hard about this. So thinking about this so more, I do see 1 problem with this. I would like to be able to use this for the pool for those that wish to use it. But if you're verify the certificate you're not going to know which server you're talking too, so there is no way to check the CommonName. Does it make sense to just skip this check in case of the pool? Kurt _______________________________________________ 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 Wed Aug 7 09:27:59 2013 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 EF36121F9C59 for ; Wed, 7 Aug 2013 09:27:58 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JLON0hMwmL7J for ; Wed, 7 Aug 2013 09:27:53 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [IPv6:2001:4f8:fff7:1::7]) by ietfa.amsl.com (Postfix) with ESMTP id 8304321E8135 for ; Wed, 7 Aug 2013 09:27:52 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id EAC6686D766 for ; Wed, 7 Aug 2013 16:27: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 0B67086D422 for ; Wed, 7 Aug 2013 16:27:41 +0000 (UTC) Received: from elasmtp-curtail.atl.sa.earthlink.net ([209.86.89.64]) by mail1.ntp.org with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1V76aJ-000Icy-Vn for ntpwg@lists.ntp.org; Wed, 07 Aug 2013 16:27:41 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=NgyWNTKvqJv+dnWNwfef0MtgSWYEfgkOmr3fmdIDr9C84RiTjucIZ6UMCecZSdgB; 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.21] (helo=[192.168.1.102]) by elasmtp-curtail.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1V76aD-0007Iq-Lt for ntpwg@lists.ntp.org; Wed, 07 Aug 2013 12:27:33 -0400 Message-ID: <52027574.4060507@earthlink.net> Date: Wed, 07 Aug 2013 09:27:32 -0700 From: tsg User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: ntpwg@lists.ntp.org References: <51FAC820.3090401@udel.edu> <20130803174008.GA17578@roeckx.be> <20130807151637.GA31292@roeckx.be> In-Reply-To: <20130807151637.GA31292@roeckx.be> X-ELNK-Trace: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec796b976faf92eeb08ce6af0cafd9f0f0d4350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 67.180.133.21 X-SA-Exim-Connect-IP: 209.86.89.64 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] security ID submitted for review X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: IETF Working Group for Network Time Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Sender: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org On 08/07/2013 08:16 AM, Kurt Roeckx wrote: > On Sat, Aug 03, 2013 at 07:40:08PM +0200, Kurt Roeckx wrote: >> I really don't understand how such a man in the middle attack >> can work. Either the certificate + the chain validate, or they >> don't. It is of course important to you check that the CommonName >> in the certificate matches the server you're trying to reach, >> and that the root CA is in your list of trusted CAs. But there >> really isn't anything new or hard about this. > So thinking about this so more, I do see 1 problem with this. I > would like to be able to use this for the pool for those that wish > to use it. But if you're verify the certificate you're not going > to know which server you're talking too, so there is no way to > check the CommonName. Does it make sense to just skip this > check in case of the pool? Yes. > > > Kurt > > _______________________________________________ > ntpwg mailing list > ntpwg@lists.ntp.org > http://lists.ntp.org/listinfo/ntpwg > -- // Standard "perasonal email" disclaimers apply _______________________________________________ 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 Wed Aug 7 11:10:30 2013 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 DE50521F99D5 for ; Wed, 7 Aug 2013 11:10:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.326 X-Spam-Level: X-Spam-Status: No, score=-5.326 tagged_above=-999 required=5 tests=[AWL=1.273, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nl4VNauWuJMX for ; Wed, 7 Aug 2013 11:10:25 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by ietfa.amsl.com (Postfix) with ESMTP id 93A7921F9E70 for ; Wed, 7 Aug 2013 11:10:23 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id BD82F86DAB4 for ; Wed, 7 Aug 2013 18:10:21 +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 CADEE86D534 for ; Wed, 7 Aug 2013 18:10:10 +0000 (UTC) Received: from gerard.telenet-ops.be ([195.130.132.48]) by mail1.ntp.org with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1V78BU-000JEF-Sx for ntpwg@lists.ntp.org; Wed, 07 Aug 2013 18:10:10 +0000 Received: from intrepid.roeckx.be ([94.226.199.45]) by gerard.telenet-ops.be with bizsmtp id 9uA61m0070zFtyu0HuA6bA; Wed, 07 Aug 2013 20:10:06 +0200 Received: by intrepid.roeckx.be (Postfix, from userid 1000) id E5918EB20B; Wed, 7 Aug 2013 20:10:05 +0200 (CEST) Date: Wed, 7 Aug 2013 20:10:05 +0200 From: Kurt Roeckx To: tsg Message-ID: <20130807181005.GA2086@roeckx.be> References: <51FAC820.3090401@udel.edu> <20130803174008.GA17578@roeckx.be> <20130807151637.GA31292@roeckx.be> <52027574.4060507@earthlink.net> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <52027574.4060507@earthlink.net> User-Agent: Mutt/1.5.21 (2010-09-15) X-SA-Exim-Connect-IP: 195.130.132.48 X-SA-Exim-Rcpt-To: ntpwg@lists.ntp.org X-SA-Exim-Mail-From: kurt@roeckx.be X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) Cc: ntpwg@lists.ntp.org Subject: Re: [ntpwg] security ID submitted for review X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.14 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 Errors-To: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Sender: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org On Wed, Aug 07, 2013 at 09:27:32AM -0700, tsg wrote: > On 08/07/2013 08:16 AM, Kurt Roeckx wrote: > >On Sat, Aug 03, 2013 at 07:40:08PM +0200, Kurt Roeckx wrote: > >>I really don't understand how such a man in the middle attack > >>can work. Either the certificate + the chain validate, or they > >>don't. It is of course important to you check that the CommonName > >>in the certificate matches the server you're trying to reach, > >>and that the root CA is in your list of trusted CAs. But there > >>really isn't anything new or hard about this. > >So thinking about this so more, I do see 1 problem with this. I > >would like to be able to use this for the pool for those that wish > >to use it. But if you're verify the certificate you're not going > >to know which server you're talking too, so there is no way to > >check the CommonName. Does it make sense to just skip this > >check in case of the pool? > > Yes. After some thinking, I have to disagree. That check is important to prevent a man in the middle attack. The only think you're going to get then is signed messages, but you have no idea who signed it. So you might as well not sign them since they don't add anything at all. The only way I can see this working without the client doing the CommonName check is that you are able to delegate that check to someone else. In case of the pool system, that would mean that the pool system will needs to know the hostname (it now only has the ip addres I think), check that it matches, and have a secure way to transfer that to the client. That secure way would then probably be DNSSEC, but ntp.org currently doesn't seem to have that set up. I'm not sure it would require the pool system to have names that only resolv to verified servers. But some people might want to make sure that all the servers it's using are verified. Kurt _______________________________________________ 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 Aug 8 00:20:50 2013 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 563BD11E81CA for ; Thu, 8 Aug 2013 00:20:50 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VGs7ez74P9lM for ; Thu, 8 Aug 2013 00:20: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 7276911E81B8 for ; Thu, 8 Aug 2013 00:20:45 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id 115CD86D77A for ; Thu, 8 Aug 2013 07:20:43 +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 0A65686D333 for ; Thu, 8 Aug 2013 07:20:21 +0000 (UTC) Received: from smtp64.intersmtp.com ([62.239.224.237] helo=smtpe1.intersmtp.com) by mail1.ntp.org with esmtps (TLSv1:RC4-MD5:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1V7KWC-000NTb-2A for ntpwg@lists.ntp.org; Thu, 08 Aug 2013 07:20:21 +0000 Received: from EVMHT67-UKRD.domain1.systemhost.net (10.36.3.104) by RDW083A008ED64.smtp-e4.hygiene.service (10.187.98.13) with Microsoft SMTP Server (TLS) id 8.3.298.1; Thu, 8 Aug 2013 08:20:10 +0100 Received: from EMV63-UKRD.domain1.systemhost.net ([169.254.2.224]) by EVMHT67-UKRD.domain1.systemhost.net ([10.36.3.104]) with mapi; Thu, 8 Aug 2013 08:20:10 +0100 From: To: , Date: Thu, 8 Aug 2013 08:20:09 +0100 Thread-Topic: [ntpwg] security ID submitted for review Thread-Index: Ac6TmWGKmF76kwBBQjCzJlfp6pdBNQAbccVA Message-ID: <2C2CFDF697AA1A44B6013D774F3565D06964ABEF15@EMV63-UKRD.domain1.systemhost.net> References: <51FAC820.3090401@udel.edu> <20130803174008.GA17578@roeckx.be> <20130807151637.GA31292@roeckx.be> <52027574.4060507@earthlink.net> <20130807181005.GA2086@roeckx.be> In-Reply-To: <20130807181005.GA2086@roeckx.be> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB MIME-Version: 1.0 X-SA-Exim-Connect-IP: 62.239.224.237 X-SA-Exim-Rcpt-To: ntpwg@lists.ntp.org X-SA-Exim-Mail-From: anthony.flavin@bt.com X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) Cc: ntpwg@lists.ntp.org Subject: Re: [ntpwg] security ID submitted for review X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.14 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 Errors-To: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Sender: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Sorry to butt in on this interesting thread, but why would a user want to verify a pool address when, generally, he does not know which pool server he is going to get, or much about the pool at all? If a user is concerned about security I think the last place he will go is a pool of servers. He will configure known servers and authenticate as previously discussed. In my view, I would exclude pool addresses from this topic. Regards, Tony Flavin Head of Synchronisation Services BT Technology Services & Operations -----Original Message----- From: ntpwg-bounces+anthony.flavin=bt.com@lists.ntp.org [mailto:ntpwg-bounces+anthony.flavin=bt.com@lists.ntp.org] On Behalf Of Kurt Roeckx Sent: 07 August 2013 19:10 To: tsg Cc: ntpwg@lists.ntp.org Subject: Re: [ntpwg] security ID submitted for review On Wed, Aug 07, 2013 at 09:27:32AM -0700, tsg wrote: > On 08/07/2013 08:16 AM, Kurt Roeckx wrote: > >On Sat, Aug 03, 2013 at 07:40:08PM +0200, Kurt Roeckx wrote: > >>I really don't understand how such a man in the middle attack can > >>work. Either the certificate + the chain validate, or they don't. > >>It is of course important to you check that the CommonName in the > >>certificate matches the server you're trying to reach, and that the > >>root CA is in your list of trusted CAs. But there really isn't > >>anything new or hard about this. > >So thinking about this so more, I do see 1 problem with this. I > >would like to be able to use this for the pool for those that wish to > >use it. But if you're verify the certificate you're not going to > >know which server you're talking too, so there is no way to check the > >CommonName. Does it make sense to just skip this check in case of > >the pool? > > Yes. After some thinking, I have to disagree. That check is important to prevent a man in the middle attack. The only think you're going to get then is signed messages, but you have no idea who signed it. So you might as well not sign them since they don't add anything at all. The only way I can see this working without the client doing the CommonName check is that you are able to delegate that check to someone else. In case of the pool system, that would mean that the pool system will needs to know the hostname (it now only has the ip addres I think), check that it matches, and have a secure way to transfer that to the client. That secure way would then probably be DNSSEC, but ntp.org currently doesn't seem to have that set up. I'm not sure it would require the pool system to have names that only resolv to verified servers. But some people might want to make sure that all the servers it's using are verified. Kurt _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg _______________________________________________ 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 Aug 8 00:42:25 2013 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 6C4DF11E81CA for ; Thu, 8 Aug 2013 00:42:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.432 X-Spam-Level: X-Spam-Status: No, score=-5.432 tagged_above=-999 required=5 tests=[AWL=1.167, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id grDQ4S9XobUx for ; Thu, 8 Aug 2013 00:42:20 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by ietfa.amsl.com (Postfix) with ESMTP id 3F35411E80C5 for ; Thu, 8 Aug 2013 00:42:20 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id 29C9D86DAD7 for ; Thu, 8 Aug 2013 07:42:20 +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 365AD86D333 for ; Thu, 8 Aug 2013 07:42:15 +0000 (UTC) Received: from jacques.telenet-ops.be ([195.130.132.50]) by mail1.ntp.org with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1V7KrN-000Naw-D2 for ntpwg@lists.ntp.org; Thu, 08 Aug 2013 07:42:15 +0000 Received: from intrepid.roeckx.be ([94.226.199.45]) by jacques.telenet-ops.be with bizsmtp id A7iA1m00P0zFtyu0J7iAxc; Thu, 08 Aug 2013 09:42:10 +0200 Received: by intrepid.roeckx.be (Postfix, from userid 1000) id 68C17EB122; Thu, 8 Aug 2013 09:42:10 +0200 (CEST) Date: Thu, 8 Aug 2013 09:42:10 +0200 From: Kurt Roeckx To: anthony.flavin@bt.com Message-ID: <20130808074210.GA15952@roeckx.be> References: <51FAC820.3090401@udel.edu> <20130803174008.GA17578@roeckx.be> <20130807151637.GA31292@roeckx.be> <52027574.4060507@earthlink.net> <20130807181005.GA2086@roeckx.be> <2C2CFDF697AA1A44B6013D774F3565D06964ABEF15@EMV63-UKRD.domain1.systemhost.net> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <2C2CFDF697AA1A44B6013D774F3565D06964ABEF15@EMV63-UKRD.domain1.systemhost.net> User-Agent: Mutt/1.5.21 (2010-09-15) X-SA-Exim-Connect-IP: 195.130.132.50 X-SA-Exim-Rcpt-To: ntpwg@lists.ntp.org X-SA-Exim-Mail-From: kurt@roeckx.be X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) Cc: ntpwg@lists.ntp.org Subject: Re: [ntpwg] security ID submitted for review X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.14 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 Errors-To: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Sender: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org On Thu, Aug 08, 2013 at 08:20:09AM +0100, anthony.flavin@bt.com wrote: > Sorry to butt in on this interesting thread, but why would a user want to verify a pool address when, generally, he does not know which pool server he is going to get, or much about the pool at all? If a user is concerned about security I think the last place he will go is a pool of servers. He will configure known servers and authenticate as previously discussed. > > In my view, I would exclude pool addresses from this topic. This is probably going a little off topic for this work group, but: - We don't want people to move away from the pool and directly confgifure ntp servers because they would get overloaded. - I want to provide the best possible solution to my users without them having to configure anything. And I think that includes having everything as secure as possible. Kurt _______________________________________________ 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 Aug 8 00:50:44 2013 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 64ED111E81CD for ; Thu, 8 Aug 2013 00:50:44 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pi+IfL75uTnd for ; Thu, 8 Aug 2013 00:50:39 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [IPv6:2001:4f8:fff7:1::7]) by ietfa.amsl.com (Postfix) with ESMTP id 5077D11E81D5 for ; Thu, 8 Aug 2013 00:50:32 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id D6E3F86DAFA for ; Thu, 8 Aug 2013 07:50:26 +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 8B52386D4E1 for ; Thu, 8 Aug 2013 07:50:21 +0000 (UTC) Received: from front2.mail.megapathdsl.net ([66.80.60.30] helo=mail.megapathdsl.net) by mail1.ntp.org with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1V7KzE-000NfS-OE for ntpwg@lists.ntp.org; Thu, 08 Aug 2013 07:50:21 +0000 Received: from [64.139.1.69] (HELO ip-64-139-1-69.sjc.megapath.net) by fe.mail.megapathdsl.net (CommuniGate Pro SMTP 5.3.13) with ESMTP id 1024121434 for ntpwg@lists.ntp.org; Thu, 08 Aug 2013 00:50:18 -0700 Received: from shuksan (localhost [127.0.0.1]) by ip-64-139-1-69.sjc.megapath.net (Postfix) with ESMTP id C2550406064; Thu, 8 Aug 2013 00:50:15 -0700 (PDT) X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.3 To: anthony.flavin@bt.com From: Hal Murray In-Reply-To: Message from of "Thu, 08 Aug 2013 08:20:09 BST." <2C2CFDF697AA1A44B6013D774F3565D06964ABEF15@EMV63-UKRD.domain1.systemhost.net> Mime-Version: 1.0 Date: Thu, 08 Aug 2013 00:50:15 -0700 Message-Id: <20130808075015.C2550406064@ip-64-139-1-69.sjc.megapath.net> X-SA-Exim-Connect-IP: 66.80.60.30 X-SA-Exim-Rcpt-To: ntpwg@lists.ntp.org X-SA-Exim-Mail-From: hmurray@megapathdsl.net X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) Cc: ntpwg@lists.ntp.org, hmurray@megapathdsl.net Subject: Re: [ntpwg] security ID submitted for review X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.14 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 Errors-To: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Sender: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org anthony.flavin@bt.com said: > In my view, I would exclude pool addresses from this topic. I'd be happy with that answer, but I think we should think about the problem area and carefully document the result. A few paragraphs in the main document might be appropriate, if nothing else to explain why security can't work with something like a pool. Maybe this branch should be split off into another document. Lots of systems are using the pool (or we wouldn't bother having this discussion). The best alternative I can think of would be a BCP requiring ISPs to provide time servers for their customers. Would that put the pool out of business? Maybe. Is that good/bad? Would the pool still be useful as a backup? Does the overall approach work if the client gets its NTP servers via DHCP? -- These are my opinions. I hate spam. _______________________________________________ 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 Aug 8 00:59:33 2013 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 AE5FA11E81D1 for ; Thu, 8 Aug 2013 00:59:33 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Zg9ZFwfQkgl for ; Thu, 8 Aug 2013 00:59: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 BD1F911E81CD for ; Thu, 8 Aug 2013 00:59:28 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id 8CF3786DADB for ; Thu, 8 Aug 2013 07:59:27 +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 C414786D422 for ; Thu, 8 Aug 2013 07:59:20 +0000 (UTC) Received: from server1a.meinberg.de ([176.9.44.212]) by mail1.ntp.org with esmtps (TLSv1:AES256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1V7L7t-000Nj8-Uv for ntpwg@lists.ntp.org; Thu, 08 Aug 2013 07:59:20 +0000 Received: from ubuntu-server-1 (unknown [217.6.112.194]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by server1a.meinberg.de (Postfix) with ESMTPSA id D731871C1465; Thu, 8 Aug 2013 09:59:09 +0200 (CEST) X-DKIM: Sendmail DKIM Filter v2.8.2 server1a.meinberg.de D731871C1465 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=meinberg.de; s=mail201101; t=1375948755; bh=qM3l1hFdsE8yLyQH1v+G5QrBb7u1XThXKbUNmwfvbK4=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=gemXPcULTyDuvpTqxDXlyI45mMjPRwldsRVsqOQEDW5sUjPlT8dLzk3fvsD03ft99 lpQkDYv8hJtcDlvuj4N+r4V0Vmz5sePNVZ7D8CsBeW5FfMWeyQ9Diukq6wU66YCgjX ugnlnuNCcs0GsIyQfKurOJ5Bikw6eLX0XkdtzD9k= Received: from localhost (localhost [127.0.0.1]) by ubuntu-server-1 (Postfix) with ESMTP id 97F0E4814E; Thu, 8 Aug 2013 09:59:09 +0200 (CEST) Received: from ubuntu-server-1 ([127.0.0.1]) by localhost (ubuntu-server-1.py.meinberg.de [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 2641AS8uy2Yf; Thu, 8 Aug 2013 09:59:08 +0200 (CEST) Received: from [172.16.100.73] (pc-martin.py.meinberg.de [172.16.100.73]) by ubuntu-server-1 (Postfix) with ESMTP id B0F014810C; Thu, 8 Aug 2013 09:59:08 +0200 (CEST) Message-ID: <52034FCC.3000806@meinberg.de> Date: Thu, 08 Aug 2013 09:59:08 +0200 From: Martin Burnicki Organization: Meinberg Funkuhren, Bad Pyrmont, Germany User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:20.0) Gecko/20100101 Firefox/20.0 SeaMonkey/2.17 MIME-Version: 1.0 To: anthony.flavin@bt.com, kurt@roeckx.be, tglassey@earthlink.net References: <51FAC820.3090401@udel.edu> <20130803174008.GA17578@roeckx.be> <20130807151637.GA31292@roeckx.be> <52027574.4060507@earthlink.net> <20130807181005.GA2086@roeckx.be> <2C2CFDF697AA1A44B6013D774F3565D06964ABEF15@EMV63-UKRD.domain1.systemhost.net> In-Reply-To: <2C2CFDF697AA1A44B6013D774F3565D06964ABEF15@EMV63-UKRD.domain1.systemhost.net> X-Virus-Scanned: clamav-milter 0.97.8 at server1a X-Virus-Status: Clean X-SA-Exim-Connect-IP: 176.9.44.212 X-SA-Exim-Rcpt-To: ntpwg@lists.ntp.org X-SA-Exim-Mail-From: martin.burnicki@meinberg.de X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) Cc: ntpwg@lists.ntp.org Subject: Re: [ntpwg] security ID submitted for review X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: IETF Working Group for Network Time Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Sender: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org anthony.flavin@bt.com wrote: > Sorry to butt in on this interesting thread, I'm sure there's no need to be sorry. ;-) I find it very important to discuss this topic from all points of view, before a standard is released and a new autokey version is implemented. Unfortunately I'm not familiar enough with crypto implementations and possible risks to be able to contribute to the main discussion aout the details of a possible implementation. > but why would a user > want to verify a pool address when, generally, he does not know which > pool server he is going to get, or much about the pool at all? If a > user is concerned about security I think the last place he will go is > a pool of servers. He will configure known servers and authenticate > as previously discussed. I think this depends. If you have one or a few own servers and those servers are compromised the you're lost. If you use a number of pool server (maybe even with "noselect") in addition to your own servers then you can at least make some plausibility check, e.g. check the "ntpq -p" billboard to to see if the pool servers and your own servers disagree on the current time, so probably something goes wrong. Of course there's still a risk that DNS is spoofed and your "pool" lookups are resolved to point to an attacker's NTP server(s). So I could imagine that you manually pick up some pool servers and use their IP addresses in the NTP config file. In this case it would IMO make sense to have some authentication with the pool servers to make sure the packets to the pool servers' IP addresses are not re-routed to an attacker's NTP server, in which case the plausibility check mentioned above would fail. Regards, Martin -- Martin Burnicki Meinberg Funkuhren Bad Pyrmont Germany _______________________________________________ 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 Aug 8 01:46:13 2013 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 7FF1021F964C for ; Thu, 8 Aug 2013 01:46:13 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QASaHCghR3OR for ; Thu, 8 Aug 2013 01:46:08 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by ietfa.amsl.com (Postfix) with ESMTP id DA12321F8CDD for ; Thu, 8 Aug 2013 01:46:06 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id A98EA86D756 for ; Thu, 8 Aug 2013 08:46: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 0BDF786D422 for ; Thu, 8 Aug 2013 08:45:49 +0000 (UTC) Received: from front3.mail.megapathdsl.net ([66.80.60.32] helo=mail.megapathdsl.net) by mail1.ntp.org with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1V7Lqu-000O0w-Bt for ntpwg@lists.ntp.org; Thu, 08 Aug 2013 08:45:49 +0000 Received: from [64.139.1.69] (HELO ip-64-139-1-69.sjc.megapath.net) by fe.mail.megapathdsl.net (CommuniGate Pro SMTP 5.3.13) with ESMTP id 986538981 for ntpwg@lists.ntp.org; Thu, 08 Aug 2013 01:45:46 -0700 Received: from shuksan (localhost [127.0.0.1]) by ip-64-139-1-69.sjc.megapath.net (Postfix) with ESMTP id 2923E406063; Thu, 8 Aug 2013 01:45:40 -0700 (PDT) X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.3 To: Martin Burnicki From: Hal Murray In-Reply-To: Message from Martin Burnicki of "Thu, 08 Aug 2013 09:59:08 +0200." <52034FCC.3000806@meinberg.de> Mime-Version: 1.0 Date: Thu, 08 Aug 2013 01:45:40 -0700 Message-Id: <20130808084540.2923E406063@ip-64-139-1-69.sjc.megapath.net> X-SA-Exim-Connect-IP: 66.80.60.32 X-SA-Exim-Rcpt-To: ntpwg@lists.ntp.org X-SA-Exim-Mail-From: hmurray@megapathdsl.net X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) Cc: ntpwg@lists.ntp.org, hmurray@megapathdsl.net Subject: Re: [ntpwg] security ID submitted for review X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.14 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 Errors-To: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Sender: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org martin.burnicki@meinberg.de said: > Unfortunately I'm not familiar enough with crypto implementations and > possible risks to be able to contribute to the main discussion aout the > details of a possible implementation. One important consideration is that crypto protocols often assume that the time is known. Does anybody have a good URL that summarizes doing crypto with vs without knowing the time? -- These are my opinions. I hate spam. _______________________________________________ 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 Aug 13 08:10:40 2013 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 2255921F8DDD for ; Tue, 13 Aug 2013 08:10:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.298 X-Spam-Level: X-Spam-Status: No, score=-5.298 tagged_above=-999 required=5 tests=[AWL=1.299, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F8Lv14wQ7qhx for ; Tue, 13 Aug 2013 08:10:36 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by ietfa.amsl.com (Postfix) with ESMTP id 0B01411E80AD for ; Tue, 13 Aug 2013 08:10:33 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id D845586D77F for ; Tue, 13 Aug 2013 15:10:32 +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 6693786D4F1 for ; Tue, 13 Aug 2013 15:10:15 +0000 (UTC) Received: from louie.udel.edu ([128.4.40.12] helo=mail.eecis.udel.edu) by mail1.ntp.org with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1V9GEZ-000FKW-V2 for ntpwg@lists.ntp.org; Tue, 13 Aug 2013 15:10:15 +0000 Received: from [192.168.1.2] (pool-74-109-13-78.phlapa.fios.verizon.net [74.109.13.78]) (Authenticated sender: mills@mail.eecis.udel.edu) by mail.eecis.udel.edu (Postfix) with ESMTP id 5186B1BDA; Tue, 13 Aug 2013 11:10:06 -0400 (EDT) Message-ID: <520A4C4F.2050400@udel.edu> Date: Tue, 13 Aug 2013 15:10:07 +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: dieter.sibold@ptb.de References: <51FAC820.3090401@udel.edu> <20130803174008.GA17578@roeckx.be> 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: NTP Working Group , "tictoc@ietf.org" Subject: Re: [ntpwg] security ID submitted for review X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.14 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="===============7501984531606304053==" Errors-To: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Sender: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org This is a multi-part message in MIME format. --===============7501984531606304053== Content-Type: multipart/alternative; boundary="------------080405070303000203070401" This is a multi-part message in MIME format. --------------080405070303000203070401 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit dieter.sibold@ptb.de wrote: > Dieter, There are several minor points I might mention. First the easy ones. You mentioned TESLA , which sound very much like the existing Autokey in broadcast mode. Actually, the Autokey scheme was stolen from S-KEY of many years ago. I still think this should all be replaced by a signature using the server public key. This is complicated in the case of multiple broadcast servers implemented in the same system. In these cases, the network delay calibration might be different, as is the case in the current NTP implementation. In order to support this requirement, the extension field for the broadcast message needs to include the process ID for the broadcast association. The process ID is used for the particular security protocol in the delay calculation. Other means might be devised in the new protocol to perform this function. For client/server and symmetric modes, I suggest the following design candidate. This would be appropriate for national time servers operated by NIST , USNO and NRC. A certain number of these servers currently support symmetric key verification, where each key is chosen for each subscriber upon payment of a fee. For instance, NIST has over 25 million clients of their public servers, and where probably several million use the bolder complex with no cryptographic support. One machine includes support for symmetric key cryptography, so probably several hundred different keys could be supported. Symmetric key cryptography becomes unwieldy when the number of customer clients much exceeds this number. An alternative design using public key cryptography might be more appropriate. This design would use Diffy-Hellman key agreement. The client would send the public value to the server signed by the client public key. The server would respond with its public value signed by the server public key. The agreed key for both the client and server would be split in two portions, the 32-bit key identifier and a 160-bit symmetric key. Both the client and the server would save the values in the same data structure used for static symmetric keys. Subsequently, operation would continue as in ordinary static symmetric keys. The devil is in the details. The server needs a table with entries corresponding to the client IP address and certificate. This is what the subscriber pays for. Additional provisions are necessary to time out old keys and regenerate accordingly. This scheme avoids the use of extension fields in all cases except when a new agreement is negotiated. A question remains on whether the sgreement messages are to be authenticated by other than the agreed key itself. My suggestion is simply to avoid this step on condition that the NTP header time values are ignored. My experience over 17 years operating experiment configurations on up to 17 different machines running various combinations of unsecured symmetric and public key combinations suggests that the supporting infrastructure is of serious concern. For one thing, certificate lifetimes are meaningless until the correct time has been verified. There is no a-priori assumption about the certificate lifetimes other than a continuous trail, possibly spanning several intermediate servers, Consider the effect of replacing a public/private key when a server fails and is replaced. Consider what happens when an intermediate server rolls a new certificate which interupts the trail continuity. Remember, a typical NTP client runs multiple servers, each of which might have a different trail to the same server or servers. A large crop of obscure interworking issues have been found and corrented over the years. I suspect similar issues and corrections will be found in PTP applications. The particular set of rules and constraints described in previous reports and RFC 5906 were constructed with great care. They established the security model and partial-order precidents relations considered at a meeting of computer science theorists and myself at the Dagstuhl (Germany) meeting in 1996. The rules require that all security changes conform to Lamport's "happens before" relation. The filestamps and timestamps described in RFC 5906 conform to these rules. Unfortunately, to my knowledge, current applications do not necessarily conform to these rules. It may be a lost cause to incorporate these rules in new NTP or PTP protocols and applications. I hope these comments are useful in the evolution of NTP and PTP security protocols. Dave > Hello Dave and Kurt, > > thanks for your comments: > > As Kurt already pointed out. Currently the ID specifies only the > design of the security protocol. We believe that we need to be clear > about the design questions before specifying the technical details. > > The private key of the client is not needed for the MAC. Instead the > calculation of the MAC includes the cookie and the whole NTP packet > (i.e. the extension fields also). The cookie is calculated from the > server seed and the client's public key, which the client attaches to > each time request (which requires a new extension field as pointed out > in the draft). During cookie exchange the server encrypts the cookie > with the client's public key before transmission. An adversary is > therefore not able to abuse a cookie which he requests in behalf of > the client. > > As Kurt pointed out the certificate exchange works as in a standard > PKI. I emphasize that this is different to autokey. In autokey the > chain of trust and time are equal whereas in this ID chain of trust > and time might be disjunct. > > Regarding the broadcast mode. I agree with Dave that the use of TESLA > for the broadcast mode adds additional complexity. It also has the > disadvantage that the authenticity of a packet can only be verified in > retrospect. But I don't see security vulnerabilities. Dave's > suggestion to use a combination of interleave mode with asymmetric > cryptography is interesting. We should consider this. The argument > that asymmetric cryptography might be feasible because of modern power > of CPUs is okay for traditional computer systems but I'm not sure > whether this assumption also applies for small devices with > constrained resources. > > Regards > Dieter > > > ---------------------------------- > Physikalisch-Technische Bundesanstalt > Dr. Dieter Sibold > Q.42 - Serversysteme und Datenhaltung > QM-Verantwortlicher der Stelle IT-Infrastruktur > Bundesallee 100 > D-38116 Braunschweig > Tel: +49-531-592-84 20 > E-Mail: dieter.sibold@ptb.de > > > > Von: Kurt Roeckx > An: "David L. Mills" > Kopie: NTP Working Group , > "tictoc@ietf.org" > Datum: 03.08.2013 20:04 > Betreff: Re: [ntpwg] security ID submitted for review > Gesendet von: ntpwg-bounces+dieter.sibold=ptb.de@lists.ntp.org > ------------------------------------------------------------------------ > > > > On Thu, Aug 01, 2013 at 08:42:08PM +0000, David L. Mills wrote: > > Guys, > > > > Here are some general comments on the ID. I apologize if they are a > > little rough as I have to dictate this message instead of my usual > > polished wordsmithing. > > > > format. > > The ID does not specify an extension field format. > > The draft only seems to specify the the general idea of how it > should work and doesn't seem to go into detail how this should > work at the protocol level. I assume he first wants to know if > the solution is something that can work and that others see > as a good solution before he works out the details. > > > In particular, the private key for the message > > authentication code (MAC) , if used, must be known beforehand. This > > is where the "cookie snatcher" issue comes up as described in > > previous messages. In particular, an important constraint for > > normal operation is that extension fields are not used unless > > required for cookie determination. > > I'm not sure I understand your remark. As far as I know the > "cookie snatcher" you talk about is the normal "man in the middle" > attack. As I understand we would change the verification by > replacing it by the normal X.509 verification as done for instance > SSL/TLS. > > I assume you meant public key and note private key. > > > Glaring vulnerability exists when using extension fields, as the key > > value is public and must be known in advance. This invites a > > cut-and-paste attack, as well as header changes, even if > > subsequently detected by the on-wire protocol. > > I've seen this cut-and-paste attack mentioned before, but I've > never really understood it. As I understand things, the MAC > is generated over the NTP + extensions. I don't see how you > can take the extension from 1 packet into an other and still > have a valid MAC. Or are you saying that you do something > with a packet even when it doesn't have a valid MAC? > > > certificate. > > Both RFC 5906 and the ID require the server certificate. The server > > certificate can be conveyed, either off-line, or directly or > > indirectly via a certificate trail as described in RFC 5906 or the > > ID. If obtained via the trail, there is a hazzard due to a > > middle-man attack and masquerade. > > I really don't understand how such a man in the middle attack > can work. Either the certificate + the chain validate, or they > don't. It is of course important to you check that the CommonName > in the certificate matches the server you're trying to reach, > and that the root CA is in your list of trusted CAs. But there > really isn't anything new or hard about this. > > > In broadcast mode, the protocols described in RFC 5906 and the ID > > are messy and with several possible vulnerabilities. Here is a > > suggestion that might be useful. Define a new broadcast packet > > format as the NTP header followed by one extension field > > representing the MAC. The extension field represents the signature > > of the header computed using the private key of the server and can > > be verified by the client using the public key in the server > > certificate. Originally, this was considered an unacceptable > > dilution of accuracy due to the variability of the signature > > computing time and the length of the signature. However, at least > > in modern NTP, the interleaved broadcast mode can be used to correct > > for this overhead. This assumes that the overhead for either the > > server or client is reduced using fast modern processors. > > I think that in all cases where it's no problem to keep track of > all clients you should use the interleaved mode, and we can use > something like the Diffie-Hellman key agreement for those. > > But there clearly is also a need for servers that can't keep > the state of each client, and we need something else for that. > So maybe we need to define 2 ways of working. > > > > Kurt > > _______________________________________________ > ntpwg mailing list > ntpwg@lists.ntp.org > http://lists.ntp.org/listinfo/ntpwg > --------------080405070303000203070401 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit dieter.sibold@ptb.de wrote:
Dieter,
There are several minor points I might mention.  First the easy ones.  You mentioned TESLA , which sound very much like the existing Autokey in broadcast mode.  Actually, the Autokey scheme was stolen from S-KEY of many years ago.   I still think this should all be replaced by a signature using the server public key. This is complicated in the case of multiple broadcast servers implemented in the same system.  In these cases,  the network delay calibration might be different, as is the case in the current NTP implementation. In order to support this requirement, the extension field for the broadcast message needs to include the process ID for the broadcast association.  The process ID is used for the particular security protocol in the delay calculation.  Other means might be devised in the new protocol to perform this function.

For client/server and symmetric modes, I suggest the following design candidate.  This would be appropriate for national time servers operated by NIST , USNO and NRC.  A certain number of these servers currently support symmetric key verification, where each key is chosen for each subscriber upon payment of a fee.  For instance, NIST has over 25 million clients of their public servers, and where probably several million use the bolder complex with no cryptographic support.  One machine includes support for symmetric key cryptography, so probably several hundred different keys could be supported. 

Symmetric key cryptography becomes unwieldy when the number of customer clients much exceeds this number.  An alternative design using public key cryptography might be more appropriate.  This design would use Diffy-Hellman key agreement.  The client would send the public value to the server signed by the client public key.  The server would respond with its public value signed by the server public key.  The agreed key for both the client and server would be split in two portions, the 32-bit key identifier and a 160-bit symmetric key.  Both the client and the server would save the values in the same data structure used for static symmetric keys.  Subsequently, operation would continue as in ordinary static symmetric keys. 

The devil is in the details.  The server needs a table with entries corresponding to the client IP address and certificate. This is what the subscriber pays for.  Additional provisions are necessary to time out old keys and regenerate accordingly. 

This scheme avoids the use of extension fields in all cases except when a new agreement is negotiated.  A question remains on whether the sgreement messages are to be authenticated by other than the agreed key itself.  My suggestion is simply to avoid this step on condition that the NTP header time values are ignored. 

My experience over 17 years operating experiment configurations on up to 17 different machines running various combinations of unsecured symmetric and public key combinations suggests that the supporting infrastructure is of serious concern.  For one thing, certificate lifetimes are meaningless until the correct time has been verified.  There is no a-priori assumption about the certificate lifetimes other than a continuous trail, possibly spanning several intermediate servers,   Consider the effect of replacing a public/private key when a server fails and is replaced.  Consider what happens when an intermediate server rolls a new certificate which interupts  the trail continuity.  Remember, a typical NTP client runs multiple servers, each of which might have a different trail to the same server or servers.  A large crop of obscure interworking issues have been found and corrented over the years.  I suspect similar issues and corrections will be found in PTP applications.

The particular set of rules and constraints described in previous reports and RFC 5906 were constructed with great care.  They established the security model and partial-order precidents relations considered at a meeting of computer science theorists and myself at the Dagstuhl (Germany) meeting in 1996.   The rules require that all security changes conform to Lamport's "happens before" relation.  The filestamps and timestamps described in RFC 5906 conform to these rules.  Unfortunately, to my knowledge, current applications do not necessarily conform to these rules.  It may be a lost cause to incorporate these rules in new NTP or PTP protocols and applications.

I hope these comments are useful in the evolution of NTP and PTP security protocols.

Dave


Hello Dave and Kurt,

thanks for your comments:

As Kurt already pointed out. Currently the ID specifies only the design of the security protocol. We believe that we need to be clear about the design questions before specifying the technical details.

The private key of the client is not needed for the MAC. Instead the calculation of the MAC includes the cookie and the whole NTP packet (i.e. the extension fields also). The cookie is calculated from the server seed and the client's public key, which the client attaches to each time request (which requires a new extension field as pointed out in the draft). During cookie exchange the server encrypts the cookie with the client's public key before transmission. An adversary is therefore not able to abuse a cookie which he requests in behalf of the client.

As Kurt pointed out the certificate exchange works as in a standard PKI. I emphasize that this is different to autokey. In autokey the chain of trust and time are equal whereas in this ID chain of trust and time might be disjunct.

Regarding the broadcast mode. I agree with Dave that the use of TESLA for the broadcast mode adds additional complexity.  It also has the disadvantage that the authenticity of a packet can only be verified in retrospect. But I don't see security vulnerabilities. Dave's suggestion to use a combination of interleave mode with asymmetric cryptography is interesting. We should consider this. The argument that asymmetric cryptography might be feasible because of modern power of CPUs is okay for traditional computer systems but I'm not sure whether this assumption also applies for small devices with constrained resources.

Regards
Dieter


----------------------------------
Physikalisch-Technische Bundesanstalt
Dr. Dieter Sibold
Q.42 - Serversysteme und Datenhaltung
QM-Verantwortlicher der Stelle IT-Infrastruktur
Bundesallee 100
D-38116 Braunschweig
Tel: +49-531-592-84 20
E-Mail: dieter.sibold@ptb.de



Von:        Kurt Roeckx <kurt@roeckx.be>
An:        "David L. Mills" <mills@udel.edu>
Kopie:        NTP Working Group <ntpwg@lists.ntp.org>, "tictoc@ietf.org" <tictoc@ietf.org>
Datum:        03.08.2013 20:04
Betreff:        Re: [ntpwg] security ID submitted for review
Gesendet von:        ntpwg-bounces+dieter.sibold=ptb.de@lists.ntp.org



On Thu, Aug 01, 2013 at 08:42:08PM +0000, David L. Mills wrote:
> Guys,
>
> Here are some general comments on the ID.  I apologize if they are a
> little rough as I have to dictate this message instead of my usual
> polished wordsmithing.
>
> format.
> The ID does not specify an extension field format.

The draft only seems to specify the the general idea of how it
should work and doesn't seem to go into detail how this should
work at the protocol level.  I assume he first wants to know if
the solution is something that can work and that others see
as a good solution before he works out the details.

> In particular, the private key for the message
> authentication code (MAC) , if used, must be known beforehand.  This
> is where the "cookie snatcher" issue comes up as described in
> previous messages.  In particular, an important constraint for
> normal operation is that extension fields are not used unless
> required for cookie determination.

I'm not sure I understand your remark.  As far as I know the
"cookie snatcher" you talk about is the normal "man in the middle"
attack.  As I understand we would change the verification by
replacing it by the normal X.509 verification as done for instance
SSL/TLS.

I assume you meant public key and note private key.

> Glaring vulnerability exists when using extension fields, as the key
> value is public and must be known in advance.  This invites a
> cut-and-paste attack, as well as header changes, even if
> subsequently detected by the on-wire protocol.

I've seen this cut-and-paste attack mentioned before, but I've
never really understood it.  As I understand things, the MAC
is generated over the NTP + extensions.  I don't see how you
can take the extension from 1 packet into an other and still
have a valid MAC.  Or are you saying that you do something
with a packet even when it doesn't have a valid MAC?

> certificate.
> Both RFC 5906 and the ID require the server certificate.  The server
> certificate can be conveyed, either off-line, or directly or
> indirectly via a certificate trail as described in RFC 5906 or the
> ID.  If obtained via the trail, there is a hazzard due to a
> middle-man attack and masquerade.

I really don't understand how such a man in the middle attack
can work.  Either the certificate + the chain validate, or they
don't.  It is of course important to you check that the CommonName
in the certificate matches the server you're trying to reach,
and that the root CA is in your list of trusted CAs.  But there
really isn't anything new or hard about this.

> In broadcast mode, the protocols described in RFC 5906 and the ID
> are messy and with several possible vulnerabilities.  Here is a
> suggestion that might be useful.  Define a new broadcast packet
> format as the NTP header followed by one extension field
> representing the MAC.  The extension field represents the signature
> of the header computed using the private key of the server and can
> be verified by the client using the public key in the server
> certificate.  Originally, this was considered an unacceptable
> dilution of accuracy due to the variability of the signature
> computing time and the length of the signature.  However, at least
> in modern NTP, the interleaved broadcast mode can be used to correct
> for this overhead.  This assumes that the overhead for either the
> server or client is reduced using fast modern processors.

I think that in all cases where it's no problem to keep track of
all clients you should use the interleaved mode, and we can use
something like the Diffie-Hellman key agreement for those.

But there clearly is also a need for servers that can't keep
the state of each client, and we need something else for that.
So maybe we need to define 2 ways of working.



Kurt

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

--------------080405070303000203070401-- --===============7501984531606304053== 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 --===============7501984531606304053==-- From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Wed Aug 14 00:35:20 2013 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 3D7FC11E8135 for ; Wed, 14 Aug 2013 00:35:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4YHexYOn1Hnj for ; Wed, 14 Aug 2013 00:35:14 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [IPv6:2001:4f8:fff7:1::7]) by ietfa.amsl.com (Postfix) with ESMTP id CF41C11E80D5 for ; Wed, 14 Aug 2013 00:35:14 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id 0434286DAB3 for ; Wed, 14 Aug 2013 07:35:13 +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 9981286D333 for ; Wed, 14 Aug 2013 07:35:04 +0000 (UTC) Received: from mx1.bs.ptb.de ([192.53.103.106]) by mail1.ntp.org with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1V9Vbh-000KS8-39 for ntpwg@lists.ntp.org; Wed, 14 Aug 2013 07:35:04 +0000 Received: from mx1.bs.ptb.de (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id E66F2CE2DDA; Wed, 14 Aug 2013 09:34:52 +0200 (CEST) Received: from rose.bs.ptb.de (rose.bs.ptb.de [141.25.85.201]) by mx1.bs.ptb.de (Postfix) with ESMTP id CBCF4CBDC00; Wed, 14 Aug 2013 09:34:52 +0200 (CEST) In-Reply-To: <52034FCC.3000806@meinberg.de> References: <51FAC820.3090401@udel.edu> <20130803174008.GA17578@roeckx.be> <20130807151637.GA31292@roeckx.be> <52027574.4060507@earthlink.net> <20130807181005.GA2086@roeckx.be> <2C2CFDF697AA1A44B6013D774F3565D06964ABEF15@EMV63-UKRD.domain1.systemhost.net> <52034FCC.3000806@meinberg.de> To: ntpwg@lists.ntp.org MIME-Version: 1.0 X-KeepSent: CB230F71:E30AA145-C1257BC2:00533EFE; type=4; name=$KeepSent X-Mailer: IBM Notes Release 9.0 March 08, 2013 Message-ID: From: dieter.sibold@ptb.de Date: Wed, 14 Aug 2013 09:34:48 +0200 X-MIMETrack: S/MIME Sign by Notes Client on Dieter Sibold/PTB(Release 9.0|March 08, 2013) at 14.08.2013 09:34:48, Serialize by Notes Client on Dieter Sibold/PTB(Release 9.0|March 08, 2013) at 14.08.2013 09:34:48, Serialize complete at 14.08.2013 09:34:48, Itemize by Notes Client on Dieter Sibold/PTB(Release 9.0|March 08, 2013) at 14.08.2013 09:34:50, S/MIME Sign complete at 14.08.2013 09:34:50, Serialize by Router on ROSE/PTB(Release 8.5.3FP3HF370 | April 24, 2013) at 08/14/2013 09:34:52, Serialize complete at 08/14/2013 09:34:52 X-SA-Exim-Connect-IP: 192.53.103.106 X-SA-Exim-Rcpt-To: ntpwg@lists.ntp.org X-SA-Exim-Mail-From: dieter.sibold@ptb.de X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) Subject: Re: [ntpwg] security ID submitted for review X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.14 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="===============1659868427026973667==" Errors-To: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Sender: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org This is an S/MIME signed message. --===============1659868427026973667== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary=-------z64412_boundary_sign This is an S/MIME signed message. ---------z64412_boundary_sign Content-Type: multipart/alternative; boundary="=_alternative 0029A391C1257BC7_=" Dies ist eine mehrteilige Nachricht im MIME-Format. --=_alternative 0029A391C1257BC7_= Content-Type: text/plain; charset="US-ASCII" Thanks for your comments and this discussion. Actually, we didn't consider the usage of a NTP pool during drafting of the ID. But as Hal and Martin suggested, this use case also has to be considered in the draft. So we shall add a section for it. I also agree with Anthony in that I do not believe that a pool would be considered seriously in cases in which verification of authenticity is required. There might be cases in which an authenticated pools would be useful. My assumption is that the support of such pools would add significant complexity to the protocol. So I doubt that this effort would be worthwhile. Still, I would like to see this topic some more discussion about this topic. I don't know the prerequisite which potential contributors to a pool have to met. But obviously for a "authenticated pool" they would have to be quit high in order to avoid that it is compromised. Dieter ---------------------------------- Physikalisch-Technische Bundesanstalt Dr. Dieter Sibold Q.42 - Serversysteme und Datenhaltung QM-Verantwortlicher der Stelle IT-Infrastruktur Bundesallee 100 D-38116 Braunschweig Tel: +49-531-592-84 20 E-Mail: dieter.sibold@ptb.de Von: Martin Burnicki An: anthony.flavin@bt.com, kurt@roeckx.be, tglassey@earthlink.net Kopie: ntpwg@lists.ntp.org Datum: 08.08.2013 09:59 Betreff: Re: [ntpwg] security ID submitted for review Gesendet von: ntpwg-bounces+dieter.sibold=ptb.de@lists.ntp.org anthony.flavin@bt.com wrote: > Sorry to butt in on this interesting thread, I'm sure there's no need to be sorry. ;-) I find it very important to discuss this topic from all points of view, before a standard is released and a new autokey version is implemented. Unfortunately I'm not familiar enough with crypto implementations and possible risks to be able to contribute to the main discussion aout the details of a possible implementation. > but why would a user > want to verify a pool address when, generally, he does not know which > pool server he is going to get, or much about the pool at all? If a > user is concerned about security I think the last place he will go is > a pool of servers. He will configure known servers and authenticate > as previously discussed. I think this depends. If you have one or a few own servers and those servers are compromised the you're lost. If you use a number of pool server (maybe even with "noselect") in addition to your own servers then you can at least make some plausibility check, e.g. check the "ntpq -p" billboard to to see if the pool servers and your own servers disagree on the current time, so probably something goes wrong. Of course there's still a risk that DNS is spoofed and your "pool" lookups are resolved to point to an attacker's NTP server(s). So I could imagine that you manually pick up some pool servers and use their IP addresses in the NTP config file. In this case it would IMO make sense to have some authentication with the pool servers to make sure the packets to the pool servers' IP addresses are not re-routed to an attacker's NTP server, in which case the plausibility check mentioned above would fail. Regards, Martin -- Martin Burnicki Meinberg Funkuhren Bad Pyrmont Germany _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg --=_alternative 0029A391C1257BC7_= Content-Type: text/html; charset="US-ASCII" Thanks for your comments and this discussion.

Actually, we didn't consider the usage of a NTP pool during drafting of the ID. But as Hal and Martin suggested,  this use case also has to be considered in the draft. So we shall add a section for it. I also agree with Anthony in that I do not believe that a pool would be considered seriously in cases in which verification of authenticity is required. There might be cases in which an authenticated pools would be useful. My assumption is that the support of such pools would add significant complexity to the protocol. So I doubt that this effort would be worthwhile. Still, I would like to see this topic some more discussion about this topic.

I don't know the prerequisite which potential contributors to a pool have to met. But obviously for a "authenticated pool" they would have to be quit high in order to avoid that it is compromised.

Dieter




----------------------------------
Physikalisch-Technische Bundesanstalt
Dr. Dieter Sibold
Q.42 - Serversysteme und Datenhaltung
QM-Verantwortlicher der Stelle IT-Infrastruktur
Bundesallee 100
D-38116 Braunschweig
Tel: +49-531-592-84 20
E-Mail: dieter.sibold@ptb.de



Von:        Martin Burnicki <martin.burnicki@meinberg.de>
An:        anthony.flavin@bt.com, kurt@roeckx.be, tglassey@earthlink.net
Kopie:        ntpwg@lists.ntp.org
Datum:        08.08.2013 09:59
Betreff:        Re: [ntpwg] security ID submitted for review
Gesendet von:        ntpwg-bounces+dieter.sibold=ptb.de@lists.ntp.org



anthony.flavin@bt.com wrote:
> Sorry to butt in on this interesting thread,

I'm sure there's no need to be sorry. ;-)

I find it very important to discuss this topic from all points of view,
before a standard is released and a new autokey version is implemented.

Unfortunately I'm not familiar enough with crypto implementations and
possible risks to be able to contribute to the main discussion aout the
details of a possible implementation.

> but why would a user
> want to verify a pool address when, generally, he does not know which
> pool server he is going to get, or much about the pool at all?  If a
> user is concerned about security I think the last place he will go is
> a pool of servers. He will configure known servers and authenticate
> as previously discussed.

I think this depends. If you have one or a few own servers and those
servers are compromised the you're lost.

If you use a number of pool server (maybe even with "noselect") in
addition to your own servers then you can at least make some
plausibility check, e.g. check the "ntpq -p" billboard to to see if the
pool servers and your own servers disagree on the current time, so
probably something goes wrong.

Of course there's still a risk that DNS is spoofed and your "pool"
lookups are resolved to point to an attacker's NTP server(s).

So I could imagine that you manually pick up some pool servers and use
their IP addresses in the NTP config file.

In this case it would IMO make sense to have some authentication with
the pool servers to make sure the packets to the pool servers' IP
addresses are not re-routed to an attacker's NTP server, in which case
the plausibility check mentioned above would fail.


Regards,

Martin
--
Martin Burnicki

Meinberg Funkuhren
Bad Pyrmont
Germany
_______________________________________________
ntpwg mailing list
ntpwg@lists.ntp.org
http://lists.ntp.org/listinfo/ntpwg
--=_alternative 0029A391C1257BC7_=-- ---------z64412_boundary_sign Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIImgAIBATELMAkGBSsOAwIaBQAwCwYJKoZIhvcNAQcBoIIjkjCCA58w ggKHoAMCAQICASYwDQYJKoZIhvcNAQEFBQAwcTELMAkGA1UEBhMCREUxHDAaBgNVBAoTE0RldXRz Y2hlIFRlbGVrb20gQUcxHzAdBgNVBAsTFlQtVGVsZVNlYyBUcnVzdCBDZW50ZXIxIzAhBgNVBAMT GkRldXRzY2hlIFRlbGVrb20gUm9vdCBDQSAyMB4XDTk5MDcwOTEyMTEwMFoXDTE5MDcwOTIzNTkw MFowcTELMAkGA1UEBhMCREUxHDAaBgNVBAoTE0RldXRzY2hlIFRlbGVrb20gQUcxHzAdBgNVBAsT FlQtVGVsZVNlYyBUcnVzdCBDZW50ZXIxIzAhBgNVBAMTGkRldXRzY2hlIFRlbGVrb20gUm9vdCBD QSAyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAqwujNeCLKRSxFIWvPBDkOW81XUqu 3ephjZVJ9G9koxpgZqSpQCKE2dSl5XiTDmgBrblNXDrO07ioQkDfz6O6gllqkhusHJraCCslJ/lp I0fx4Ossepv1EwLQfjR8wp48AFmr9doM9TI8K6xQ2tbD3oOUyqgMmTIOCEhWW2r72uFYWAFJX3JB PBUGAY5draq4k7TNnuun6GotUjTbOu9cdVHa2/Mx+e5xmDLEVBVEDPmbVe2t3xgIoKOGiknuUwWP GUzV3lh5m9JqHEKrxdWnz2gPluThYZh2YciRfNY+AOKRUIfhnQrmrZfSHcY6fcu82gM01Y5bAfVq B7cWtm5KfwIDAQABo0IwQDAdBgNVHQ4EFgQUMcN5G7r1U9cX4Il6LRdsCrMrnTMwDwYDVR0TBAgw BgEB/wIBBTAOBgNVHQ8BAf8EBAMCAQYwDQYJKoZIhvcNAQEFBQADggEBAJRkWa05ZOcp6xP+WsOL E1fIBCTwdHfAYONn++mJpoO/loJ8btTDPe+egG67KbSYerE7VOs5F0d+Go4L/B8xWTEEss4X8yzH YjZV4iLYiVW0mEiqZPrWHDbYRHhaWiM6V5f1ejBPrp9qTEsrjqAD4z7gqdTSe9KzqOJyPK2e/4BZ 5JtFtPY7sM05GZgy5eohYZDkMSGONLH3LzVKhRDa54o3Ib5ZY+DyhYgxU9RUFIVwefQuBncndS8f uIr5/sW62Dbkg+znZbe/Y1rzRq+BlDfUQYzWI9Yez/VoG0Rjolq6pzVZoeVwBZsOI1eZlAptujlj KIaS8xiE2PvRzwVWZFcwggOfMIICh6ADAgECAgEmMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYT AkRFMRwwGgYDVQQKExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1 c3QgQ2VudGVyMSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw05OTA3MDkx MjExMDBaFw0xOTA3MDkyMzU5MDBaMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNEZXV0c2NoZSBU ZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVyMSMwIQYDVQQDExpEZXV0 c2NoZSBUZWxla29tIFJvb3QgQ0EgMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKsL ozXgiykUsRSFrzwQ5DlvNV1Krt3qYY2VSfRvZKMaYGakqUAihNnUpeV4kw5oAa25TVw6ztO4qEJA 38+juoJZapIbrBya2ggrJSf5aSNH8eDrLHqb9RMC0H40fMKePABZq/XaDPUyPCusUNrWw96DlMqo DJkyDghIVltq+9rhWFgBSV9yQTwVBgGOXa2quJO0zZ7rp+hqLVI02zrvXHVR2tvzMfnucZgyxFQV RAz5m1Xtrd8YCKCjhopJ7lMFjxlM1d5YeZvSahxCq8XVp89oD5bk4WGYdmHIkXzWPgDikVCH4Z0K 5q2X0h3GOn3LvNoDNNWOWwH1age3FrZuSn8CAwEAAaNCMEAwHQYDVR0OBBYEFDHDeRu69VPXF+CJ ei0XbAqzK50zMA8GA1UdEwQIMAYBAf8CAQUwDgYDVR0PAQH/BAQDAgEGMA0GCSqGSIb3DQEBBQUA A4IBAQCUZFmtOWTnKesT/lrDixNXyAQk8HR3wGDjZ/vpiaaDv5aCfG7Uwz3vnoBuuym0mHqxO1Tr ORdHfhqOC/wfMVkxBLLOF/Msx2I2VeIi2IlVtJhIqmT61hw22ER4WlojOleX9XowT66fakxLK46g A+M+4KnU0nvSs6jicjytnv+AWeSbRbT2O7DNORmYMuXqIWGQ5DEhjjSx9y81SoUQ2ueKNyG+WWPg 8oWIMVPUVBSFcHn0LgZ3J3UvH7iK+f7Futg25IPs52W3v2Na80avgZQ31EGM1iPWHs/1aBtEY6Ja uqc1WaHlcAWbDiNXmZQKbbo5YyiGkvMYhNj70c8FVmRXMIIEITCCAwmgAwIBAgICAMcwDQYJKoZI hvcNAQEFBQAwcTELMAkGA1UEBhMCREUxHDAaBgNVBAoTE0RldXRzY2hlIFRlbGVrb20gQUcxHzAd BgNVBAsTFlQtVGVsZVNlYyBUcnVzdCBDZW50ZXIxIzAhBgNVBAMTGkRldXRzY2hlIFRlbGVrb20g Um9vdCBDQSAyMB4XDTA2MTIxOTEwMjkwMFoXDTE5MDYzMDIzNTkwMFowWjELMAkGA1UEBhMCREUx EzARBgNVBAoTCkRGTi1WZXJlaW4xEDAOBgNVBAsTB0RGTi1QS0kxJDAiBgNVBAMTG0RGTi1WZXJl aW4gUENBIEdsb2JhbCAtIEcwMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAOmbw2eF +Q2u9Y1Uw5ZQNT1i6W5M7ZTXAFuVInTUIOs0j9bswDEEC5mB4qYU0lKgKCOEi3SJBF5b4OJ4wXjL FssoNTl7LZBF0O2gAHp8v0oOGwDDhulcKzERewzzgiRDjBw4i2poAJru3E94q9LGE5t2re7eJujv Aa90D8EJovZrzr3TzRQwT/Xl46TIYpuCGgMnMA0CZWBN7dEJIyqWNVgn03bGcbaQHcTt/zWGfW8z s9sPxRHCioOhlF1Ba9jSEPVM/cpRrNm975KDu9rrixZWVkPP4dUTPaYfJzDNSVTbyRM0mnF1xWzq pwuY+SGdJ68+ozk5SGqMrcmZ+8MS8r0CAwEAAaOB2TCB1jBwBgNVHR8EaTBnMGWgY6Bhhl9odHRw Oi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNybD8tY3Js X2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjAdBgNVHQ4EFgQUSbfGz+g9H3/qRHsT KffxCnA+3mQwHwYDVR0jBBgwFoAUMcN5G7r1U9cX4Il6LRdsCrMrnTMwDgYDVR0PAQH/BAQDAgEG MBIGA1UdEwEB/wQIMAYBAf8CAQIwDQYJKoZIhvcNAQEFBQADggEBADvhWnfASBfcqRjsga9aifC9 KJKmylkYEnDsKPLnrn+WLOfyXRkx9hMrdL29gLK592fJOaJ5O+EREe5reJEzfjtfJid1U2WOM2Pu z3PDsJIjSSFQdSOhHxjilIU9PzPpdyCNor3moYUpQPY/czJYDQlrptqFbMA/u41mZFYkTq4NPzI1 AVvpjILZcllPsYaF8XSFVuXD+Fzzje5Hs1MFcOflTYppgyjhEwmGnl7I6lgeDB/5pNRaBGj9KD6L ArZYtfahLDdXAGerI2iNY6XvmWtc/UtW9qtAhzTUEZJs7IfFCgsHM3K0bwwdVCzYUcfMvzDTQ3Lx Mr+MzkljqAD38hwwggQhMIIDCaADAgECAgIAxzANBgkqhkiG9w0BAQUFADBxMQswCQYDVQQGEwJE RTEcMBoGA1UEChMTRGV1dHNjaGUgVGVsZWtvbSBBRzEfMB0GA1UECxMWVC1UZWxlU2VjIFRydXN0 IENlbnRlcjEjMCEGA1UEAxMaRGV1dHNjaGUgVGVsZWtvbSBSb290IENBIDIwHhcNMDYxMjE5MTAy OTAwWhcNMTkwNjMwMjM1OTAwWjBaMQswCQYDVQQGEwJERTETMBEGA1UEChMKREZOLVZlcmVpbjEQ MA4GA1UECxMHREZOLVBLSTEkMCIGA1UEAxMbREZOLVZlcmVpbiBQQ0EgR2xvYmFsIC0gRzAxMIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA6ZvDZ4X5Da71jVTDllA1PWLpbkztlNcAW5Ui dNQg6zSP1uzAMQQLmYHiphTSUqAoI4SLdIkEXlvg4njBeMsWyyg1OXstkEXQ7aAAeny/Sg4bAMOG 6VwrMRF7DPOCJEOMHDiLamgAmu7cT3ir0sYTm3at7t4m6O8Br3QPwQmi9mvOvdPNFDBP9eXjpMhi m4IaAycwDQJlYE3t0QkjKpY1WCfTdsZxtpAdxO3/NYZ9bzOz2w/FEcKKg6GUXUFr2NIQ9Uz9ylGs 2b3vkoO72uuLFlZWQ8/h1RM9ph8nMM1JVNvJEzSacXXFbOqnC5j5IZ0nrz6jOTlIaoytyZn7wxLy vQIDAQABo4HZMIHWMHAGA1UdHwRpMGcwZaBjoGGGX2h0dHA6Ly9wa2kudGVsZXNlYy5kZS9jZ2kt YmluL3NlcnZpY2UvYWZfRG93bmxvYWRBUkwuY3JsPy1jcmxfZm9ybWF0PVhfNTA5Ji1pc3N1ZXI9 RFRfUk9PVF9DQV8yMB0GA1UdDgQWBBRJt8bP6D0ff+pEexMp9/EKcD7eZDAfBgNVHSMEGDAWgBQx w3kbuvVT1xfgiXotF2wKsyudMzAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIBAjAN BgkqhkiG9w0BAQUFAAOCAQEAO+Fad8BIF9ypGOyBr1qJ8L0okqbKWRgScOwo8ueuf5Ys5/JdGTH2 Eyt0vb2Asrn3Z8k5onk74RER7mt4kTN+O18mJ3VTZY4zY+7Pc8OwkiNJIVB1I6EfGOKUhT0/M+l3 II2iveahhSlA9j9zMlgNCWum2oVswD+7jWZkViROrg0/MjUBW+mMgtlyWU+xhoXxdIVW5cP4XPON 7kezUwVw5+VNimmDKOETCYaeXsjqWB4MH/mk1FoEaP0oPosCtli19qEsN1cAZ6sjaI1jpe+Za1z9 S1b2q0CHNNQRkmzsh8UKCwczcrRvDB1ULNhRx8y/MNNDcvEyv4zOSWOoAPfyHDCCBO8wggPXoAMC AQICBA0hCk0wDQYJKoZIhvcNAQEFBQAwWjELMAkGA1UEBhMCREUxEzARBgNVBAoTCkRGTi1WZXJl aW4xEDAOBgNVBAsTB0RGTi1QS0kxJDAiBgNVBAMTG0RGTi1WZXJlaW4gUENBIEdsb2JhbCAtIEcw MTAeFw0wODEwMjQwODUyMTNaFw0xOTA2MzAwMDAwMDBaMGkxCzAJBgNVBAYTAkRFMS4wLAYDVQQK EyVQaHlzaWthbGlzY2gtVGVjaG5pc2NoZSBCdW5kZXNhbnN0YWx0MQ8wDQYDVQQDEwZQVEIgQ0Ex GTAXBgkqhkiG9w0BCQEWCnBraUBwdGIuZGUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQC8CsKDOSrDYswBi5TfxUlODIYEL4+n66/DnYua0jowQyIWvTFjpITNhwMbfPk1KiFmKx2cvtu7 wR7swUPdNlfWNUGJ7/9Q0AmpdsedTMTyFslgJHnJ1v1aojOhPk/MbTuolZuVuJ1ytlVwJAR5/1XU JpHJ9e6qJJM6CJuo4Ms/3w3uMwgibPaKlSAx2gbI6BKH+p2zlIzoJSDAx64njZClg2i32uLUgoDB 7KEghrdMA2y7nqxzL4Vzb5dY5+y4iZ54txqK7ock+TpfnlBP6RZoChB/qonIle/xv+fqXWeZMhTY BjYHkSc7+shP4Nb4wnLvv8c77uu3BrOe6e1cyDK3AgMBAAGjggGsMIIBqDASBgNVHRMBAf8ECDAG AQH/AgEBMAsGA1UdDwQEAwIBBjAdBgNVHQ4EFgQUxIDQbigVaDFa7HBfeI7hMEM46jQwHwYDVR0j BBgwFoAUSbfGz+g9H3/qRHsTKffxCnA+3mQwFQYDVR0RBA4wDIEKcGtpQHB0Yi5kZTCBiAYDVR0f BIGAMH4wPaA7oDmGN2h0dHA6Ly9jZHAxLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2Ny bC9jYWNybC5jcmwwPaA7oDmGN2h0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2Ev cHViL2NybC9jYWNybC5jcmwwgaIGCCsGAQUFBwEBBIGVMIGSMEcGCCsGAQUFBzAChjtodHRwOi8v Y2RwMS5wY2EuZGZuLmRlL2dsb2JhbC1yb290LWNhL3B1Yi9jYWNlcnQvY2FjZXJ0LmNydDBHBggr BgEFBQcwAoY7aHR0cDovL2NkcDIucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY2FjZXJ0 L2NhY2VydC5jcnQwDQYJKoZIhvcNAQEFBQADggEBAJ3KSKdj6GjgE6pSuE74pBcKLfmC2Phy1Gfj 83Lzx9leQX67sL6uTIV5NTQgQDsjTlqyxRQJ5eYhj+ZjwfVS02pDdD+trg2iGp1WdFFsqyhts+oS M4SpRUuZ83FHEieuWq9teT7bcWPUzckYy4k17u9LAp7+V1h7s6aOpk9RCyA1sSlFTP33O9tpLwXq KpXHK+zG9JOV7kPDHYLAi2Krw5LB91EBSyXWLu7xK4i6prEUGRWVblckx116ikhBFy3cNr2NGfhh KiOCphAeIFPCCxOEvRk/LkZRnZaMnHQsUHVuAs2SBB08coYSjF7/NZAXprZlpI2KZiUfeo6JU9bS UbowggTvMIID16ADAgECAgQNIQpNMA0GCSqGSIb3DQEBBQUAMFoxCzAJBgNVBAYTAkRFMRMwEQYD VQQKEwpERk4tVmVyZWluMRAwDgYDVQQLEwdERk4tUEtJMSQwIgYDVQQDExtERk4tVmVyZWluIFBD QSBHbG9iYWwgLSBHMDEwHhcNMDgxMDI0MDg1MjEzWhcNMTkwNjMwMDAwMDAwWjBpMQswCQYDVQQG EwJERTEuMCwGA1UEChMlUGh5c2lrYWxpc2NoLVRlY2huaXNjaGUgQnVuZGVzYW5zdGFsdDEPMA0G A1UEAxMGUFRCIENBMRkwFwYJKoZIhvcNAQkBFgpwa2lAcHRiLmRlMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAvArCgzkqw2LMAYuU38VJTgyGBC+Pp+uvw52LmtI6MEMiFr0xY6SEzYcD G3z5NSohZisdnL7bu8Ee7MFD3TZX1jVBie//UNAJqXbHnUzE8hbJYCR5ydb9WqIzoT5PzG07qJWb lbidcrZVcCQEef9V1CaRyfXuqiSTOgibqODLP98N7jMIImz2ipUgMdoGyOgSh/qds5SM6CUgwMeu J42QpYNot9ri1IKAweyhIIa3TANsu56scy+Fc2+XWOfsuImeeLcaiu6HJPk6X55QT+kWaAoQf6qJ yJXv8b/n6l1nmTIU2AY2B5EnO/rIT+DW+MJy77/HO+7rtwaznuntXMgytwIDAQABo4IBrDCCAagw EgYDVR0TAQH/BAgwBgEB/wIBATALBgNVHQ8EBAMCAQYwHQYDVR0OBBYEFMSA0G4oFWgxWuxwX3iO 4TBDOOo0MB8GA1UdIwQYMBaAFEm3xs/oPR9/6kR7Eyn38QpwPt5kMBUGA1UdEQQOMAyBCnBraUBw dGIuZGUwgYgGA1UdHwSBgDB+MD2gO6A5hjdodHRwOi8vY2RwMS5wY2EuZGZuLmRlL2dsb2JhbC1y b290LWNhL3B1Yi9jcmwvY2FjcmwuY3JsMD2gO6A5hjdodHRwOi8vY2RwMi5wY2EuZGZuLmRlL2ds b2JhbC1yb290LWNhL3B1Yi9jcmwvY2FjcmwuY3JsMIGiBggrBgEFBQcBAQSBlTCBkjBHBggrBgEF BQcwAoY7aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY2FjZXJ0L2Nh Y2VydC5jcnQwRwYIKwYBBQUHMAKGO2h0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3Qt Y2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MA0GCSqGSIb3DQEBBQUAA4IBAQCdykinY+ho4BOqUrhO +KQXCi35gtj4ctRn4/Ny88fZXkF+u7C+rkyFeTU0IEA7I05assUUCeXmIY/mY8H1UtNqQ3Q/ra4N ohqdVnRRbKsobbPqEjOEqUVLmfNxRxInrlqvbXk+23Fj1M3JGMuJNe7vSwKe/ldYe7OmjqZPUQsg NbEpRUz99zvbaS8F6iqVxyvsxvSTle5Dwx2CwItiq8OSwfdRAUsl1i7u8SuIuqaxFBkVlW5XJMdd eopIQRct3Da9jRn4YSojgqYQHiBTwgsThL0ZPy5GUZ2WjJx0LFB1bgLNkgQdPHKGEoxe/zWQF6a2 ZaSNimYlH3qOiVPW0lG6MIIFCjCCA/KgAwIBAgIHE3VRA4JzBjANBgkqhkiG9w0BAQUFADBpMQsw CQYDVQQGEwJERTEuMCwGA1UEChMlUGh5c2lrYWxpc2NoLVRlY2huaXNjaGUgQnVuZGVzYW5zdGFs dDEPMA0GA1UEAxMGUFRCIENBMRkwFwYJKoZIhvcNAQkBFgpwa2lAcHRiLmRlMB4XDTEyMDMwNjA5 MDU1NVoXDTE1MDMwNjA5MDU1NVowaDELMAkGA1UEBhMCREUxLjAsBgNVBAoTJVBoeXNpa2FsaXNj aC1UZWNobmlzY2hlIEJ1bmRlc2Fuc3RhbHQxDTALBgNVBAsTBFEuNDIxGjAYBgNVBAMTEURyLiBE aWV0ZXIgU2lib2xkMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3A4qPUWvMdRKdf6n 8n4ILMz17CkFLSBykOfvNqK0Xki5G1uEN0Lm4B9OznfnLLetkncla3k/LUVI7CfjFoYM/CS3BfQg gO9sTHi9oTyusMCm+to0JeEJ5oIijmGzIPLRGTXjQP1Hy/HFcRHvSbGNGK2S6hOBiM7Upn1bnZLc 3Y8Cd0SW9Dk0ZB1LfBi4sy+cqzTi0YU5LTfg2blwWJPoZW1zxCerdPMnoAu+EcD3naDjjR6K0A6H 0KIMmb3JsGBW7Uz7yyAllmF3QUpFGL2I6vHdSYBqIaxxv7qsly6juExhZqsxKpyZYeECs+W2fz8B Nzf2nxGHlGDqvzje5gEpUQIDAQABo4IBtjCCAbIwCQYDVR0TBAIwADALBgNVHQ8EBAMCBeAwKQYD VR0lBCIwIAYIKwYBBQUHAwIGCCsGAQUFBwMEBgorBgEEAYI3FAICMB0GA1UdDgQWBBSMITESopjC ckNxeIcM6c7MrI80gzAfBgNVHSMEGDAWgBTEgNBuKBVoMVrscF94juEwQzjqNDAfBgNVHREEGDAW gRRkaWV0ZXIuc2lib2xkQHB0Yi5kZTB3BgNVHR8EcDBuMDWgM6Axhi9odHRwOi8vY2RwMS5wY2Eu ZGZuLmRlL3B0Yi1jYS9wdWIvY3JsL2NhY3JsLmNybDA1oDOgMYYvaHR0cDovL2NkcDIucGNhLmRm bi5kZS9wdGItY2EvcHViL2NybC9jYWNybC5jcmwwgZIGCCsGAQUFBwEBBIGFMIGCMD8GCCsGAQUF BzAChjNodHRwOi8vY2RwMS5wY2EuZGZuLmRlL3B0Yi1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQw PwYIKwYBBQUHMAKGM2h0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvcHRiLWNhL3B1Yi9jYWNlcnQvY2Fj ZXJ0LmNydDANBgkqhkiG9w0BAQUFAAOCAQEADZnBfu/SYDcvnobrn/SPrQkf/b9cXJOiZDDTsT5C TG6M9tP6vp6Ng1JmecoDHesQG4zOBMGo2Bop9lQiXfEXAQlmJL1aE/F+bdFoJ8OLd1+CQOdciKwY ndt+fXP6eZNUPE366bOYM9EFOU0HxjyzJSaZO7aa+POXFeA8teX/KmWuCvLbPAedZBIbj9lcZMwa c1zoLgoHOk+jywDfbNnU8y8KFW6lZ/rpL8L2VUqIVBrdoUkau4Hc2LJ3bRYfU8Usx29sJHMOrW3c k4E63FoujxLVLl9uxsdEN20TJQaY9RsVzTnOJmqa2mLlcG6EkUGOivnP24Wueo2Go+8rT+LuEzCC BQowggPyoAMCAQICBxN1UQOCcwYwDQYJKoZIhvcNAQEFBQAwaTELMAkGA1UEBhMCREUxLjAsBgNV BAoTJVBoeXNpa2FsaXNjaC1UZWNobmlzY2hlIEJ1bmRlc2Fuc3RhbHQxDzANBgNVBAMTBlBUQiBD QTEZMBcGCSqGSIb3DQEJARYKcGtpQHB0Yi5kZTAeFw0xMjAzMDYwOTA1NTVaFw0xNTAzMDYwOTA1 NTVaMGgxCzAJBgNVBAYTAkRFMS4wLAYDVQQKEyVQaHlzaWthbGlzY2gtVGVjaG5pc2NoZSBCdW5k ZXNhbnN0YWx0MQ0wCwYDVQQLEwRRLjQyMRowGAYDVQQDExFEci4gRGlldGVyIFNpYm9sZDCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANwOKj1FrzHUSnX+p/J+CCzM9ewpBS0gcpDn7zai tF5IuRtbhDdC5uAfTs535yy3rZJ3JWt5Py1FSOwn4xaGDPwktwX0IIDvbEx4vaE8rrDApvraNCXh CeaCIo5hsyDy0Rk140D9R8vxxXER70mxjRitkuoTgYjO1KZ9W52S3N2PAndElvQ5NGQdS3wYuLMv nKs04tGFOS034Nm5cFiT6GVtc8Qnq3TzJ6ALvhHA952g440eitAOh9CiDJm9ybBgVu1M+8sgJZZh d0FKRRi9iOrx3UmAaiGscb+6rJcuo7hMYWarMSqcmWHhArPltn8/ATc39p8Rh5Rg6r843uYBKVEC AwEAAaOCAbYwggGyMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgXgMCkGA1UdJQQiMCAGCCsGAQUFBwMC BggrBgEFBQcDBAYKKwYBBAGCNxQCAjAdBgNVHQ4EFgQUjCExEqKYwnJDcXiHDOnOzKyPNIMwHwYD VR0jBBgwFoAUxIDQbigVaDFa7HBfeI7hMEM46jQwHwYDVR0RBBgwFoEUZGlldGVyLnNpYm9sZEBw dGIuZGUwdwYDVR0fBHAwbjA1oDOgMYYvaHR0cDovL2NkcDEucGNhLmRmbi5kZS9wdGItY2EvcHVi L2NybC9jYWNybC5jcmwwNaAzoDGGL2h0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvcHRiLWNhL3B1Yi9j cmwvY2FjcmwuY3JsMIGSBggrBgEFBQcBAQSBhTCBgjA/BggrBgEFBQcwAoYzaHR0cDovL2NkcDEu cGNhLmRmbi5kZS9wdGItY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MD8GCCsGAQUFBzAChjNodHRw Oi8vY2RwMi5wY2EuZGZuLmRlL3B0Yi1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwDQYJKoZIhvcN AQEFBQADggEBAA2ZwX7v0mA3L56G65/0j60JH/2/XFyTomQw07E+QkxujPbT+r6ejYNSZnnKAx3r EBuMzgTBqNgaKfZUIl3xFwEJZiS9WhPxfm3RaCfDi3dfgkDnXIisGJ3bfn1z+nmTVDxN+umzmDPR BTlNB8Y8syUmmTu2mvjzlxXgPLXl/yplrgry2zwHnWQSG4/ZXGTMGnNc6C4KBzpPo8sA32zZ1PMv ChVupWf66S/C9lVKiFQa3aFJGruB3Niyd20WH1PFLMdvbCRzDq1t3JOBOtxaLo8S1S5fbsbHRDdt EyUGmPUbFc05ziZqmtpi5XBuhJFBjor5z9uFrnqNhqPvK0/i7hMxggLJMIICxQIBATB0MGkxCzAJ BgNVBAYTAkRFMS4wLAYDVQQKEyVQaHlzaWthbGlzY2gtVGVjaG5pc2NoZSBCdW5kZXNhbnN0YWx0 MQ8wDQYDVQQDEwZQVEIgQ0ExGTAXBgkqhkiG9w0BCQEWCnBraUBwdGIuZGUCBxN1UQOCcwYwCQYF Kw4DAhoFAKCCASowGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMw ODE0MDczNDUxWjAjBgkqhkiG9w0BCQQxFgQUagfjDCdJSaInBMpQSnomOsOWj7swQwYJKoZIhvcN AQkPMTYwNDAHBgUrDgMCHTAOBggqhkiG9w0DAgICAIAwCgYIKoZIhvcNAwcwDQYIKoZIhvcNAwIC ASgwgYUGCyqGSIb3DQEJEAILMXagdDBpMQswCQYDVQQGEwJERTEuMCwGA1UEChMlUGh5c2lrYWxp c2NoLVRlY2huaXNjaGUgQnVuZGVzYW5zdGFsdDEPMA0GA1UEAxMGUFRCIENBMRkwFwYJKoZIhvcN AQkBFgpwa2lAcHRiLmRlAgcTdVEDgnMGMA0GCSqGSIb3DQEBAQUABIIBABxx4W2BoyaD/54SDKhv Ack7oPx/kAQBbt/Gz2O2ENrwM5/ihfhbz5ZkSj2yJvY4Fu958SmvC83fk8f8frgSFVMlpAWMDTJa rJH0Crl0DxKoOSaLdZMm8IB3AuZyV6rmE+Hl10MCHO64krnjqEZyg9D3BYsK9GgoAxAZ4sBLgtcj s3FEEJ+BnClBhAHEpMV3hDD4hgChu8ZO72FuZXPd8bo9sBP9gkMs99Vt822BBFz3aQKzlILY0DZp xjga3lFq6uFZMrhtJrMDe8+xbvIFb/YKXNpMjNuLlk8QgoxETr2h9murjzPN5+tX7CVy/d8ZU3Mj LAs6RQ+g2PyER6mx2ioAAAAA ---------z64412_boundary_sign-- --===============1659868427026973667== 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 --===============1659868427026973667==-- From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Wed Aug 14 02:34:45 2013 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 C46B421F9E33 for ; Wed, 14 Aug 2013 02:34:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KiNsAPriNjlj for ; Wed, 14 Aug 2013 02:34: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 0546C21F9A33 for ; Wed, 14 Aug 2013 02:34:40 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id 6D0F086D76A for ; Wed, 14 Aug 2013 09:34:40 +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 EA59986D333 for ; Wed, 14 Aug 2013 09:34:32 +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.77 (FreeBSD)) (envelope-from ) id 1V9XTL-000L54-Og for ntpwg@lists.ntp.org; Wed, 14 Aug 2013 09:34:32 +0000 Received: from [92.63.173.118] (account y0034674@tu-braunschweig.de HELO [0.0.0.0]) by rz.tu-bs.de (CommuniGate Pro SMTP 5.4.9) with ESMTPA id 19561051; Wed, 14 Aug 2013 11:34:24 +0200 Message-ID: <520B4F15.5070808@tu-bs.de> Date: Wed, 14 Aug 2013 11:34:13 +0200 From: =?ISO-8859-1?Q?Stephen_R=F6ttger?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130805 Thunderbird/17.0.8 MIME-Version: 1.0 To: Hal Murray References: <20130808084540.2923E406063@ip-64-139-1-69.sjc.megapath.net> In-Reply-To: <20130808084540.2923E406063@ip-64-139-1-69.sjc.megapath.net> X-TagToolbar-Keys: D20130814113413377 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) Cc: ntpwg@lists.ntp.org Subject: Re: [ntpwg] security ID submitted for review X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.14 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 Errors-To: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Sender: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org > Does anybody have a good URL that summarizes doing crypto with vs without > knowing the time? The time has to be known in order to verify the expiration date on certificates. When I researched the arguments for an expiration date, I found the following link quite insightful: http://security.stackexchange.com/questions/31463/why-do-we-not-trust-an-ssl-certificate-that-expired-recently In order to limit the size of certificate revocation lists, they will not include expired certificates. As a consequence, a client that does not know the current time can not check the revocation status of a certificate. Thus, I think it's crucial that we require checking special revocation lists that do not purge expired certificates. _______________________________________________ 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 Aug 27 06:53:58 2013 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 0E5D021F9E5C for ; Tue, 27 Aug 2013 06:53:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.298 X-Spam-Level: X-Spam-Status: No, score=-6.298 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vxbqi4lc8vFG for ; Tue, 27 Aug 2013 06:53:53 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [IPv6:2001:4f8:fff7:1::7]) by ietfa.amsl.com (Postfix) with ESMTP id 2442521E80C9 for ; Tue, 27 Aug 2013 06:53:53 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id AE8FD86DAAD for ; Tue, 27 Aug 2013 13:53:51 +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 CED0486D562 for ; Tue, 27 Aug 2013 13:53:33 +0000 (UTC) Received: from deacon.udel.edu ([128.4.2.5] helo=whimsy.udel.edu) by mail1.ntp.org with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1VEJi6-000OtW-RW for ntpwg@lists.ntp.org; Tue, 27 Aug 2013 13:53:33 +0000 Received: by whimsy.udel.edu (Postfix, from userid 62) id D2C38816F; Tue, 27 Aug 2013 13:53:29 +0000 (UTC) Received: from [128.4.2.11] (hepzibah.udel.edu [128.4.2.11]) by whimsy.udel.edu (Postfix) with ESMTP id 05C07816C; Tue, 27 Aug 2013 13:53:28 +0000 (UTC) Message-ID: <521CAF57.6090703@udel.edu> Date: Tue, 27 Aug 2013 13:53:27 +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: =?ISO-8859-1?Q?Stephen_R=F6ttger?= References: <20130808084540.2923E406063@ip-64-139-1-69.sjc.megapath.net> <520B4F15.5070808@tu-bs.de> In-Reply-To: <520B4F15.5070808@tu-bs.de> X-SA-Exim-Connect-IP: 128.4.2.5 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, Hal Murray Subject: Re: [ntpwg] security ID submitted for review X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.14 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="===============3506417008585672612==" Errors-To: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Sender: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org This is a multi-part message in MIME format. --===============3506417008585672612== Content-Type: multipart/alternative; boundary="------------050106080403080504090802" This is a multi-part message in MIME format. --------------050106080403080504090802 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Stephen, Unfortunately, things are not that simple. We must assume that the=20 system clock is not necessarily synchronized at the time the certificate=20 trail is constructed. This means that the only time test is to insure=20 that the valid time interval of the subject certificate overlaps the=20 valid time interval of the issuer certificate.=20 This raises an interesting issue. It could be that issuer A interval=20 overlaps subject B interval on the trail, while issuer B interval=20 overlaps subject C interval, but issuer A interval does not overlap=20 subject C interval. Consider the A interval is valid during 2011, B is valid during 2012=20 and C is valid during 2013. In this example, interval A does not=20 overlap interval C, but the trail is considered valid. Validity could=20 in fact be extended if all three intervals were required to be extended=20 to the present time, but this is extremely awkward, especially if the=20 current time has not yet been determined.=20 In particular, none of the intevals can be reckoned with time until all=20 machines are synchronized to a reference source as indicated by the NTP=20 on-wire selection and other algorithms of the NTP client. It does not=20 seem prudent to rely on revocation lists maintained by other processes,=20 especially if these processes require time synchronization. In the current Autokey design, every client and server is assigned a=20 self-signed certificate valid from the time of signing to one year=20 hence. Once the client has been synchronized to a proventic source, the=20 client requests the server to sign its certificate. The certificate is=20 available to dependent clients during the Autokey dance by the dependent=20 client. Errors due to invalid intervals are inevitably caught during=20 the dance. Perhaps, this short validity interval choice was unwise, as=20 this requires all certificates to be regenerated every year. Longer=20 intervals might be more appropriate for future systems.=20 When an interval error is discovered, the client association is=20 cleared. The error results in a Crypto-NAK message, which restarts the=20 dance from the beginning.=20 There might be other interpretations and/or requirements for opposed=20 systems; however, these all have to be consistent with the intended NTP=20 and/or PTP architecture and protocols.=20 Dave Stephen R=F6ttger wrote: >>Does anybody have a good URL that summarizes doing crypto with vs witho= ut >>knowing the time? >> =20 >> > >The time has to be known in order to verify the expiration date on >certificates. When I researched the arguments for an expiration date, I >found the following link quite insightful: > >http://security.stackexchange.com/questions/31463/why-do-we-not-trust-an= -ssl-certificate-that-expired-recently > >In order to limit the size of certificate revocation lists, they will >not include expired certificates. As a consequence, a client that does >not know the current time can not check the revocation status of a >certificate. Thus, I think it's crucial that we require checking special >revocation lists that do not purge expired certificates. >_______________________________________________ >ntpwg mailing list >ntpwg@lists.ntp.org >http://lists.ntp.org/listinfo/ntpwg > =20 > --------------050106080403080504090802 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Stephen,

Unfortunately, things are not that simple.  We must assume that the system clock is not necessarily synchronized at the time the certificate trail is constructed.  This means that the only time test is to insure that the valid time interval of the subject certificate overlaps the valid time interval of the issuer certificate. 

This raises an interesting issue.  It could be that issuer A interval overlaps subject B interval on the trail, while issuer B interval overlaps subject C interval, but issuer A interval does not overlap subject C interval.
Consider the A interval is valid during 2011,  B is valid during  2012 and C is valid during 2013.  In this example, interval A does not overlap interval C, but the trail is considered valid.  Validity could in fact be extended if all three intervals were required to be extended to the present time, but this is extremely awkward, especially if the current time has not yet been determined. 

In particular, none of the intevals can be reckoned with time until  all machines are synchronized to a  reference source as indicated by the NTP on-wire selection and other algorithms of the NTP client.  It does not seem prudent to rely on revocation lists maintained by other processes, especially if these processes require time synchronization.

In the current Autokey design, every client and server is assigned a self-signed certificate valid from the time of signing to one year hence.  Once the client has been synchronized to a proventic source, the client requests the server to sign its certificate.  The certificate is available to dependent clients during the Autokey dance by the dependent client.  Errors due to invalid intervals are inevitably caught during the dance.  Perhaps, this short validity interval choice was unwise, as this requires all certificates to be regenerated every year. Longer intervals might be more appropriate for future systems. 

When an interval error is discovered, the client association is cleared.  The error results in a Crypto-NAK message, which restarts the dance from the beginning. 

There might be other interpretations and/or requirements for opposed systems; however, these all have to be consistent with the intended NTP and/or PTP architecture and protocols. 

Dave

Stephen Röttger wrote: 
Does anybody have a good URL that summarizes doing crypto with vs without
knowing the time?
    

The time has to be known in order to verify the expiration date on
certificates. When I researched the arguments for an expiration date, I
found the following link quite insightful:

http://security.stackexchange.com/questions/31463/why-do-we-not-trust-an-ssl-certificate-that-expired-recently

In order to limit the size of certificate revocation lists, they will
not include expired certificates. As a consequence, a client that does
not know the current time can not check the revocation status of a
certificate. Thus, I think it's crucial that we require checking special
revocation lists that do not purge expired certificates.
_______________________________________________
ntpwg mailing list
ntpwg@lists.ntp.org
http://lists.ntp.org/listinfo/ntpwg

--------------050106080403080504090802-- --===============3506417008585672612== 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 --===============3506417008585672612==-- From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Tue Aug 27 07:51:54 2013 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 45B2C21F9D69 for ; Tue, 27 Aug 2013 07:51:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KKytWftKrerd for ; Tue, 27 Aug 2013 07:51:49 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [IPv6:2001:4f8:fff7:1::7]) by ietfa.amsl.com (Postfix) with ESMTP id E971D21F9D23 for ; Tue, 27 Aug 2013 07:51:48 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id C83A486DAA9 for ; Tue, 27 Aug 2013 14:51:46 +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 9B44086D562 for ; Tue, 27 Aug 2013 14:51:37 +0000 (UTC) Received: from mailfront1.rz.tu-bs.de ([134.169.12.132] helo=tu-bs.de) by mail1.ntp.org with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1VEKcK-000PBc-3L for ntpwg@lists.ntp.org; Tue, 27 Aug 2013 14:51:37 +0000 Received: from [134.169.34.1] (account y0034674@tu-braunschweig.de HELO [10.1.0.81]) by rz.tu-bs.de (CommuniGate Pro SMTP 5.4.9) with ESMTPA id 39854274; Tue, 27 Aug 2013 16:51:27 +0200 Message-ID: <521CBCED.3020809@tu-bs.de> Date: Tue, 27 Aug 2013 16:51:25 +0200 From: =?ISO-8859-1?Q?Stephen_R=F6ttger?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130805 Thunderbird/17.0.8 MIME-Version: 1.0 To: "David L. Mills" References: <20130808084540.2923E406063@ip-64-139-1-69.sjc.megapath.net> <520B4F15.5070808@tu-bs.de> <521CAF57.6090703@udel.edu> In-Reply-To: <521CAF57.6090703@udel.edu> X-TagToolbar-Keys: D20130827165125589 X-SA-Exim-Connect-IP: 134.169.12.132 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) Cc: ntpwg@lists.ntp.org, Hal Murray Subject: Re: [ntpwg] security ID submitted for review X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.14 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 Errors-To: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Sender: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Hi David, > Consider the A interval is valid during 2011, B is valid during 2012 > and C is valid during 2013. In this example, interval A does not > overlap interval C, but the trail is considered valid. This is wrong, if a single certificate in a chain is invalid, the whole chain can not be trusted. > In the current Autokey design, every client and server is assigned a > self-signed certificate valid from the time of signing to one year > hence. Once the client has been synchronized to a proventic source, the > client requests the server to sign its certificate. I don't really see the point of this. If the server signs the certificate of the client, it will only state that the client communicated with the server once. There is no security benefit in this practice since it will not stop the client from lying about the current time. An attacker can simply retrieve these signatures from arbitrary servers. If we do authenticated time synchronization, we simply can not rely on the current time in any way. Any automatic approach to circumvent this problem, for example by using another secure channel for an initial time synchronization, will again have to use cryptography without a known time and thus have the same problem. Regards, Stephen _______________________________________________ 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 Aug 27 10:04:12 2013 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 B5C4C21F9BD8 for ; Tue, 27 Aug 2013 10:04:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7PzDVofRkiGl for ; Tue, 27 Aug 2013 10:04: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 8848A21F9A98 for ; Tue, 27 Aug 2013 10:04:07 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id 919B786DAA5 for ; Tue, 27 Aug 2013 17:04: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 7936886D58E for ; Tue, 27 Aug 2013 17:03:55 +0000 (UTC) Received: from juliette.telenet-ops.be ([195.130.137.74]) by mail1.ntp.org with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1VEMgL-0000TQ-RO for ntpwg@lists.ntp.org; Tue, 27 Aug 2013 17:03:55 +0000 Received: from intrepid.roeckx.be ([94.226.199.45]) by juliette.telenet-ops.be with bizsmtp id Ht3q1m00a0zFtyu06t3qEl; Tue, 27 Aug 2013 19:03:50 +0200 Received: by intrepid.roeckx.be (Postfix, from userid 1000) id 3A242EB2EC; Tue, 27 Aug 2013 19:03:50 +0200 (CEST) Date: Tue, 27 Aug 2013 19:03:50 +0200 From: Kurt Roeckx To: Stephen =?iso-8859-1?Q?R=F6ttger?= Message-ID: <20130827170350.GA725@roeckx.be> References: <20130808084540.2923E406063@ip-64-139-1-69.sjc.megapath.net> <520B4F15.5070808@tu-bs.de> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <520B4F15.5070808@tu-bs.de> User-Agent: Mutt/1.5.21 (2010-09-15) X-SA-Exim-Connect-IP: 195.130.137.74 X-SA-Exim-Rcpt-To: ntpwg@lists.ntp.org X-SA-Exim-Mail-From: kurt@roeckx.be X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) Cc: ntpwg@lists.ntp.org, Hal Murray Subject: Re: [ntpwg] security ID submitted for review X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.14 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 Errors-To: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Sender: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org On Wed, Aug 14, 2013 at 11:34:13AM +0200, Stephen R=F6ttger wrote: > = > In order to limit the size of certificate revocation lists, they will > not include expired certificates. As a consequence, a client that does > not know the current time can not check the revocation status of a > certificate. Thus, I think it's crucial that we require checking special > revocation lists that do not purge expired certificates. I think CRLs really should be avoided, nobody downloads the CRLs. You probably want to use OCSP instead. But maybe not all CAs provide OCSP. What we don't want is OCSP stapling, since we don't know the time. To avoid a replay attack, we even want to use the nonce extention that doesn't seem to be used much. But it's possible that a MITM can still be done succesful and fake the time. However now it would require compromising both the certificate of the server and the CA. Kurt _______________________________________________ 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 Aug 27 23:03:30 2013 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 4226711E8144 for ; Tue, 27 Aug 2013 23:03:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ta1FZOPd7cQa for ; Tue, 27 Aug 2013 23: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 A576B11E810C for ; Tue, 27 Aug 2013 23:03:24 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id 6418786D763 for ; Wed, 28 Aug 2013 06:03:22 +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 46FAF86D33D for ; Wed, 28 Aug 2013 06:03:08 +0000 (UTC) Received: from rrzmta1.uni-regensburg.de ([194.94.155.51]) by mail1.ntp.org with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1VEYqQ-0004Pb-Qx for ntpwg@lists.ntp.org; Wed, 28 Aug 2013 06:03:08 +0000 Received: from rrzmta1.uni-regensburg.de (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 142863629F for ; Wed, 28 Aug 2013 08:02:58 +0200 (CEST) Received: from gwsmtp1.uni-regensburg.de (gwsmtp1.uni-regensburg.de [132.199.5.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "gwsmtp.uni-regensburg.de", Issuer "Uni Regensburg CA - G01" (not verified)) by rrzmta1.uni-regensburg.de (Postfix) with ESMTPS id 529C0362FC for ; Wed, 28 Aug 2013 08:02:57 +0200 (CEST) Received: from uni-regensburg-smtp1-MTA by gwsmtp1.uni-regensburg.de with Novell_GroupWise; Wed, 28 Aug 2013 08:01:39 +0200 Message-Id: <521DAEAB020000A1000125CD@gwsmtp1.uni-regensburg.de> X-Mailer: Novell GroupWise Internet Agent 12.0.2 Date: Wed, 28 Aug 2013 08:02:51 +0200 From: "Ulrich Windl" To: "=?UTF-8?Q?Stephen=20R=C3=B6ttger?=" , "David L. Mills" References: <20130808084540.2923E406063@ip-64-139-1-69.sjc.megapath.net> <520B4F15.5070808@tu-bs.de> <521CAF57.6090703@udel.edu> <521CBCED.3020809@tu-bs.de> In-Reply-To: <521CBCED.3020809@tu-bs.de> Mime-Version: 1.0 Content-Disposition: inline X-SA-Exim-Connect-IP: 194.94.155.51 X-SA-Exim-Rcpt-To: ntpwg@lists.ntp.org X-SA-Exim-Mail-From: Ulrich.Windl@rz.uni-regensburg.de X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) Cc: ntpwg@lists.ntp.org, Hal Murray Subject: [ntpwg] Antw: Re: security ID submitted for review X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.14 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="utf-8" Content-Transfer-Encoding: base64 Errors-To: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Sender: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Pj4+IFN0ZXBoZW4gUsO2dHRnZXI8cy5yb2V0dGdlckB0dS1icy5kZT4gc2NocmllYiBhbSAyNy4w OC4yMDEzIHVtIDE2OjUxIGluCk5hY2hyaWNodCA8NTIxQ0JDRUQuMzAyMDgwOUB0dS1icy5kZT46 Cj4gSGkgRGF2aWQsCj4gCj4+IENvbnNpZGVyIHRoZSBBIGludGVydmFsIGlzIHZhbGlkIGR1cmlu ZyAyMDExLCAgQiBpcyB2YWxpZCBkdXJpbmcgIDIwMTIKPj4gYW5kIEMgaXMgdmFsaWQgZHVyaW5n IDIwMTMuICBJbiB0aGlzIGV4YW1wbGUsIGludGVydmFsIEEgZG9lcyBub3QKPj4gb3ZlcmxhcCBp bnRlcnZhbCBDLCBidXQgdGhlIHRyYWlsIGlzIGNvbnNpZGVyZWQgdmFsaWQuCj4gCj4gVGhpcyBp cyB3cm9uZywgaWYgYSBzaW5nbGUgY2VydGlmaWNhdGUgaW4gYSBjaGFpbiBpcyBpbnZhbGlkLCB0 aGUgd2hvbGUKPiBjaGFpbiBjYW4gbm90IGJlIHRydXN0ZWQuCj4gCj4+IEluIHRoZSBjdXJyZW50 IEF1dG9rZXkgZGVzaWduLCBldmVyeSBjbGllbnQgYW5kIHNlcnZlciBpcyBhc3NpZ25lZCBhCj4+ IHNlbGYtc2lnbmVkIGNlcnRpZmljYXRlIHZhbGlkIGZyb20gdGhlIHRpbWUgb2Ygc2lnbmluZyB0 byBvbmUgeWVhcgo+PiBoZW5jZS4gIE9uY2UgdGhlIGNsaWVudCBoYXMgYmVlbiBzeW5jaHJvbml6 ZWQgdG8gYSBwcm92ZW50aWMgc291cmNlLCB0aGUKPj4gY2xpZW50IHJlcXVlc3RzIHRoZSBzZXJ2 ZXIgdG8gc2lnbiBpdHMgY2VydGlmaWNhdGUuCj4gCj4gSSBkb24ndCByZWFsbHkgc2VlIHRoZSBw b2ludCBvZiB0aGlzLiBJZiB0aGUgc2VydmVyIHNpZ25zIHRoZQo+IGNlcnRpZmljYXRlIG9mIHRo ZSBjbGllbnQsIGl0IHdpbGwgb25seSBzdGF0ZSB0aGF0IHRoZSBjbGllbnQKPiBjb21tdW5pY2F0 ZWQgd2l0aCB0aGUgc2VydmVyIG9uY2UuIFRoZXJlIGlzIG5vIHNlY3VyaXR5IGJlbmVmaXQgaW4g dGhpcwoKSGkhCgpJJ20gYWN0dWFsbHkgbm90IGludG8gYWxsIHRoYXQsIGJ1dCBJIHRoaW5rIHRo ZSBjZXJ0aWZpY2F0ZSBqdXN0IHNheXMgdGhlCmNsaWVudCBoYXMgYSB2YWxpZCBjZXJ0aWZpY2F0 ZSwgbm90IHRoYXQgaXQgaGFzIHZhbGlkIHRpbWUuCgo+IHByYWN0aWNlIHNpbmNlIGl0IHdpbGwg bm90IHN0b3AgdGhlIGNsaWVudCBmcm9tIGx5aW5nIGFib3V0IHRoZSBjdXJyZW50Cj4gdGltZS4g QW4gYXR0YWNrZXIgY2FuIHNpbXBseSByZXRyaWV2ZSB0aGVzZSBzaWduYXR1cmVzIGZyb20gYXJi aXRyYXJ5Cj4gc2VydmVycy4KPiAKPiBJZiB3ZSBkbyBhdXRoZW50aWNhdGVkIHRpbWUgc3luY2hy b25pemF0aW9uLCB3ZSBzaW1wbHkgY2FuIG5vdCByZWx5IG9uCj4gdGhlIGN1cnJlbnQgdGltZSBp biBhbnkgd2F5LiBBbnkgYXV0b21hdGljIGFwcHJvYWNoIHRvIGNpcmN1bXZlbnQgdGhpcwo+IHBy b2JsZW0sIGZvciBleGFtcGxlIGJ5IHVzaW5nIGFub3RoZXIgc2VjdXJlIGNoYW5uZWwgZm9yIGFu IGluaXRpYWwgdGltZQo+IHN5bmNocm9uaXphdGlvbiwgd2lsbCBhZ2FpbiBoYXZlIHRvIHVzZSBj cnlwdG9ncmFwaHkgd2l0aG91dCBhIGtub3duCj4gdGltZSBhbmQgdGh1cyBoYXZlIHRoZSBzYW1l IHByb2JsZW0uCj4gCj4gUmVnYXJkcywKPiBTdGVwaGVuCj4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18KPiBudHB3ZyBtYWlsaW5nIGxpc3QKPiBudHB3Z0Bs aXN0cy5udHAub3JnIAo+IGh0dHA6Ly9saXN0cy5udHAub3JnL2xpc3RpbmZvL250cHdnIAoKCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCm50cHdnIG1haWxp bmcgbGlzdApudHB3Z0BsaXN0cy5udHAub3JnCmh0dHA6Ly9saXN0cy5udHAub3JnL2xpc3RpbmZv L250cHdn From ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Wed Aug 28 07:06:00 2013 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 D5ACC21F9CA6 for ; Wed, 28 Aug 2013 07:05:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.599 X-Spam-Level: X-Spam-Status: No, score=-104.599 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TJ-fqC1kRPAe for ; Wed, 28 Aug 2013 07:05:40 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [IPv6:2001:4f8:fff7:1::7]) by ietfa.amsl.com (Postfix) with ESMTP id 1975621F9C7E for ; Wed, 28 Aug 2013 07:05:39 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id 7D21F86D768 for ; Wed, 28 Aug 2013 14:05:39 +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 8C6A086D33D for ; Wed, 28 Aug 2013 14:05:23 +0000 (UTC) Received: from smtp90.ord1c.emailsrvr.com ([108.166.43.90]) by mail1.ntp.org with esmtps (TLSv1:AES256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1VEgN6-000BUc-R8 for ntpwg@lists.ntp.org; Wed, 28 Aug 2013 14:05:23 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp4.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id AD13814014F for ; Wed, 28 Aug 2013 10:05:19 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp4.relay.ord1c.emailsrvr.com (Authenticated sender: odonoghue-AT-isoc.org) with ESMTPSA id 6B74D1401A1 for ; Wed, 28 Aug 2013 10:05:19 -0400 (EDT) Message-ID: <521E039E.7090402@isoc.org> Date: Wed, 28 Aug 2013 10:05:18 -0400 From: Karen O'Donoghue Organization: ISOC User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: NTP Working Group X-SA-Exim-Connect-IP: 108.166.43.90 X-SA-Exim-Rcpt-To: ntpwg@lists.ntp.org X-SA-Exim-Mail-From: odonoghue@isoc.org X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) Subject: [ntpwg] heads up on effort to define new dhcp option for ntp X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: odonoghue@isoc.org List-Id: IETF Working Group for Network Time Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Sender: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Folks, The dhc wg is looking to update the dhcp ntp option: Their proposed recharter https://datatracker.ietf.org/doc/charter-ietf-dhc/ includes the following item: - New NTP option to replace OPTION_NTP_SERVER (RFC 5908) I will suggest that this work item should be coordinated with the ntp wg. Those of you who are interested in this replacement should try to follow the work in the dhc working group (provided that the rechartering is approved). 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 Aug 29 07:01:57 2013 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 7F68121F9E63 for ; Thu, 29 Aug 2013 07:01:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.599 X-Spam-Level: X-Spam-Status: No, score=-104.599 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nAEDiomFZHst for ; Thu, 29 Aug 2013 07:01:52 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by ietfa.amsl.com (Postfix) with ESMTP id 8C93921F9A38 for ; Thu, 29 Aug 2013 07:01:49 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id 2012E86D763 for ; Thu, 29 Aug 2013 14:01:48 +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 9DDE886D33D for ; Thu, 29 Aug 2013 14:01:35 +0000 (UTC) Received: from uillean.fuaim.com ([206.197.161.140]) by mail1.ntp.org with esmtps (TLSv1:AES256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1VF2mz-000Nlo-9p for ntpwg@lists.ntp.org; Thu, 29 Aug 2013 14:01:35 +0000 Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id C3534880A9 for ; Thu, 29 Aug 2013 07:01:27 -0700 (PDT) Received: from 102527176.rudm1.ra.johnshopkins.edu (addr16212925014.ippl.jhmi.edu [162.129.250.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 8E4DF130003 for ; Thu, 29 Aug 2013 07:01:27 -0700 (PDT) Message-ID: <521F5437.7080203@innovationslab.net> Date: Thu, 29 Aug 2013 10:01:27 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: ntpwg@lists.ntp.org References: <521E039E.7090402@isoc.org> In-Reply-To: <521E039E.7090402@isoc.org> X-SA-Exim-Connect-IP: 206.197.161.140 X-SA-Exim-Rcpt-To: ntpwg@lists.ntp.org X-SA-Exim-Mail-From: brian@innovationslab.net X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) Subject: Re: [ntpwg] heads up on effort to define new dhcp option for ntp X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: IETF Working Group for Network Time Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Sender: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org I am curious about the current usage of RFC 5908. Can folks who have implemented RFC 5908 let me know? Or if you operate a network, if you use the option to distribute NTP information? You can send input to me directly if you wish it to remain private. Thanks! Brian On 8/28/13 10:05 AM, Karen O'Donoghue wrote: > Folks, > > The dhc wg is looking to update the dhcp ntp option: > > Their proposed recharter > https://datatracker.ietf.org/doc/charter-ietf-dhc/ > includes the following item: > > - New NTP option to replace OPTION_NTP_SERVER (RFC 5908) > > I will suggest that this work item should be coordinated with the ntp > wg. Those of you who are interested in this replacement should try to > follow the work in the dhc working group (provided that the rechartering > is approved). > > Regards, > Karen > > _______________________________________________ > ntpwg mailing list > ntpwg@lists.ntp.org > http://lists.ntp.org/listinfo/ntpwg _______________________________________________ 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 Aug 30 10:16:36 2013 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 89E6921F9E0D for ; Fri, 30 Aug 2013 10:16:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.656 X-Spam-Level: X-Spam-Status: No, score=-104.656 tagged_above=-999 required=5 tests=[AWL=1.943, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mqQw5Yzlu1QN for ; Fri, 30 Aug 2013 10:16:31 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [IPv6:2001:4f8:fff7:1::7]) by ietfa.amsl.com (Postfix) with ESMTP id 8290E21F9C8E for ; Fri, 30 Aug 2013 10:16:31 -0700 (PDT) Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id F311586DAD5 for ; Fri, 30 Aug 2013 17:16: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 F0B4186D33D for ; Fri, 30 Aug 2013 17:16:10 +0000 (UTC) Received: from uillean.fuaim.com ([206.197.161.140]) by mail1.ntp.org with esmtps (TLSv1:AES256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1VFSIp-000BCA-Ah for ntpwg@lists.ntp.org; Fri, 30 Aug 2013 17:16:10 +0000 Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id D4B68880D1 for ; Fri, 30 Aug 2013 10:16:01 -0700 (PDT) Received: from 102527176.rudm1.ra.johnshopkins.edu (addr16212925014.ippl.jhmi.edu [162.129.250.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 8CE4A130003 for ; Fri, 30 Aug 2013 10:16:01 -0700 (PDT) Message-ID: <5220D34E.4000505@innovationslab.net> Date: Fri, 30 Aug 2013 13:15:58 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: ntpwg@lists.ntp.org References: <20130830165300.16729.46895.idtracker@ietfa.amsl.com> In-Reply-To: <20130830165300.16729.46895.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20130830165300.16729.46895.idtracker@ietfa.amsl.com> X-SA-Exim-Connect-IP: 206.197.161.140 X-SA-Exim-Rcpt-To: ntpwg@lists.ntp.org X-SA-Exim-Mail-From: brian@innovationslab.net X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on mail1.ntp.org) Subject: [ntpwg] Fwd: WG Review: Dynamic Host Configuration (dhc) X-BeenThere: ntpwg@lists.ntp.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: IETF Working Group for Network Time Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Sender: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org Please note objective #2. Regards, Brian -------- Original Message -------- Subject: WG Review: Dynamic Host Configuration (dhc) Date: Fri, 30 Aug 2013 09:53:00 -0700 From: The IESG Reply-To: ietf@ietf.org To: IETF-Announce CC: dhc WG The Dynamic Host Configuration (dhc) working group in the Internet Area of the IETF is undergoing rechartering. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg at ietf.org) by 2013-09-09. Dynamic Host Configuration (dhc) ------------------------------------------------ Current Status: Active WG Chairs: Bernie Volz Tomek Mrugalski Assigned Area Director: Ted Lemon Mailing list Address: dhcwg@ietf.org To Subscribe: http://www.ietf.org/mailman/listinfo/dhcwg Archive: http://www.ietf.org/mail-archive/web/dhcwg/ Charter: Proposed Updated DHC WG Charter (August 26, 2013) ------------------------------------------------- The Dynamic Host Configuration working group (DHC WG) has developed DHCP for automated allocation, configuration and management of IP addresses and TCP/IP protocol stack parameters. DHCPv4 is currently a Draft Standard and is documented in RFC 2131 and RFC 2132. DHCPv6 is currently a Proposed Standard and is documented in RFC 3315. Subsequent RFCs document additional options and other enhancements to the specifications. The DHC WG is responsible for defining DHCP protocol extensions. Definitions of new DHCP options that are delivered using standard mechanisms with documented semantics are not considered a protocol extension and thus are outside of scope for the DHC WG. Such options should be defined within their respective WGs and reviewed by the DHCP Directorate. However, if such options require protocol extensions or new semantics, the protocol extension work must be done in the DHC WG. The DHC WG has the following main objectives: 1. Develop extensions to the DHCPv6 infrastructure as required to meet new applications and deployments of DHCP. The topics currently in development are: - DHCPv6 Failover, High Availability and Load Balancing - Extend DHCPv6 to work with multiple provisioning domains - DHCP provisioning of IPv4 clients over IPv6 networks - SOLMAXRT counter update - Container option - Access Network Identifier - DNS registration for SLAAC Additional topics may only be added with approval from the responsible Area Director or by re-chartering. 2. Develop a replacement for OPTION_NTP_SERVER (RFC 5908). The DHC working group will develop this option, taking input from the NTP working group during the development process. Last call on this option will be done in the DHC working group. 3. Specify guidelines for creating new DHCPv6 options. 4. Develop documents that help explain operational considerations for the wider community. 5. Issue updated versions of the DHCP base specifications-- RFC 3315 (DHCPv6), RFC 3633 (DHCPv6 Prefix Delegation) and RFC 3736 (Stateless DHCPv6) so as to fix errata and bring the documents to the point where they can advance along the IETF Standards Track. 6. In the process of updating the DHCP base specifications, in cases where time is of the essence, issue corrections and clarifications of the specifications in order to quickly address interoperability problems. 7. Write analyses and interoperability reports on existing DHC documents, including base specs. 8. When serious interoperability problems are found in other DHCP specifications, issue updated versions of those problems to address the interoperability problems. Milestones: Done - WG Last Call on DHCP Options for Internet Storage Name Service (draft-ietf-dhc-isnsoption-03.txt) Done - WG Last Call on Load Balancing for DHCPv6 (draft-ietf-dhc-dhcpv6-loadb-02.txt) Done - WG Last Call on Time Configuration Options for DHCPv6 (draft-ietf-dhc-dhcpv6-opt-timeconfig-01.txt) Done - WG Last Call on IPv6 Prefix Options for DHCPv6 (draft-troan-dhcpv6-opt-prefix-delegation-02.txt) Done - WG Last Call on DNS Configuration options for DHCPv6 (draft-ietf-dhc-dhcpv6-opt-dnsconfig-01.txt) Done - WG Last Call on NIS Configuration Options for DHCPv6 (draft-ietf-dhc-dhcpv6-opt-nisconfig-01.txt) Done - Resubmit draft-ietf-dhc-dhcpv6-28.txt to IESG Done - Identify DHCPv4 authentication design team Done - Identify DHCPv4 specification review design team Done - Identify DHCPv4 relay agent message authentication design team Done - Submit DHCP Options for Internet Storage Name Service to IESG (draft-ietf-dhc-isnsoption) Done - Submit DNS Configuration options for DHCPv6 to IESG (draft-ietf-dhc-dhcpv6-opt-dnsconfig) Done - Submit NIS Configuratio Options for DHCPv6 to IESG (draft-ietf-dhc-dhcpv6-opt-nisconfig) Done - Submit IPv6 Prefix Options for DHCPv6 to IESG (draft-troan-dhcpv6-opt-prefix-delegation) Done - Submit 'Detection of Network Attachment (DNA) in IPv4' to IESG (draft-ietf-dhc-dna-ipv4) Done - Resolve IPR issues around 'Rapid Commit Option for DHCPv4' Done - Publish report on dual-stack issues in DHCP (draft-ietf-dhc-dual-stack) Done - Publish report on requirements for renumbering using stateless DHCPv6 (draft-ietf-dhc-stateless-dhcpv6-renumbering) Done - Submit 'Lifetime Option for DHCPv6' to IESG (draft-ietf-dhc-lifetime) Done - Submit 'Rapid Commit Option for DHCPv4' to IESG (draft-ietf-dhc-rapid-commit-opt) Done - Submit DDNS/DHCP documents to IESG Done - Submit 'Node-Specific Client Identifiers for DHCPv4' to IESG (draft-ietf-dhc-3315id-for-v4) Done - WG last call for 'Subnet Allocation Option' Done - WG last call on 'Virtual Subnet Selection Option' Oct 2007 - Submit 'Subnet Allocation Option' (draft-ietf-dhc-subnet-alloc-04) to IESG for Proposed Standard Nov 2007 - WG last call on 'Guidelines for Creating New DHCP Options' (draft-ietf-dhc-option-guidelines) Nov 2007 - Submit 'Virtual Subnet Selection Option', (draft-ietf-dhc-vpn-option) and (draft-ietf-dhc-agent-vpn-id) to IESG for Proposed Standard Dec 2007 - WG last call for 'Domain Suffix Option for DHCPv6' (draft-ietf-dhc-dhcpv6-opt-dnsdomain) Jan 2008 - Submit 'Domain Suffix Option for DHCPv6' (draft-ietf-dhc-dhcpv6-opt-dnsdomain) to IESG for Proposed Standard Jan 2008 - Submit 'Guidelines for Creating New DHCP Options' (draft-ietf-dhc-option-guidelines) to IESG for Best Current Practice Jan 2008 - Develop plan for advancing DHCPv4 and DHCPv6 plan to include completion of DHCPv4 specification review report, 'Implementation Issues with RFC 2131' (draft-ietf-dhc-implementation) for Informational Feb 2008 - WG last call for 'Status of Reclassifying DHCPv4 Options' (draft-ietf-dhc-status-3942) Feb 2008 - WG last call for 'Dual-stack clients and merging of data from DHCPv4 and DHCPv6' (draft-ietf-dhc-dual-stack-merge); waiting for more experience with IPv6 deployment Feb 2008 - WG last call for 'Rebind Capability in DHCPv6 Reconfigure Messages' (draft-ietf-dhc-dhcpv6-reconfigure-rebind) Mar 2008 - Submit 'Status of Reclassifying DHCPv4 Options' (draft-ietf-dhc-status-3942) to IESG for Informational Apr 2008 - 2nd WG last call for 'DHCP Relay Agent Assignment Notification Option (draft-ietf-dhc-dhcpv6-agentopt-delegate) and 'DHCPv6 Server Reply Sequence Number Option' (draft-ietf-dhc-dhcpv6-srsn-option) May 2008 - Submit 'Rebind Capability in DHCPv6 Reconfigure Messages' (draft-ietf-dhc-dhcpv6-reconfigure-rebind) to IESG for Proposed Standard Jun 2008 - WG last call on 'Layer 2 Relay Agent Behaviour' (draft-ietf-dhc-layer2-relay-agent) Jul 2008 - Submit 'Layer 2 Relay Agent Behaviour' to IESG (draft-ietf-dhc-layer2-relay-agent) for Informational Jul 2008 - Submit 'DHCP Relay Agent Assignment Notification Option' (draft-ietf-dhc-dhcpv6-agentopt-delegate) and 'DHCPv6 Server Reply Sequence Number Option' (draft-ietf-dhc-dhcpv6-srsn-option) to IESG for Proposed Standard Jul 2008 - Recharter, if needed _______________________________________________ ntpwg mailing list ntpwg@lists.ntp.org http://lists.ntp.org/listinfo/ntpwg