From nobody Mon Mar 3 10:27: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 B1F1F1A01C7 for ; Mon, 3 Mar 2014 10:27:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.115 X-Spam-Level: X-Spam-Status: No, score=-8.115 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_INVITATION=-2, HELO_EQ_FR=0.35, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547] 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 DEy4VLmiqBaH for ; Mon, 3 Mar 2014 10:27:23 -0800 (PST) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by ietfa.amsl.com (Postfix) with ESMTP id 5AA2C1A000A for ; Mon, 3 Mar 2014 10:27:22 -0800 (PST) X-IronPort-AV: E=Sophos; i="4.97,579,1389740400"; d="scan'208,217"; a="61106460" Received: from dhcp-a2af.meeting.ietf.org ([31.133.162.175]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/AES128-SHA; 03 Mar 2014 19:27:18 +0100 Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: multipart/alternative; boundary=Apple-Mail-55--1047789257 From: Vincent Roca In-Reply-To: <7CD270C5-2E9F-45A5-B434-8A4EB6146C24@cisco.com> Date: Mon, 3 Mar 2014 19:27:18 +0100 Message-Id: <0815908A-7B2F-4A0B-9654-5367962995B6@inria.fr> References: <3CB35FCD-F9EA-4361-B290-3CBBE087C3B8@cisco.com> <5C96E649-6CF5-450E-9787-2C51D76DF2A5@cisco.com> <7CD270C5-2E9F-45A5-B434-8A4EB6146C24@cisco.com> To: Brian Weis X-Mailer: Apple Mail (2.1085) Archived-At: http://mailarchive.ietf.org/arch/msg/msec/z9ePb0KSF5uS6B9N8oURXEpeFg4 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: Mon, 03 Mar 2014 18:27:30 -0000 --Apple-Mail-55--1047789257 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi Brian, I finally gave a look at the document (draft-weis-gdoi-iec62351-9-03). Here are my comments: =20 Section 2.2. SA TEK Payload ---------------------------- ** typo: An GDOI_PROTO_IEC_61850 SA TEK includes =3D> A GDOI_PROTO_IEC_61850 SA = TEK includes ^^ ** typo: represents a SPI =3D> represents an SPI ^^ (there are many occurrences of "a SPI", is it volontary?) ** typo: are define in Section 2.2. =3D> are defined in Section 2.2.X ^^ (several occurrences) =20 ** 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. =20 Section 2.3: ------------ =20 ** 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" =3D> "The KD Type MUST be TEK" ^^^^ =20 ** 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=3D<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=3D field. =20 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. =20 ** Fig p.19:=20 typo: There is a trailing "2" character in "RESERVED2". Cheers, Vincent Le 13 f=E9vr. 2014 =E0 23:20, Brian Weis a =E9crit : > Hi Steffen, >=20 > 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. >=20 > Thanks, > Brian >=20 > On Aug 6, 2013, at 11:10 PM, "Fries, Steffen" = wrote: >=20 >> 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 > --=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 --Apple-Mail-55--1047789257 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 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 =3D> A GDOI_PROTO_IEC_61850 SA = TEK includes
                =                     =        ^^
** typo:
represents a SPI =3D> = represents an SPI
              =                 =  ^^
(there are many occurrences of "a SPI", is it = volontary?)

** typo:
are define = in Section 2.2. =3D> 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 .
    =  
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" =3D> = "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=3D<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=3D<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=E9vr. 2014 =E0 = 23:20, Brian Weis a =E9crit :

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" <steffen.fries@siemens.com>= ; 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: 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

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=3D1 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://t= ools.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://t= ools.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/m= ailman/listinfo/msec
_______________________________________________
MSEC mailing = list
MSEC@ietf.org
https://www.ietf.org/m= ailman/listinfo/msec

--
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/ma= ilman/listinfo/msec

= --Apple-Mail-55--1047789257--