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

dieter.sibold@ptb.de Thu, 24 April 2014 16:23 UTC

Return-Path: <dieter.sibold@ptb.de>
X-Original-To: tictoc@ietfa.amsl.com
Delivered-To: tictoc@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CC2C1A0395 for <tictoc@ietfa.amsl.com>; Thu, 24 Apr 2014 09:23:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.821
X-Spam-Level:
X-Spam-Status: No, score=-1.821 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.272] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z1ncXnfXj6nb for <tictoc@ietfa.amsl.com>; Thu, 24 Apr 2014 09:23:37 -0700 (PDT)
Received: from mx1.bs.ptb.de (mx1.bs.ptb.de [192.53.103.106]) by ietfa.amsl.com (Postfix) with ESMTP id 3F71D1A03BA for <tictoc@ietf.org>; Thu, 24 Apr 2014 09:23:37 -0700 (PDT)
Received: from mx1.bs.ptb.de (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 9D732D193C3; Thu, 24 Apr 2014 18:23:30 +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 80830D191EB; Thu, 24 Apr 2014 18:23:30 +0200 (CEST)
In-Reply-To: <74470498B659FA4687F0B0018C19A89C01D4397649E9@IL-MB01.marvell.com>
References: <74470498B659FA4687F0B0018C19A89C01D4397649E9@IL-MB01.marvell.com>
To: Tal Mizrahi <talmi@marvell.com>
MIME-Version: 1.0
X-KeepSent: 115648C5:E137AD16-C1257CC4:0058221F; type=4; name=$KeepSent
X-Mailer: IBM Notes Release 9.0.1 October 14, 2013
Message-ID: <OF115648C5.E137AD16-ONC1257CC4.0058221F-C1257CC4.005A0A44@ptb.de>
From: dieter.sibold@ptb.de
Date: Thu, 24 Apr 2014 18:23:28 +0200
X-MIMETrack: S/MIME Sign by Notes Client on Dieter Sibold/PTB(Release 9.0.1|October 14, 2013) at 24.04.2014 18:23:28, Serialize by Notes Client on Dieter Sibold/PTB(Release 9.0.1|October 14, 2013) at 24.04.2014 18:23:28, Serialize complete at 24.04.2014 18:23:28, Itemize by Notes Client on Dieter Sibold/PTB(Release 9.0.1|October 14, 2013) at 24.04.2014 18:23:29, S/MIME Sign complete at 24.04.2014 18:23:29, Serialize by Router on ROSE/PTB(Release 9.0.1HF198 | January 23, 2014) at 04/24/2014 18:23:30, Serialize complete at 04/24/2014 18:23:30
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary=-------z45660_boundary_sign
Archived-At: http://mailarchive.ietf.org/arch/msg/tictoc/vqzf9fEWYf5F2KkKu81RQn3zKRk
Cc: tictoc@ietf.org
Subject: Re: [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: Thu, 24 Apr 2014 16:23:41 -0000

Hello Tal,

I have one comment regarding Sec. 5.1.3.

This section requires that the master MUST authenticate each client. I 
think that this requirement should be a MAY! In the case of a public time 
service there is no need for the master to authenticate its slaves. The 
spoofing attack described in the second example of 3.2.2 can be mitigated 
by other means such as the introduction of a nonce in a time request or 
delay_req message. 

I agree that in the case of authorization of the slave authentication is 
also necessary. 


Greetings
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:    Tal Mizrahi <talmi@marvell.com>;
An:     "odonoghue@isoc.org"; <odonoghue@isoc.org>;, "Yaakov Stein 
(yaakov_s@rad.com)"; <yaakov_s@rad.com>;, "tictoc@ietf.org"; 
<tictoc@ietf.org>;
Kopie:  "Shawn M Emery \(shawn.emery@oracle.com\)"; 
<shawn.emery@oracle.com>;
Datum:  23.04.2014 14:40
Betreff:        [TICTOC] Updated 
draft-ietf-tictoc-security-requirements-07
Gesendet von:   "TICTOC" <tictoc-bounces@ietf.org>;



Hi,
 
I have posted an updated draft.
http://tools.ietf.org/html/draft-ietf-tictoc-security-requirements-07
 
 
The most notable changes in this draft:
1.       I updated the draft to address comments from Shawn, the appointed 
secdir reviewer:
http://www.ietf.org/mail-archive/web/secdir/current/msg04315.html
2.       I updated the draft to address comments from Russell Smiley: 
http://www.ietf.org/mail-archive/web/tictoc/current/msg01387.html
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.
 
Thanks,
Tal.
 _______________________________________________
TICTOC mailing list
TICTOC@ietf.org
https://www.ietf.org/mailman/listinfo/tictoc