From talmi@marvell.com Mon Sep 3 07:03:42 2012 Return-Path: X-Original-To: tictoc@ietfa.amsl.com Delivered-To: tictoc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA1F521F861C for ; Mon, 3 Sep 2012 07:03:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[AWL=-1.279, BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DHeFGbu96O-T for ; Mon, 3 Sep 2012 07:03:40 -0700 (PDT) Received: from galiil.marvell.com (galiil.marvell.com [199.203.130.254]) by ietfa.amsl.com (Postfix) with ESMTP id 1EAC421F8599 for ; Mon, 3 Sep 2012 07:03:40 -0700 (PDT) From: Tal Mizrahi To: "tictoc@ietf.org" Date: Mon, 3 Sep 2012 17:03:35 +0300 Thread-Topic: draft-ietf-tictoc-security-requirements - Proventication Thread-Index: Ac2J3DVybLc3kdEiTSuGMTmFzlwsgw== Message-ID: <74470498B659FA4687F0B0018C19A89C01A0F8A52810@IL-MB01.marvell.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_74470498B659FA4687F0B0018C19A89C01A0F8A52810ILMB01marve_" MIME-Version: 1.0 Subject: [TICTOC] draft-ietf-tictoc-security-requirements - Proventication X-BeenThere: tictoc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Timing over IP Connection and Transfer of Clock BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2012 14:03:42 -0000 --_000_74470498B659FA4687F0B0018C19A89C01A0F8A52810ILMB01marve_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, One of the main comments from draft 02 was to rephrase the proventication s= ection. I am suggesting the phrasing below. The word "proventication" will appear o= nly once in the document (see the last sentence of the paragraph below). If you have any comments, I will appreciate if you can send them this week. 4.1.2. Recursive Authentication of Masters (Chain of Trust) Requirement The security mechanism MUST support recursive authentication of the master,= to be used in cases where end-to-end authentication is not possible. Discussion Clocks authenticate masters in order to ensure the authenticity of the time= source. In some cases a slave is connected to an intermediate master, that is not t= he primary time source. For example, in PTP a slave can be connected to a B= oundary Clock (BC), which in turn is connected to a grandmaster. A similar = example in NTP is when a client is connected to a stratum 2 server, which i= s connected to a stratum 1 server. In both the PTP and the NTP cases, the s= lave authenticates the intermediate master, and the intermediate master aut= henticates the primary master. This inductive authentication process is ref= erred to in [AutoKey] as proventication. Tal. --_000_74470498B659FA4687F0B0018C19A89C01A0F8A52810ILMB01marve_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

One of the= main comments from draft 02 was to rephrase the proventication section.

I am suggesting the phrasing below. The wo= rd “proventication” will appear only once in the document (see = the last sentence of the paragraph below).

If you have any comments, I will appreciate if you can send them this we= ek.

 

 

4.1.2. Recursive Authentica= tion of Masters (Chain of Trust)

Require= ment

The security mechanism MUST support= recursive authentication of the master, to be used in cases where end-to-e= nd authentication is not possible.

Discu= ssion

Clocks authenticate masters in ord= er to ensure the authenticity of the time source.

In some cases a slave is connected to an intermediate master, = that is not the primary time source. For example, in PTP a slave can be con= nected to a Boundary Clock (BC), which in turn is connected to a grandmaste= r. A similar example in NTP is when a client is connected to a stratum 2 se= rver, which is connected to a stratum 1 server. In both the PTP and the NTP= cases, the slave authenticates the intermediate master, and the intermedia= te master authenticates the primary master. This inductive authentication p= rocess is referred to in [AutoKey] as proventication.

 

Tal.

 

= --_000_74470498B659FA4687F0B0018C19A89C01A0F8A52810ILMB01marve_-- From internet-drafts@ietf.org Fri Sep 14 06:51:54 2012 Return-Path: X-Original-To: tictoc@ietfa.amsl.com Delivered-To: tictoc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC06121F851B; Fri, 14 Sep 2012 06:51:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.333 X-Spam-Level: X-Spam-Status: No, score=-102.333 tagged_above=-999 required=5 tests=[AWL=0.266, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uz0eTye7vIPS; Fri, 14 Sep 2012 06:51:54 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CEE621F84F5; Fri, 14 Sep 2012 06:51:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120914135154.21574.7671.idtracker@ietfa.amsl.com> Date: Fri, 14 Sep 2012 06:51:54 -0700 Cc: tictoc@ietf.org Subject: [TICTOC] I-D Action: draft-ietf-tictoc-security-requirements-03.txt X-BeenThere: tictoc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Timing over IP Connection and Transfer of Clock BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2012 13:51:54 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Timing over IP Connection and Transfer of= Clock Working Group of the IETF. Title : TICTOC Security Requirements Author(s) : Tal Mizrahi Filename : draft-ietf-tictoc-security-requirements-03.txt Pages : 24 Date : 2012-09-14 Abstract: As time synchronization protocols are becoming increasingly common and widely deployed, concern about their exposure to various security threats is increasing. This document defines a set of security requirements for time synchronization protocols, focusing on the Precision Time Protocol (PTP) and the Network Time Protocol (NTP). This document also discusses the security impacts of time synchronization protocol practices, the time synchronization performance implications of external security practices, the dependencies between other security services and time synchronization. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tictoc-security-requirements There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tictoc-security-requirements-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tictoc-security-requirements-= 03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From talmi@marvell.com Fri Sep 14 06:55:17 2012 Return-Path: X-Original-To: tictoc@ietfa.amsl.com Delivered-To: tictoc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAA3821F84F9 for ; Fri, 14 Sep 2012 06:55:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bckpM78qCR1m for ; Fri, 14 Sep 2012 06:55:17 -0700 (PDT) Received: from galiil.marvell.com (galiil.marvell.com [199.203.130.254]) by ietfa.amsl.com (Postfix) with ESMTP id 1438B21F84F6 for ; Fri, 14 Sep 2012 06:55:17 -0700 (PDT) From: Tal Mizrahi To: "tictoc@ietf.org" Date: Fri, 14 Sep 2012 16:55:12 +0300 Thread-Topic: TICTOC Security Requirements - Draft 03 Posted Thread-Index: Ac2SgEqbf4wCD1PoT3elNcCZOTJ5dA== Message-ID: <74470498B659FA4687F0B0018C19A89C01A0F8ACCB0F@IL-MB01.marvell.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_74470498B659FA4687F0B0018C19A89C01A0F8ACCB0FILMB01marve_" MIME-Version: 1.0 Subject: [TICTOC] TICTOC Security Requirements - Draft 03 Posted X-BeenThere: tictoc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Timing over IP Connection and Transfer of Clock BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2012 13:55:18 -0000 --_000_74470498B659FA4687F0B0018C19A89C01A0F8ACCB0FILMB01marve_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I have posted draft 03, which addresses all the comments WRT draft 02. http://tools.ietf.org/html/draft-ietf-tictoc-security-requirements-03 Regards, Tal. --_000_74470498B659FA4687F0B0018C19A89C01A0F8ACCB0FILMB01marve_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I have pos= ted draft 03, which addresses all the comments WRT draft 02.

=

http://tools.ietf.org/html/draft-ietf-tictoc-se= curity-requirements-03

 

Regards,

Tal.

 

= --_000_74470498B659FA4687F0B0018C19A89C01A0F8ACCB0FILMB01marve_-- From ldg004@earthlink.net Thu Sep 27 17:26:50 2012 Return-Path: X-Original-To: tictoc@ietfa.amsl.com Delivered-To: tictoc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57F0821F84FA for ; Thu, 27 Sep 2012 17:26:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xj9wfeaweQlr for ; Thu, 27 Sep 2012 17:26:49 -0700 (PDT) Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) by ietfa.amsl.com (Postfix) with ESMTP id A853721F84CE for ; Thu, 27 Sep 2012 17:26:49 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=AF/LOWeJqRuryoivfhOhefC/KWctMnTGwbEa738g3eHj4+SGxUF4ar+KL9Q8WIUQ; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:X-Forwarded-Message-Id:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [96.233.42.129] (helo=[192.168.1.3]) by elasmtp-junco.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1THOPo-0001uL-Nc for tictoc@ietf.org; Thu, 27 Sep 2012 20:26:48 -0400 Message-ID: <5064EEAB.2030704@earthlink.net> Date: Thu, 27 Sep 2012 20:26:19 -0400 From: Dan Grossman User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: "tictoc@ietf.org" References: <5064C962.3070004@earthlink.net> In-Reply-To: <5064C962.3070004@earthlink.net> X-Forwarded-Message-Id: <5064C962.3070004@earthlink.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 5fd9b736a583489594f5150ab1c16ac0485087bba56e6009ace03cf1e9b5aaa0a651a7dcc2f66992350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 96.233.42.129 Subject: [TICTOC] Security Draft -03 X-BeenThere: tictoc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Timing over IP Connection and Transfer of Clock BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Sep 2012 00:26:50 -0000 Tal, Looks much better. Some specific suggestions: 3.1 There is a third category of attacker: one who attacks a clock device, rather than the protocol. I would think that this should be included for completeness, but taken out of scope. Thus: -- 3.1.3 Protocol vs Device Attackers MITM and Packet Injection attacks exploit vulnerabilities in time synchronization protocols and the underlying network(s) that support them. A separate category of attacks exploits vulnerabilities in devices; for example, by installing malware, obtaining credentials to reconfigure the device, or stealing encryption keys in order to enable insider attacks. Requirements for securing against device attacks are outside the scope of this memo, except to the extent that they enable Insider attacks. -- Alternatively, we could create a requirement later on that requires "good hygiene" to prevent these kinds of attacks. Global change: "attackee" to "victim" (or "intended victim"). "Attackee" doesn't seem to be in the dictionary. 4.1 Discussion, 4.1.1: clarification needed. Is the intent of 4.1 that authentication covers both identification AND authorization, or that is covers identification OR authorization? If the latter, does 4.1.1 imply that the slaves can authenticate the identity but not the authorization of the master? And if the former, the words are misleading. If what is intended is what I think is intended, then here are some improved words: " In the context of this document, authentication refers to both: o Identification: verifying the identity of the peer clock; and, " " 4.1.1 Authentication of Masters Requirement The security mechanism MUST support an authentication mechanism, allowing slave clocks to authenticate the identity and authorization of master clocks. " 4.2 change "WHO" to "which device" ("who" implies a person). 4.2.1.2 Change "It should be noted that this approach is more difficult to implement than the hop-by-hop approach, as it requires separate layers of protection for the correctionField and for the rest of the packet, using different cryptographic mechanisms and keys." to "It should be noted that this approach is more difficult to implement than the hop-by-hop approach, as it requires the correctionField to be protected separately from the other fields of the packet, possibly using different cryptographic mechanisms and keys." How much benefit would you get from using different mechanisms and keys? 4.5.1 Change "cryptographich" to "cryptographic" (typo) 4.5.3 Change "The association protocol MUST be invoked periodically, where each instance of the association protocol MUST produce a different session key." to "The association protocol MUST be periodically invoked to produce a fresh session key." While on this subject... shouldn't it be possible to revoke or force refresh session keys if a compromise is detected? 4.7 If traffic analysis attacks were a concern, there certainly are mechanisms (random padding of encrypted packets, random dummy packets) to protect against them. Is the point here that traffic analysis attacks are not a consideration? 6.3 Change "that are exposed to the security keys" to "that possess the security keys". 7 Change "Although this is a cardinal element in any security system, it is not a security requirement, and is thus not described here." to "Although this is an essential element of any security system, it is outside the scope of this document". Thanks much for the credit! Regards Dan Grossman