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 91E4F21F9619 for ; Thu, 25 Apr 2013 10:56:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.598 X-Spam-Level: X-Spam-Status: No, score=-1.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001] 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 Zf9gKOGX2EEZ for ; Thu, 25 Apr 2013 10:56:11 -0700 (PDT) Received: from mxout1.idt.com (mxout1.idt.com [157.165.5.25]) by ietfa.amsl.com (Postfix) with ESMTP id A73FC21F960C for ; Thu, 25 Apr 2013 10:56:11 -0700 (PDT) Received: from mail.idt.com (localhost [127.0.0.1]) by mxout1.idt.com (8.13.1/8.13.1) with ESMTP id r3PHuAel015279; Thu, 25 Apr 2013 10:56:10 -0700 Received: from corpml1.corp.idt.com (corpml1.corp.idt.com [157.165.140.20]) by mail.idt.com (8.13.8/8.13.8) with ESMTP id r3PHu81A014001; Thu, 25 Apr 2013 10:56:08 -0700 (PDT) Received: from corpmail2.na.ads.idt.com (localhost [127.0.0.1]) by corpml1.corp.idt.com (8.11.7p1+Sun/8.11.7) with ESMTP id r3PHtE612634; Thu, 25 Apr 2013 10:55:14 -0700 (PDT) Received: from CORPMAIL1.na.ads.idt.com ([fe80::f9ec:4643:471e:dd33]) by corpmail2.na.ads.idt.com ([fe80::7d1f:86ad:31c6:5aee%20]) with mapi id 14.02.0318.001; Thu, 25 Apr 2013 10:55:13 -0700 From: "Smiley, Russell" To: Tal Mizrahi , "tictoc@ietf.org" Thread-Topic: Updated TICTOC Security Requirements Thread-Index: Ac5BuiZMjCtSCoq1RjSqII8TtL5nOgAIazEQ Date: Thu, 25 Apr 2013 17:55:12 +0000 Message-ID: <3EB7D1CECF89334E9B5A0D6E60B9518F207EB050@corpmail1.na.ads.idt.com> References: <74470498B659FA4687F0B0018C19A89C01A0F9A356C3@IL-MB01.marvell.com> In-Reply-To: <74470498B659FA4687F0B0018C19A89C01A0F9A356C3@IL-MB01.marvell.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [157.165.140.139] Content-Type: multipart/related; boundary="_004_3EB7D1CECF89334E9B5A0D6E60B9518F207EB050corpmail1naadsi_"; type="multipart/alternative" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.43 Subject: Re: [TICTOC] Updated TICTOC Security Requirements 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: Thu, 25 Apr 2013 17:56:14 -0000 --_004_3EB7D1CECF89334E9B5A0D6E60B9518F207EB050corpmail1naadsi_ Content-Type: multipart/alternative; boundary="_000_3EB7D1CECF89334E9B5A0D6E60B9518F207EB050corpmail1naadsi_" --_000_3EB7D1CECF89334E9B5A0D6E60B9518F207EB050corpmail1naadsi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Tal, Here are some comments on your draft. In general I find your idea of a fram= ework for defining the necessary security support in timing protocols very = helpful. I hope it will be a useful basis for the IEEE 1588 working group b= eing convened when considering how to implement security functions in PTP. Section 5.1 [Comment] It would be good to have each requirement statement uniquely numb= ered to make it easy for implementors to reference the requirements directl= y. Section 5.1.3 [Comment] Not clear here, if authorization is implicitly included in the au= thentication requirement, or if it is implicitly excluded from the authenti= cation requirement and is not addressed in 5.1.3. "(Requirement Level) Its low impact, i.e., in the absence of this requireme= nt the protocol is only exposed to DoS" [Comment] Disagree. Absence of authentication of slaves may enable MITM att= acks delaying delay_req packets and thereby distorting the delay_req packet= arrival times and subsequent departure of delay_resp. The resulting asymme= try could distort the subsequent slave clock offset calculations. Slaves don't necessarily require authorization though. "(Discussion)Slaves are authenticated by masters in order to verify that th= e slave is authorized to receive timing services from the master." [Comment] This conflation of authentication and authorization is not helpfu= l. Slaves could be authenticated to prevent MITM attacks against delay_req = packets without authorization. Authorization could be added for the purpose= of controlling master load and preventing DoS attacks as described in the = text. Suggest the following: [Modify 'authenticate' to 'authorize'] Requirement The security mechanism MAY provide a means for a master to authorize it= s slaves. [Add] Requirement The security mechanism MUST provide a means for a master to authenticat= e its slaves. Section 5.1.4 [Comment] Same motivation as 5.1.3 applies here. Suggest the same changes i= n terms of MAY/MUST for authorization and authentication respectively. Section 7.3 "The usage of intermediate nodes implies that if a security mechanism is de= ployed in the network, all intermediate nodes must possess the security key= " [Comment] This is not true in the BC case since a BC fully terminates the s= ync connection. A slave's master is just the next adjacent BC. In the BC ca= se the session key does not need to be shared across all nodes; each node c= an have a unique key. In the TC case the nodes must have a shared session k= ey, at least for modification of the correction field as discussed earlier. Hope this helps. Russell. Russell Smiley Principal Systems Engineer +1 613 592 0859 x1831 direct +1 613 322 9433 mobile [cid:image002.jpg@01CDC41A.21180AF0] Integrated Device Technology, Canada Inc. 603 March Rd, Ottawa, Ontario Canada K2K 2M5 www.IDT.com NASDAQ: IDTI CONFIDENTIAL COMMUNICATION: This email and any attachments thereto may cont= ain private and confidential material for the sole use of the intended reci= pient. Any review, copying, or distribution of this email (or any attachmen= ts thereto) by others is strictly prohibited. If you are not the intended r= ecipient, please contact the sender immediately and permanently delete the = original and any copies of this email and any attachments thereto. From: tictoc-bounces@ietf.org [mailto:tictoc-bounces@ietf.org] On Behalf Of= Tal Mizrahi Sent: Thursday, April 25, 2013 9:50 AM To: tictoc@ietf.org; odonoghue@isoc.org; Yaakov Stein (yaakov_s@rad.com) Subject: [TICTOC] Updated TICTOC Security Requirements Hi, Following the comments received on the WGLC I updated the draft - mostly mi= nor editorial updates. The most notable changes compared to draft 04: 1. I added some text in the introduction about the target audience of= the document. 2. I changed "time synchronization protocols" to "time protocols", as= this seems to be the common grounds of NTP and PTP, both of which end with= a TP (Time Protocol). Seems like a fair compromise between Yaakov's sugges= tion and Kevin's (http://www.ietf.org/mail-archive/web/tictoc/current/msg01= 382.html). The current draft can be found in: http://tools.ietf.org/html/draft-ietf-tictoc-security-requirements-05 Thanks, Tal. --_000_3EB7D1CECF89334E9B5A0D6E60B9518F207EB050corpmail1naadsi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Tal,=

 

Here are some comments= on your draft. In general I find your idea of a framework for defining the= necessary security support in timing protocols very helpful. I hope it wil= l be a useful basis for the IEEE 1588 working group being convened when considering how to implement security fu= nctions in PTP.

 

Section 5.1

[Comment] It would be good to have each requirement statement uniquely= numbered to make it easy for implementors to reference the requirements di= rectly.

 

 

Section 5.1.3

[Comment] Not clear here, if authorization is implicitly included in t= he authentication requirement, or if it is implicitly excluded from the aut= hentication requirement and is not addressed in 5.1.3.

 

"(Requirement Level) Its low impact, i.e., in the absence of thi= s requirement the protocol is only exposed to DoS"

 

[Comment] Disagree. Absence of authentication of slaves may enable MIT= M attacks delaying delay_req packets and thereby distorting the delay_req p= acket arrival times and subsequent departure of delay_resp. The resulting asymmetry could distort the subsequent slave = clock offset calculations.

Slaves don't necessarily require authorization though.

 

"(Discussion)Slaves are authenticated by masters in order to ver= ify that the slave is authorized to receive timing services from the master= ."

 

[Comment] This conflation of authentication and authorization is not h= elpful. Slaves could be authenticated to prevent MITM attacks against delay= _req packets without authorization. Authorization could be added for the purpose of controlling master load and preventing D= oS attacks as described in the text.

 

Suggest the following:

 

[Modify 'authenticate' to 'authorize']   

    Requirement

    The security mechanism MAY provide a means for a m= aster to authorize its slaves.

[Add]

    Requirement

    The security mechanism MUST provide a means for a = master to authenticate its slaves.

 

 

Section 5.1.4

[Comment] Same motivation as 5.1.3 applies here. Suggest the same chan= ges in terms of MAY/MUST for  authorization and authentication respect= ively.

 

 

Section 7.3

"The usage of intermediate nodes implies that if a security mecha= nism is deployed in the network, all intermediate nodes must possess the se= curity key"

 

[Comment] This is not true in the BC case since a BC fully terminates = the sync connection. A slave's master is just the next adjacent BC. In the = BC case the session key does not need to be shared across all nodes; each node can have a unique key. In the TC = case the nodes must have a shared session key, at least for modification of= the correction field as discussed earlier.

 

Hope this helps.<= /o:p>

 

Russell.

 

 

 

Russell Smiley

Principal Systems Engineer

+1 613 592 0859 x1831 direct

+1 613 322 9433 mobile

 

3D"cid:image002.jpg@01=

6= 03 March Rd, Ottawa, Ontario Canada K2K 2M5

w= ww.IDT.com NASDAQ: IDTI

<= o:p> 

CONFIDENTIAL COMMUNICATION: This email and any attachments thereto may = contain private and confidential material for the sole use of the intended = recipient. Any review, copying, or distribution of this email (or any attachments thereto) by others is strictly prohibited. If yo= u are not the intended recipient, please contact the sender immediately and= permanently delete the original and any copies of this email and any attac= hments thereto.

 

From: tictoc-b= ounces@ietf.org [mailto:tictoc-bounces@ietf.org] On Behalf Of Tal Mizrahi
Sent: Thursday, April 25, 2013 9:50 AM
To: tictoc@ietf.org; odonoghue@isoc.org; Yaakov Stein (yaakov_s@rad.= com)
Subject: [TICTOC] Updated TICTOC Security Requirements

 

Hi,

 

Following the comments received on the WGLC I update= d the draft – mostly minor editorial updates.

The most notable changes compared to draft 04:<= /o:p>

 

1.     &= nbsp; I added some text in the introduction about the tar= get audience of the document.

2.     &= nbsp; I changed “time synchronization protocolsR= 21; to “time protocols”, as this seems to be the common grounds= of NTP and PTP, both of which end with a TP (Time Protocol). Seems like a = fair compromise between Yaakov’s suggestion and Kevin’s (http://www.ietf.org/mail-archive/web/tictoc/current/msg01382.html)= .

 

The current draft can be found in:

http://tools.ietf.org/html/draft-ietf-tictoc-= security-requirements-05

 

Thanks,

Tal.

 

--_000_3EB7D1CECF89334E9B5A0D6E60B9518F207EB050corpmail1naadsi_-- --_004_3EB7D1CECF89334E9B5A0D6E60B9518F207EB050corpmail1naadsi_ Content-Type: image/jpeg; name="image001.jpg" Content-Description: image001.jpg Content-Disposition: inline; filename="image001.jpg"; size=1563; creation-date="Thu, 25 Apr 2013 17:55:12 GMT"; modification-date="Thu, 25 Apr 2013 17:55:12 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAoHBwgHBgoICAgLCgoLDhgQDg0NDh0VFhEYIx8lJCIf IiEmKzcvJik0KSEiMEExNDk7Pj4+JS5ESUM8SDc9Pjv/2wBDAQoLCw4NDhwQEBw7KCIoOzs7Ozs7 Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozv/wAARCAAeAE8DASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwDrPiH8 RE8JxrYWCJPqky7gG5WFezMO59B/k+YeH73XfHHjGysNR1m9kjmkLShZigCKCzAAYA6Y/GsPxLqU ur+JdRv5WLNNcPjPZQcKPwAFdJ8IAD8QICe1vKR+Qr3Y0I0KDklrYi92elTeK5bGF7C0tkia3lKR tnK7FOMEHnPvXS6JrMOs2nmoNkqcSR5+6f8ACvOb3m/uf+uz/wDoRrU8I3LW+vxID8s6lGHrxkfy rwyi3rvxX0fQNcudJubG9kmt2Cs0artOQDxk+9WfFPxJ0vwpqaafeWl3LI8IlDQhSMEkdyPSvH/i T/yUbVv+u0f/AKAla3xn/wCRwt/+vBP/AEJq9WOEpNw81/kK52kPxt8OPIFls9QiU/xGNTj8mrqX 8Y6O3hm58QWdx9ttLZNziH749iDjB9jXE6d8J9B1vwdY3cLT2l/cWqSecJCylyoPKntn0xXnfh6a TRfE8mj6kGNpdS/YdQhViAyltufqDyD/AI1Kw9Cpf2d7rdBdnpv/AAvDQP8AoHaj/wB8p/8AFVNa /GjQrq5SBNP1AM+cEqmOBn+97VwnxS8LaT4W1HT4NJheJJ4XZw0hbJBAHWuv8A/D7w7qfhXTNYur WRryVGLOJmAJ3MvTOOlOdLDRpKpZ2YXZ5d4t0mXRPFWo2EilQk7NHn+JGOVP5Guh+DwJ8fxEdraU n9K9S8d+AbTxlapIsgtdRgUiKfGQR/dYdx/KjTvAGnaHcx6jo8SW16tkbYgsTGzHGXPfPB+uaqWM hKhyvdqwW1OSuGDXUzDoZGP6mtnwfZtca4k2Pkt1LMfcjAH+fSrI8C3+Rm7t8dz8x/pXV6VpVvpF mLeDJJOXc9XPrXkDPn34k/8AJRtW/wCu0f8A6Ala3xn/AORwt/8ArwT/ANCauj8WfCfWNf8AFV7q 1tf2UcVw6sqSb9wwoHOB7Ve8e/DXVPFmuxahZ3tpDGlssRWbdnIJOeB05r24VoJ09dl/kI2ND8Va HofgPS5r/U7dPLso8xrIGkJ2jgKOc141pcVx4w+IUbxxENe35uHA58tN24k/QV1MPwM1kyDztWsE TuyI7H8iB/OvSPB/gXS/B8D/AGXdPdyjEt1IPmYegH8I9qydSlh1Jxd5MNzzz46f8hjSf+veT/0I V33wx/5J1pH/AFzf/wBDasr4jeANR8Y39lcWV3awLbRMjCbdkkkHjAPpW34b0DVNB8OaXpYvIN1o riYqpKvkkjGRnvWNSUZYWEb63/zDqf/Z --_004_3EB7D1CECF89334E9B5A0D6E60B9518F207EB050corpmail1naadsi_--