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

[Brian Weis <[e-mail]>]

Hi Steffen,

Many thanks for your detailed review. We've incorporated the changes and will publish them in the next version of the document.

On Aug 6, 2013, at 1:35 AM, "Fries, Steffen" <[e-mail]> wrote:

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

This makes sense. We're planning to change the title to "GDOI Protocol Support for IEC 62351 Security Services".

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

My co-authors tell me the precise wording would be "The protection of frames is defined within IEC 62351-6 , IEC 61850-8-1, and IEC 61850-9-2.", and we'll add that.

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

We've added a short introduction to the payloads here.

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

The most recent IEC 62351-9 document now points to this document as the definition of available algorithms to use.

We decided to drop support for AES-GCM here because there doesn't seem to be a safe way to use AES-GCM in the GOOSE and SV security transforms. AES-GCM takes a counter as input, but there is no explicit counter defined in the IEC documents by which the receiver would know what counter to use for decryption (or for integrity protection if AES-GMAC is used).

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

This change would be a good idea, but the names are defined in RFC 6407 and this document isn't at liberty to rename them.

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

The SA TEK is considered part of the SA payload (see RFC 6407 Figure 2), so the figure title is actually correct.

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

Good catch! We'll fix the figure.

Thanks,
Brian

> 
> 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: [phone]
> Fax: [phone]
> mailto:[e-mail]
> 
> 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: [e-mail] [mailto:[e-mail]] On Behalf Of Brian Weis
> Sent: Freitag, 2. August 2013 21:28
> To: [e-mail]
> Cc: [e-mail]; 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 <[e-mail]> 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 ([e-mail]) or send them to the authors ([e-mail]). 
>> 
>> Thanks,
>> Brian 

-- 
Brian Weis
Security, Enterprise Networking Group, Cisco Systems
Telephone: [phone]
Email: [e-mail]