Re: [secdir] Secdir review of draft-ietf-karp-isis-analysis-04

"Takeshi Takahashi" <takeshi_takahashi@nict.go.jp> Tue, 07 July 2015 00:21 UTC

Return-Path: <takeshi_takahashi@nict.go.jp>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF6291A6FF8; Mon, 6 Jul 2015 17:21:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.598
X-Spam-Level:
X-Spam-Status: No, score=0.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
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 c2Cu1Gj5MDYO; Mon, 6 Jul 2015 17:21:26 -0700 (PDT)
Received: from ns1.nict.go.jp (ns1.nict.go.jp [IPv6:2001:df0:232:300::1]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 235471A6F03; Mon, 6 Jul 2015 17:21:26 -0700 (PDT)
Received: from gw1.nict.go.jp (gw1.nict.go.jp [133.243.18.250]) by ns1.nict.go.jp with ESMTP id t670LHMB050773; Tue, 7 Jul 2015 09:21:17 +0900 (JST)
Received: from TakeVaioVJP13 (vrrp.ssh.nict.go.jp [133.243.3.48] (may be forged)) by gw1.nict.go.jp with ESMTP id t670LGH4050768; Tue, 7 Jul 2015 09:21:17 +0900 (JST)
From: Takeshi Takahashi <takeshi_takahashi@nict.go.jp>
To: 'Uma Chunduri' <uma.chunduri@ericsson.com>, draft-ietf-karp-isis-analysis.all@tools.ietf.org
References: <006f01d0b595$baae8b20$300ba160$@nict.go.jp> <1B502206DFA0C544B7A60469152008633F749A8C@eusaamb105.ericsson.se>
In-Reply-To: <1B502206DFA0C544B7A60469152008633F749A8C@eusaamb105.ericsson.se>
Date: Tue, 07 Jul 2015 09:21:20 +0900
Message-ID: <024901d0b84a$d9735790$8c5a06b0$@nict.go.jp>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 15.0
Thread-Index: AQHAav37aHmKEmJW9EJGsrkITV/1WgHulHjEneBKMJA=
Content-Language: ja
X-Virus-Scanned: clamav-milter 0.98.5 at zenith1
X-Virus-Status: Clean
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/ix7zasE1Ilf1FhD9DQeMbmeYax4>
Cc: karp-chairs@tools.ietf.org, iesg@ietf.org, secdir@ietf.org
Subject: Re: [secdir] Secdir review of draft-ietf-karp-isis-analysis-04
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
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: <https://mailarchive.ietf.org/arch/browse/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, 07 Jul 2015 00:21:28 -0000

Hi Uma,

The proposed sentence is fine to me, thank you for addressing my comments.

Regards,
Take



> -----Original Message-----
> From: Uma Chunduri [mailto:uma.chunduri@ericsson.com]
> Sent: Tuesday, July 7, 2015 4:56 AM
> To: Takeshi Takahashi; draft-ietf-karp-isis-analysis.all@tools.ietf.org
> Cc: iesg@ietf.org; secdir@ietf.org; karp-chairs@tools.ietf.org
> Subject: RE: Secdir review of draft-ietf-karp-isis-analysis-04
> 
> Hi Take,
> 
> Thanks for your  review and comments. Shall address both your comments in
the
> next update i.e., a. Ref. to 5310 in Section 4 b.  Shall recommend usage
of
> RFC 5310 instead of RFC 5304 (HMAC-MD5)
> 
> " In view of openly published attack vectors, as noted in Section 1 of
> [RFC5310] on HMAC-MD5 cryptographic authentication mechanism,
>    IS-IS deployments SHOULD use HMAC-SHA family [RFC5310]  instead of
HMAC-MD5
> [RFC5304] for protecting IS-IS PDUs."
> 
> Please suggest if the above is sufficient to address #b (or happy to
consider
> better text).  Thx!
> 
> --
> Uma C.
> 
> -----Original Message-----
> From: Takeshi Takahashi [mailto:takeshi_takahashi@nict.go.jp]
> Sent: Friday, July 03, 2015 6:40 AM
> To: draft-ietf-karp-isis-analysis.all@tools.ietf.org
> Cc: iesg@ietf.org; secdir@ietf.org; karp-chairs@tools.ietf.org
> Subject: RE: Secdir review of draft-ietf-karp-isis-analysis-04
> 
> Let me add one more comment here.
> We could probably discourage the use of HMAC-MD5, and encourage the use of
> HMAC-SHA family instead.
> 
> Take
> 
> > -----Original Message-----
> > From: Takeshi Takahashi [mailto:takeshi_takahashi@nict.go.jp]
> > Sent: Friday, July 3, 2015 1:10 PM
> > To: 'draft-ietf-karp-isis-analysis.all@tools.ietf.org'
> > Cc: 'iesg@ietf.org'; 'secdir@ietf.org'; 'karp-chairs@tools.ietf.org'
> > Subject: Secdir review of draft-ietf-karp-isis-analysis-04
> >
> > Hello,
> >
> > 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 document is ready for publication.
> >
> > [summary of this document]
> >
> > This document analyzes the threats of IS-IS protocol.
> > It first summarizes the current state of the IS-IS protocol, with
> > special
> focus
> > on key usage and key management (in section 2), and then analyzes the
> security
> > gaps in order to identify security requirements (in section 3).
> >
> > In the summary of the current state of the protocol (section 2), it
> already
> > mentioned the threats of the protocol, i.e. replay attack and spoofing
> attack,
> > for each of the three message types of IS-IS protocol.
> > Section 3 summarizes, organizes, and develops the threat analysis and
> provides
> > candidate direction to cope with the threats by listing requirements
> > and
> by
> > listing related I-D works.
> >
> > [minor comment]
> >
> > As mentioned in the security consideration section, this draft does
> > not
> modify
> > any of the existing protocols.
> > It thus does not produce any new security concerns.
> > So, the security consideration section seems adequate.
> > The authors could consider citing RFC 5310 in Section 5, since I feel
> > like
> that
> > this draft does not discuss all the content of the consideration
> > section
> of
> > the rfc (it does discuss major parts of the section, though).
> >
> > Cheers,
> > Take
> >