[TICTOC] Updated draft-ietf-tictoc-security-requirements-07

Tal Mizrahi <talmi@marvell.com> Wed, 23 April 2014 12:40 UTC

Return-Path: <talmi@marvell.com>
X-Original-To: tictoc@ietfa.amsl.com
Delivered-To: tictoc@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 3F4DC1A0357 for <tictoc@ietfa.amsl.com>; Wed, 23 Apr 2014 05:40:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.266
X-Spam-Status: No, score=-2.266 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id GT0hS_C_iDlK for <tictoc@ietfa.amsl.com>; Wed, 23 Apr 2014 05:40:38 -0700 (PDT)
Received: from mx0b-0016f401.pphosted.com (mx0b-0016f401.pphosted.com []) by ietfa.amsl.com (Postfix) with ESMTP id BC7B01A02C5 for <tictoc@ietf.org>; Wed, 23 Apr 2014 05:40:38 -0700 (PDT)
Received: from pps.filterd (m0045851.ppops.net []) by mx0b-0016f401.pphosted.com (8.14.5/8.14.5) with SMTP id s3NCe1YQ027265; Wed, 23 Apr 2014 05:40:01 -0700
Received: from sc-owa.marvell.com ([]) by mx0b-0016f401.pphosted.com with ESMTP id 1ke29bhyhn-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 23 Apr 2014 05:40:00 -0700
Received: from YK-HUB01.marvell.com ( by SC-OWA.marvell.com ( with Microsoft SMTP Server (TLS) id 8.3.327.1; Wed, 23 Apr 2014 05:39:58 -0700
Received: from IL-MB01.marvell.com ([]) by YK-HUB01.marvell.com ([]) with mapi; Wed, 23 Apr 2014 15:39:54 +0300
From: Tal Mizrahi <talmi@marvell.com>
To: "odonoghue@isoc.org" <odonoghue@isoc.org>, "Yaakov Stein (yaakov_s@rad.com)" <yaakov_s@rad.com>, "tictoc@ietf.org" <tictoc@ietf.org>
Date: Wed, 23 Apr 2014 15:39:53 +0300
Thread-Topic: Updated draft-ietf-tictoc-security-requirements-07
Thread-Index: Ac9e8PH6FTW5bIGHTPSgv/bSNdGL/g==
Message-ID: <74470498B659FA4687F0B0018C19A89C01D4397649E9@IL-MB01.marvell.com>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_74470498B659FA4687F0B0018C19A89C01D4397649E9ILMB01marve_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.96, 1.0.14, 0.0.0000 definitions=2014-04-23_04:2014-04-23, 2014-04-23, 1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1404230193
Archived-At: http://mailarchive.ietf.org/arch/msg/tictoc/0VN98tEYFYdyllwV-4XF0cNcwGs
Cc: "Shawn M Emery \(shawn.emery@oracle.com\)" <shawn.emery@oracle.com>
Subject: [TICTOC] Updated draft-ietf-tictoc-security-requirements-07
X-BeenThere: tictoc@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Timing over IP Connection and Transfer of Clock BOF <tictoc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tictoc>, <mailto:tictoc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tictoc/>
List-Post: <mailto:tictoc@ietf.org>
List-Help: <mailto:tictoc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tictoc>, <mailto:tictoc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 23 Apr 2014 12:40:41 -0000


I have posted an updated draft.

The most notable changes in this draft:

1.       I updated the draft to address comments from Shawn, the appointed secdir reviewer:

2.       I updated the draft to address comments from Russell Smiley:
This includes:
- In section 5.1.3 and 5.1.4 we decoupled the authentication and authorization requirements. The authentication requirement level was changed to 'MUST' following the good observation made by Russell: "Absence of authentication of slaves may enable MITM attacks delaying delay_req packets and thereby distorting the delay_req packet arrival times and subsequent departure of delay_resp. The resulting asymmetry could distort the subsequent slave clock offset calculations."
- The authorization requirement remains 'MAY' for sections 5.1.3 and 5.1.4.

3.       The requirement level of section 5.8 was changed to 'MUST'. The background is the insight that MITM attacks (sections 3.2.5, 3.2.6) have the same impact and level of difficulty to implement as manipulation attacks (section 3.2.1). Hence, a similar requirement level is called for in the two cases.
Section 5.8 also clarifies that: "While the security mechanism should support the ability to detect delay attacks, it is noted that in some networks it is not possible to provide the redundancy needed for such a detection mechanism."

4.       Section 5.2: merged the two sub-requirements to a single requirement for integrity protection. The previous phrasing called for hop-by-hop integrity protection as a MUST and end-to-end as a SHOULD, but some of the feedback we received was that in some scenarios or network topologies an end-to-end may provide a higher level of security. The current phrasing just presents the tradeoff between peer-to-peer and end-to-end.

Please let me know if there are any comments.