[MSEC] Review comments, was RE: GDOI support for IEC 62351

"Fries, Steffen" <steffen.fries@siemens.com> Tue, 06 August 2013 08:35 UTC

Return-Path: <steffen.fries@siemens.com>
X-Original-To: msec@ietfa.amsl.com
Delivered-To: msec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AE3F21F9AE3 for <msec@ietfa.amsl.com>; Tue, 6 Aug 2013 01:35:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -12.249
X-Spam-Level:
X-Spam-Status: No, score=-12.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_INVITATION=-2, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
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 wODXY+CUrtsB for <msec@ietfa.amsl.com>; Tue, 6 Aug 2013 01:35:17 -0700 (PDT)
Received: from lizzard.sbs.de (lizzard.sbs.de [194.138.37.39]) by ietfa.amsl.com (Postfix) with ESMTP id A4CCB21F90CC for <msec@ietf.org>; Tue, 6 Aug 2013 01:35:15 -0700 (PDT)
Received: from mail2.sbs.de (localhost [127.0.0.1]) by lizzard.sbs.de (8.13.6/8.13.6) with ESMTP id r768Z7Rb030633; Tue, 6 Aug 2013 10:35:09 +0200
Received: from defthw99et6msx.ww902.siemens.net ([157.163.148.61]) by mail2.sbs.de (8.13.6/8.13.6) with ESMTP id r768Z6JJ028644 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 6 Aug 2013 10:35:07 +0200
Received: from DENBGAT9ERCMSX.ww902.siemens.net (139.22.70.82) by DEFTHW99ET6MSX.ww902.siemens.net (157.163.148.61) with Microsoft SMTP Server (TLS) id 8.3.298.1; Tue, 6 Aug 2013 10:35:06 +0200
Received: from DENBGAT9EH2MSX.ww902.siemens.net ([169.254.6.86]) by DENBGAT9ERCMSX.ww902.siemens.net ([139.22.70.82]) with mapi id 14.03.0146.000; Tue, 6 Aug 2013 10:35:06 +0200
From: "Fries, Steffen" <steffen.fries@siemens.com>
To: Brian Weis <bew@cisco.com>, "msec@ietf.org" <msec@ietf.org>
Thread-Topic: Review comments, was RE: [MSEC] GDOI support for IEC 62351
Thread-Index: AQHOj7Z3AbSbgsEbm0iv4yUajEgAMpmHvMjQ
Date: Tue, 06 Aug 2013 08:35:05 +0000
Message-ID: <E6C9F0E527F94F4692731382340B3378025AA7@DENBGAT9EH2MSX.ww902.siemens.net>
References: <3CB35FCD-F9EA-4361-B290-3CBBE087C3B8@cisco.com> <5C96E649-6CF5-450E-9787-2C51D76DF2A5@cisco.com>
In-Reply-To: <5C96E649-6CF5-450E-9787-2C51D76DF2A5@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [139.22.70.9]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "draft-weis-gdoi-iec62351-9@tools.ietf.org" <draft-weis-gdoi-iec62351-9@tools.ietf.org>, Sean Turner <turners@ieca.com>
Subject: [MSEC] Review comments, was RE: GDOI support for IEC 62351
X-BeenThere: msec@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multicast Security List <msec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/msec>, <mailto:msec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/msec>
List-Post: <mailto:msec@ietf.org>
List-Help: <mailto:msec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/msec>, <mailto:msec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 06 Aug 2013 08:35:22 -0000

Hi Brian,

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.

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.

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."

- 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."

Section 1.1 (page 4)
- two abbreviations are missing:
  - CK	Current Key
  - NK 	Next Key

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. 

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." 
  The application of the key material is defined in IEC 61850-90-5 (and will be included in IEC 62351-6) 
  and may be used for integrity protection and/or confidentiality protection.

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.

Section 2.3  (page 10)
- There are two attributes for the TEK key: 
  - TEK_INTEGRITY_KEY if the key is associated with an IEC 61850-90-5 defined integrity algorithm 
  - 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.

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"?
 
Annex A (page 19)
- I calculated the KD Length of SPI=1 in the example to 62 (TEK_INTEGRITY_KEY, TEK_ALGORITHM_KEY, and the header). Currently 30 is stated. This should be verified.

Okay so far for the review. As I said, mostly editorial.

Regards
	Steffen  

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

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 



-----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

Folks,

Sean had some good feedback, and there is a new version now: <http://tools.ietf.org/html/draft-weis-gdoi-iec62351-9-02>. 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.

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.

Comments on the Internet-Draft are still requested.

Thanks,
Brian 

On Jul 23, 2013, at 1:56 AM, Brian Weis <bew@cisco.com> wrote:

> Greetings,
> 
> 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 <http://tools.ietf.org/html/draft-weis-gdoi-iec62351-9-01>. 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). 
> 
> Thanks,
> Brian 
> 
> -- 
> Brian Weis
> Security, Enterprise Networking Group, Cisco Systems
> Telephone: +1 408 526 4796
> Email: bew@cisco.com
> 

-- 
Brian Weis
Security, Enterprise Networking Group, Cisco Systems
Telephone: +1 408 526 4796
Email: bew@cisco.com

_______________________________________________
MSEC mailing list
MSEC@ietf.org
https://www.ietf.org/mailman/listinfo/msec