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

[Vincent Roca <[e-mail]>]

Hi Brian,

I finally gave a look at the document (draft-weis-gdoi-iec62351-9-03).
Here are my comments:
     
Section 2.2.  SA TEK Payload
----------------------------

** typo:
An GDOI_PROTO_IEC_61850 SA TEK includes => A GDOI_PROTO_IEC_61850 SA TEK includes
                                           ^^
** typo:
represents a SPI => represents an SPI
                               ^^
(there are many occurrences of "a SPI", is it volontary?)

** typo:
are define in Section 2.2. => are defined in Section 2.2.X
                                       ^^
(several occurrences)
      
** There is a window of 2 keys (CK and NK). Each of them have timing values, representing
their validity time till it needs to be updated. As I understand, the CK will take the
value of the NK upon CK expiration. Potentially, the CK/NK timing values can be different.
Is it an issue (e.g. if the NK remaining lifetime is < CK remaining lifetime, the NK must
be updated before the CK) ? I imagine this is discussed elsewhere. A note might be useful.
     
Section 2.3:
------------              

** incoherencies:
there are several occurences of "KD payload", whereas it is written "Key Download Payload" elsewhere.
Also, section 1.3 mentions:
   KD    Key Download Payload
i.e. includes the payload in the KD acronym definition.

** Typo: "The KD TYPE MUST be TEK" => "The KD Type MUST be TEK"
                                              ^^^^
   
** Fig 6: The figure mentions "KD Length", but this is a Key Packet.
Should it be the "Key Packet Length" instead?

Appendix A:
-----------

** I find it strange to provide actual field payloads, without respecting the field size. E.g.:
	OID=<06 0B 2A 86 48 CE 56 83 E3 1A 08 01 02>
is 13 byte long if I understand correctly, but in the figure, it only spans 3 bytes.
Same remark for the OID SP=<DER for 233.252.0.1> field.    

BTW, these figures are not numbered which makes it more complicated to reference them.

** I was also wondering if there are alignment requirements. In theory no as there is
no padding field. I haven't seen any note for this, whereas all figures are presented in
such a way that 16-bit fields are correctly aligned. A note could be added to section B.1.
   
** Fig p.19: 
typo: There is a trailing "2" character in "RESERVED2".


Cheers,

   Vincent


Le 13 févr. 2014 à 23:20, Brian Weis a écrit :

> 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.
> 	<http://datatracker.ietf.org/doc/draft-weis-gdoi-iec62351-9/>
> Let us know if you have any further comments.
> 
> Thanks,
> Brian
> 
> On Aug 6, 2013, at 11:10 PM, "Fries, Steffen" <[e-mail]> wrote:
> 
>> Hi Brian,
>> 
>> 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.
>> 
>> Regards
>> 	Steffen
>> 
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On Behalf Of Fries, Steffen
>> Sent: Dienstag, 6. August 2013 10:35
>> To: Brian Weis; [e-mail]
>> Cc: [e-mail]; Sean Turner
>> Subject: [MSEC] Review comments, was RE: GDOI support for IEC 62351
>> 
>> 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: [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]
>>> 
>> 
>> -- 
>> Brian Weis
>> Security, Enterprise Networking Group, Cisco Systems
>> Telephone: [phone]
>> Email: [e-mail]
>> 
>> _______________________________________________
>> MSEC mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/msec
>> _______________________________________________
>> MSEC mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/msec
> 
> -- 
> Brian Weis
> Security, Enterprise Networking Group, Cisco Systems
> Telephone: [phone]
> Email: [e-mail]
> 
> _______________________________________________
> MSEC mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/msec