IETF Logo Mail Archive

[secdir] Review of draft-ietf-tictoc-security-requirements-05

Shawn M Emery <shawn.emery@oracle.com> Tue, 29 October 2013 07:17 UTC

Return-Path: <shawn.emery@oracle.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7C4811E815C; Tue, 29 Oct 2013 00:17:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.351
X-Spam-Level:
X-Spam-Status: No, score=-6.351 tagged_above=-999 required=5 tests=[AWL=0.248, 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 X5iDAWmUDlRm; Tue, 29 Oct 2013 00:17:20 -0700 (PDT)
Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 92D7621E809F; Tue, 29 Oct 2013 00:17:11 -0700 (PDT)
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r9T7H9q4016938 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 29 Oct 2013 07:17:10 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r9T7H8gT000125 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 Oct 2013 07:17:08 GMT
Received: from abhmt111.oracle.com (abhmt111.oracle.com [141.146.116.63]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r9T7H7bq000071; Tue, 29 Oct 2013 07:17:08 GMT
Received: from [10.159.89.115] (/10.159.89.115) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 29 Oct 2013 00:17:07 -0700
Message-ID: <526F612D.1020005@oracle.com>
Date: Tue, 29 Oct 2013 01:18:05 -0600
From: Shawn M Emery <shawn.emery@oracle.com>
User-Agent: Mozilla/5.0 (X11; SunOS i86pc; rv:17.0) Gecko/20130718 Thunderbird/17.0.6
MIME-Version: 1.0
To: secdir@ietf.org
References: <51CAA254.6040303@oracle.com>
In-Reply-To: <51CAA254.6040303@oracle.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Cc: draft-ietf-tictoc-security-requirements.all@tools.ietf.org, iesg@ietf.org
Subject: [secdir] Review of draft-ietf-tictoc-security-requirements-05
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 29 Oct 2013 07:17:28 -0000

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the IESG.
These comments were written primarily for the benefit of the security
area directors. Document editors and WG chairs should treat these
comments just like any other last call comments.

This internet-draft describes the threat analysis for time protocols, such as
Precision Time Protocol (PTP) and the Network Time Protocol (NTP).

The draft itself discusses security considerations.  I believe the draft adequately
covers the various threats and how to mitigate such attacks.  I just have a few
comments below:

In regards to this paragraph in section 5.1.3:
    Authentication of slaves prevents unauthorized clocks from receiving
    time services. Preventing the master from serving unauthorized clocks
    can help in mitigating DoS attacks against the master. Note that the
    authentication of slaves might put a higher load on the master than
    serving the unauthorized clock, and hence this requirement is a
    SHOULD.

I think that this requirement of whether to allow for unauthorized clocks
should be a MAY (as does the prior text in this section) and should state
that the decision to do this should be based on the environment in which
the master and slaves are deployed.

In regards to this paragraph in section 5.2.1:
    The requirement level of the first requirement is 'SHOULD' since in
    the presence of recursive authentication (Section 5.1.2.) this
    requirement may be redundant.

This should state that this is the "second requirement", not the "first requirement".

In section 5.5.1 what's the difference between a replay and playback attack?  If there
is such a difference then playback needs to be defined.

In section 5.8, interception attacks is never explicitly described.

I don't understand this sentence:

The erroneous time may expose cryptographic
    algorithms that rely on time to prevent replay attacks.

Does this mean to say "security protocols" instead of "cryptographic algorithms"?

General comments:

None.

Editorial comments:

s/if a slave is/if a slave/

s/(Section 3.2.4.
    )/(Section 3.2.4.)/

s/Additional measure/Additional measures/

Looks like this sentence was truncated:

    The requirements in this subsection address MITM attacks such as the
    3.2.1.).

s/necessarily possible/possible/

s/5.1. ,/Section 5.1.,/

s/in the literature/in literature/

s/in [1588IPsec] and [Tunnel]/[1588IPsec] and [Tunnel]/

Shawn.
--

v2.23.0 | Report a Bug | By Email