From nobody Thu Feb 13 14:20:34 2014 Return-Path: X-Original-To: msec@ietfa.amsl.com Delivered-To: msec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A3BB1A0469 for ; Thu, 13 Feb 2014 14:20:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.049 X-Spam-Level: X-Spam-Status: No, score=-17.049 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_I_INVITATION=-2, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 KOqqSdWih7az for ; Thu, 13 Feb 2014 14:20:25 -0800 (PST) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 518841A03BF for ; Thu, 13 Feb 2014 14:20:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8173; q=dns/txt; s=iport; t=1392330024; x=1393539624; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=rtF0qpyWygbJ7aJPWrqW45u8okwnYKPuLFzLushgEYA=; b=EnDDeX0tp5OlqpPpGVq8hD3Wgb36zEMw7M6fqdtHPQ7EHEFPcIDjXGWP /JWG8jAvH6mgJdrjyjeO2QQbAo+8BaVbZIs7p+XU8rvhyX6JAHm3MMBZL F/ck6cubr5LN2tQuR+US9+JEpMzEmi4yzT0hTmaNRWBdCmn2cB7RIEvX2 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAONE/VKrRDoJ/2dsb2JhbABWA4MGOMAkgRsWdIIlAQEBAwEBAQEkEzQLBQcECxEEAQEBJwcnHwkIBhOHfQcBDcg+F44XEQECGyMQBwYLgxOBFASJSI5kgTKQcYNOgVA X-IronPort-AV: E=Sophos;i="4.95,841,1384300800"; d="scan'208";a="102407775" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-1.cisco.com with ESMTP; 13 Feb 2014 22:20:23 +0000 Received: from dhcp-128-107-147-105.cisco.com (dhcp-128-107-147-105.cisco.com [128.107.147.105]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s1DMKJbo000457 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 13 Feb 2014 22:20:23 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Brian Weis In-Reply-To: Date: Thu, 13 Feb 2014 14:20:19 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <7CD270C5-2E9F-45A5-B434-8A4EB6146C24@cisco.com> References: <3CB35FCD-F9EA-4361-B290-3CBBE087C3B8@cisco.com> <5C96E649-6CF5-450E-9787-2C51D76DF2A5@cisco.com> To: "Fries, Steffen" X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/msec/iQHdmHrJgaHL3SIg3cpLRfPQRek Cc: "msec@ietf.org" , Sean Turner , "draft-weis-gdoi-iec62351-9@tools.ietf.org" Subject: Re: [MSEC] Review comments, was RE: GDOI support for IEC 62351 X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 22:20:30 -0000 Hi Steffen, Many thanks for your comments on this draft. We have published a revised = draft that I believe addresses each of your comments below. Let us know if you have any further comments. Thanks, Brian On Aug 6, 2013, at 11:10 PM, "Fries, Steffen" = wrote: > Hi Brian, >=20 > While re-reading my message I realized that I was only focused on the = content review, not thinking about the embedding. The support IEC 62351 = in GDOI payloads really helps in securing GOOSE and SV. In IEC TC 57 WG = 15 we discussed different approaches of securing this type of = communication and the group-based approach based on GDOI was the one = that coped best with the requirements. Hence, having this draft ensures = the applicability within IEC 62351 by providing the required additional = payloads. > Sorry for not mentioning that in the first place. >=20 > Regards > Steffen >=20 > -----Original Message----- > From: msec-bounces@ietf.org [mailto:msec-bounces@ietf.org] On Behalf = Of Fries, Steffen > Sent: Dienstag, 6. August 2013 10:35 > To: Brian Weis; msec@ietf.org > Cc: draft-weis-gdoi-iec62351-9@tools.ietf.org; Sean Turner > Subject: [MSEC] Review comments, was RE: GDOI support for IEC 62351 >=20 > Hi Brian, >=20 > Thank you for compiling the draft. Meanwhile I had the chance to = review the current draft. Most of the comments I have are actually more = editorial nits than technical. >=20 > Title: IEC 62351 Security Protocol support for GDOI > - After reading the document I would propose to change the title into = "GDOI enhancements supporting IEC 62351 Security Mechanisms". The reason = is that the payloads enhancements are defined for GDOI and are applied = within IEC 62351. But maybe that is philosophical. >=20 > Section 1.Introduction (page 3) > - In the first paragraph I would suggest to add the following = sentence: > "The protection of the frames is defined within IEC 62351-6." >=20 > - Last paragraph (page 3): > /r "This document defines GDOI payloads to distribute policy and = keying > material for IEC 61850, and defines the necessary information to > ensure interoperability between IEC 61850 implementations." > /w "This document defines GDOI payloads to distribute policy and = keying > material to protect IEC 61850 data exchanges, and defines the = necessary information to > ensure interoperability between IEC 61850 implementations." >=20 > Section 1.1 (page 4) > - two abbreviations are missing: > - CK Current Key > - NK Next Key >=20 > Section 2 (page 5) > - I would suggest adding one sentence stating, which payloads are = being defined for IEC 61850 protection. All in all we have definitions = for ID, SA TEK, and the KD payloads. To be frank, I wasn't quite sure, = if it makes also sense to spent a subsection on the Security Association = Payload more or less just stating that it is always used with "SA = Attribute NP" set to 16 (SA TEK) as stated in the example in Appendix A.=20= >=20 > Section 2.2 (page 7) > - Bullet list below figure 4 > /r "OIDs defined in IEC 61850 declare the type of traffic to be = encrypted." > /w "OIDs defined in IEC 61850 declare the type of traffic to be = protected."=20 > The application of the key material is defined in IEC 61850-90-5 (and = will be included in IEC 62351-6)=20 > and may be used for integrity protection and/or confidentiality = protection. >=20 > Section 2.2.3 (page 9) > - There are two confidentiality algorithms defined. Both are AES-CBC = with different key length. > IEC 61850-90-5 specifies AES-GCM with the two stated key length. This = should be double checked. >=20 > Section 2.3 (page 10) > - There are two attributes for the TEK key:=20 > - TEK_INTEGRITY_KEY if the key is associated with an IEC 61850-90-5 = defined integrity algorithm=20 > - TEK_ALGORITHM_KEY if the key is associated with an IEC 61850-90-5 = defined confidentiality algorithm > I would suggest to rename the TEK_ALGORITHM_KEY to = TEK_CONFIDENTIALITY_KEY to have the same association. >=20 > Annex A (page 18) > - caption of figure states "Sample IEC-61850 SA Payload" -> should = this be enhanced to "Sample IEC-61850 SA and SA TEK Payload"? >=20 > Annex A (page 19) > - I calculated the KD Length of SPI=3D1 in the example to 62 = (TEK_INTEGRITY_KEY, TEK_ALGORITHM_KEY, and the header). Currently 30 is = stated. This should be verified. >=20 > Okay so far for the review. As I said, mostly editorial. >=20 > Regards > Steffen =20 >=20 > Steffen Fries > Siemens AG > Corporate Technology > CT RTC ITS > Otto-Hahn-Ring 6 > 81739 Muenchen, Germany > Tel: +49 89 636-53403 > Fax: +49 89 636-48000 > mailto:steffen.fries@siemens.com >=20 > Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Gerhard = Cromme; Managing Board: Joe Kaeser, Chairman, President and Chief = Executive Officer; Roland Busch, Brigitte Ederer, Klaus Helmrich, = Barbara Kux, Hermann Requardt, Siegfried Russwurm, Peter Y. Solmssen, = Michael Suess; Registered offices: Berlin and Munich, Germany; = Commercial registries: Berlin Charlottenburg, HRB 12300, Munich, HRB = 6684; WEEE-Reg.-No. DE 23691322=20 >=20 >=20 >=20 > -----Original Message----- > From: msec-bounces@ietf.org [mailto:msec-bounces@ietf.org] On Behalf = Of Brian Weis > Sent: Freitag, 2. August 2013 21:28 > To: msec@ietf.org > Cc: draft-weis-gdoi-iec62351-9@tools.ietf.org; Sean Turner > Subject: Re: [MSEC] GDOI support for IEC 62351 >=20 > Folks, >=20 > Sean had some good feedback, and there is a new version now: = . GDOI = implementers should note that both RFC 3547 and RFC 6407 relied upon the = ID Types defined in the IPsec DOI, which wasn't quite the right thing to = do. So please note that Section 4 (IANA Considerations) now adds a = registry of ID types for the GDOI DOI. This came about because this I-D = adds a new value. >=20 > The GDOI DOI list of ID Types is copy-and-paste from the IPsec DOI, = plus the new ID type added. So all of the old values are still valid, = they are just administratively defined in the GDOI IANA registry now = rather than the IPsec registry. This should not have a negative effect = on implementations but it's worth pointing out. >=20 > Comments on the Internet-Draft are still requested. >=20 > Thanks, > Brian=20 >=20 > On Jul 23, 2013, at 1:56 AM, Brian Weis wrote: >=20 >> Greetings, >>=20 >> The IEC 62351 power utility automation standards group has chosen to = use GDOI (RFC 6407) as their key management method to distribute group = keys. The keys protect multicast traffic streams sent by devices = monitoring the power grid, and other multicast streams as well. To do = this they require some new GDOI payloads. This message is an invitation = to review and comment on the new definitions, which are defined in = . Since the = MSEC WG is not currently active, we hope to progress the draft as an = individual submission soon and would appreciate any feedback. If you = have comments, please post them to the MSEC list (msec@ietf.org) or send = them to the authors (draft-weis-gdoi-iec62351-9@tools.ietf.org).=20 >>=20 >> Thanks, >> Brian=20 >>=20 >> --=20 >> Brian Weis >> Security, Enterprise Networking Group, Cisco Systems >> Telephone: +1 408 526 4796 >> Email: bew@cisco.com >>=20 >=20 > --=20 > Brian Weis > Security, Enterprise Networking Group, Cisco Systems > Telephone: +1 408 526 4796 > Email: bew@cisco.com >=20 > _______________________________________________ > MSEC mailing list > MSEC@ietf.org > https://www.ietf.org/mailman/listinfo/msec > _______________________________________________ > MSEC mailing list > MSEC@ietf.org > https://www.ietf.org/mailman/listinfo/msec --=20 Brian Weis Security, Enterprise Networking Group, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com