From ynir@checkpoint.com Sat Nov 2 23:44:16 2013 Return-Path: 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 B76E211E81A9 for ; Sat, 2 Nov 2013 23:44:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.491 X-Spam-Level: X-Spam-Status: No, score=-10.491 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, 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 a5DUXFIXAij1 for ; Sat, 2 Nov 2013 23:44:09 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id AD78E11E81A5 for ; Sat, 2 Nov 2013 23:44:06 -0700 (PDT) Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id rA36hmUE002186; Sun, 3 Nov 2013 08:43:49 +0200 X-CheckPoint: {5275EF65-2-1B221DC2-1FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.106]) by DAG-EX10.ad.checkpoint.com ([169.254.3.213]) with mapi id 14.03.0123.003; Sun, 3 Nov 2013 08:43:48 +0200 From: Yoav Nir To: Sean Turner Thread-Topic: [MSEC] Key Management protocol (GDOI - 6407) forward Thread-Index: Ac67FJGyoGPYHJStQ3mYygEDVBEZfAAEfu0gABl+LQAABa9lgACNPdEAAADvBAAAAE6HgAAAcUCABpwUlYA= Date: Sun, 3 Nov 2013 06:43:48 +0000 Message-ID: <0EC5982A-FAF2-4A67-9F4E-720CE0912DDC@checkpoint.com> References: <418E74FA535F654FAB3CAAE12902E2940156AA80@SISCO-SBS.sisconet.local> <7417090A-55F1-42ED-B051-1EB197DAAB52@checkpoint.com> <5245E431.8070208@concordia.ca> <5249980C.2090201@ieca.com> <5249A05F.6060207@ieca.com> <85CF9F24-C02C-491D-A000-487B7A524F97@checkpoint.com> In-Reply-To: <85CF9F24-C02C-491D-A000-487B7A524F97@checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.20.63] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="iso-8859-1" Content-ID: <653B8385AA82A04F987F6BB3E7AD4FEB@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "msec@ietf.org" , Jeff Gooding/SCE/EIX , "Maik Seewald \(maseewal\)" , "Andrew.Free@sce.com" , "Madani, Vahid" , "Adamiak, Mark \(GE Energy Management\)" , "Novosel, Damir" , "Thanos, Daniel \(GE Energy Management\)" , Herb Falk , "Alex Apostolov \(alex.apostolov@omicronusa.com\)" Subject: Re: [MSEC] Key Management protocol (GDOI - 6407) forward X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Nov 2013 06:44:17 -0000 Hi As promised. See below. Sean, do you want me to post it like a SecDir rev= iew on the secdir/iesg/draft lists? On Sep 30, 2013, at 9:14 AM, Yoav Nir wrote: > OK, I'll do it.=20 >=20 > At the latest, on the 20-hour journey to Vancouver. Hopefully earlier. >=20 > Yoav >=20 > On Sep 30, 2013, at 7:01 PM, Sean Turner wrote: >=20 >> IEC is usually paired with ISO ;) There's the rub right - I read it and= was like sure I take your word Brian. I think that you could treat it kin= d of like a secdir review and that would be sufficient for me. >>=20 Hi, there. At Sean's request, I've done a SecDir-ish review of draft-weis-gdoi-iec6235= 1-9-02. I think it is in pretty good shape, but I do have some concerns. First, an apology: the draft embeds OIDs in IKE packets. Throughout this re= view I use the term "ASN.1" for both the objects and the encoding. I do rea= lize that ASN means abstract syntax notation, and that the correct term to = use for the encoding ia DER, but this is a very common misuse. The draft do= es get this correct. I am somewhat confused by the IEC standards numbers. The abstract and intro= duction mostly discuss IEC 61850, which is the "power utility automation" f= amily of standards. On the other hand, the number in the title of the draft= is IEC 62351. There is a reference to a document called "IEC 62351 Part 9 = - Key Management". I can see how this draft relates to key management, but = "part 9" of what? Another thing that's missing for me, as one uninitiated in the ways of the = IEC, is what are we negotiating keys for? I get that it's not IPsec, but at= the end of the protocol, we have keys that are distributed to group member= s. Now, what is this data layer that can now use them. A reference to some = standard ("IEC-61850-9-2" would be OK), but since these are not widely avai= lable, some short description of what this protocol looks like would be gre= at. Another generic comment is about the IANA considerations as well as parts o= f section 2.2. Why do we need to establish new registries, that are duplica= tes of IPsec registries with one additional value? I know there has been so= me resistance to adding things there for stuff that's "not IKE", but with t= his already done in RFC 6932 ([1],[2]), that ship has left the station afte= r the horses had bolted. Why is there an OID_LENGTH field? All ASN.1 structures are self-describing= in terms of length. There can be a good reason: so that you can implement = with a bitwise comparison rather than implementing an ASN.1 parser. Please = say so if that's the reason. I didn't quite get where each of the OIDs in the ID payload (figure 2) and = the TEK payload (figure 4) come from. Are they the same? Appendix A suggest= s that they're not. So, - what does "type of traffic" mean? =20 - Appendix A says "OID=3D" in the TEK payload. What is k? One last thing: KeyID is the SPI. This is explicitly said in 2.2.4, but men= tioned earlier in 2.2. Why is it 1 octet rather than 4? There is a ton of I= Psec library code that assumes SPI length to be 4. Are the three bytes wort= h it? Yoav [1] http://www.iana.org/assignments/ipsec-registry/ipsec-registry.xhtml#ips= ec-registry-10 [2] http://tools.ietf.org/html/rfc6932=09 From TurnerS@ieca.com Sun Nov 3 09:03:03 2013 Return-Path: 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 1898F21E80DE for ; Sun, 3 Nov 2013 09:03:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] 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 Lsxj7GSkd6aj for ; Sun, 3 Nov 2013 09:02:58 -0800 (PST) Received: from gateway02.websitewelcome.com (gateway02.websitewelcome.com [69.41.247.20]) by ietfa.amsl.com (Postfix) with ESMTP id F09C521E80FA for ; Sun, 3 Nov 2013 09:02:55 -0800 (PST) Received: by gateway02.websitewelcome.com (Postfix, from userid 5007) id BAAD0BBE24DFB; Sun, 3 Nov 2013 11:02:41 -0600 (CST) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway02.websitewelcome.com (Postfix) with ESMTP id 9966BBBE24DD4 for ; Sun, 3 Nov 2013 11:02:41 -0600 (CST) Received: from [31.133.164.114] (port=53824 helo=dhcp-a472.meeting.ietf.org) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1Vd14f-0007yw-OO; Sun, 03 Nov 2013 11:02:53 -0600 Content-Type: multipart/signed; boundary="Apple-Mail=_37B97ABD-4464-4145-ABD4-C0475BCE5040"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: Sean Turner In-Reply-To: <418E74FA535F654FAB3CAAE12902E294015A2B47@SISCO-SBS.sisconet.local> Date: Sun, 3 Nov 2013 09:02:51 -0800 Message-Id: <1F274B6F-E4BD-4AD4-9A17-FB8BD8BA7826@ieca.com> References: <418E74FA535F654FAB3CAAE12902E2940156AA80@SISCO-SBS.sisconet.local> <7417090A-55F1-42ED-B051-1EB197DAAB52@checkpoint.com> <5245E431.8070208@concordia.ca> <5249980C.2090201@ieca.com> <5249A05F.6060207@ieca.com> <85CF9F24-C02C-491D-A000-487B7A524F97@checkpoint.com> <0EC5982A-FAF2-4A67-9F4E-720CE0912DDC@checkpoint.com> <418E74FA535F654FAB3CAAE12902E294015A2B47@SISCO-SBS.sisconet.local> To: Herb Falk , Yoav Nir X-Mailer: Apple Mail (2.1816) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator3286.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (dhcp-a472.meeting.ietf.org) [31.133.164.114]:53824 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 9 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Cc: "msec@ietf.org" , Jeff Gooding/SCE/EIX , "Maik Seewald \(maseewal\)" , "Andrew.Free@sce.com" , "Madani, Vahid" , "Adamiak, Mark \(GE Energy Management\)" , "Novosel, Damir" , "Thanos, Daniel \(GE Energy Management\)" , "Alex Apostolov \(alex.apostolov@omicronusa.com\)" Subject: Re: [MSEC] Key Management protocol (GDOI - 6407) forward X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Nov 2013 17:03:03 -0000 --Apple-Mail=_37B97ABD-4464-4145-ABD4-C0475BCE5040 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Yoav, Please do submit it like a regular secdir review. spt On Nov 03, 2013, at 04:18, Herb Falk wrote: > See below. > =20 > Herbert Falk > Solutions Architect > SISCO, INC. > 6605 19 =BD Mile Rd. > Sterling Heights, MI 48314 > (586) 254-0020 x-105 > =20 > =20 > = =20 > "In matters of style, swim with the current; in matters of = principle, stand like a rock." [Thomas Jefferson] > =20 > =20 > NOTICE: This communication may contain privileged or other = confidential information. If you are not the intended recipient, or = believe that you have received this communication in error, please do = not print, copy, retransmit, disseminate, or otherwise use the = information. Also, please indicate to the sender that you have received = this communication in error, and delete the copy you received. Thank = you. > =20 > -----Original Message----- > From: Yoav Nir [mailto:ynir@checkpoint.com]=20 > Sent: Sunday, November 03, 2013 1:44 AM > To: Sean Turner > Cc: msec@ietf.org; Jeff Gooding/SCE/EIX; Maik Seewald (maseewal); = Andrew.Free@sce.com; Madani, Vahid; Adamiak, Mark (GE Energy = Management); Novosel, Damir; Thanos, Daniel (GE Energy Management); Herb = Falk ; Alex Apostolov (alex.apostolov@omicronusa.com) > Subject: Re: [MSEC] Key Management protocol (GDOI - 6407) forward > =20 > Hi > =20 > As promised. See below. Sean, do you want me to post it like a = SecDir review on the secdir/iesg/draft lists? > =20 > On Sep 30, 2013, at 9:14 AM, Yoav Nir wrote: > =20 > > OK, I'll do it. > > > > At the latest, on the 20-hour journey to Vancouver. Hopefully = earlier. > > > > Yoav > > > > On Sep 30, 2013, at 7:01 PM, Sean Turner wrote: > > > >> IEC is usually paired with ISO ;) There's the rub right - I read = it and was like sure I take your word Brian. I think that you could = treat it kind of like a secdir review and that would be sufficient for = me. > >> > =20 > =20 > =20 > Hi, there. > =20 > At Sean's request, I've done a SecDir-ish review of = draft-weis-gdoi-iec62351-9-02. I think it is in pretty good shape, but I = do have some concerns. > =20 > First, an apology: the draft embeds OIDs in IKE packets. Throughout = this review I use the term "ASN.1" for both the objects and the = encoding. I do realize that ASN means abstract syntax notation, and that = the correct term to use for the encoding ia DER, but this is a very = common misuse. The draft does get this correct. > =20 > [Herb]: BER encoding is what was intended. > =20 > I am somewhat confused by the IEC standards numbers. The abstract and = introduction mostly discuss IEC 61850, which is the "power utility = automation" family of standards. On the other hand, the number in the = title of the draft is IEC 62351. There is a reference to a document = called "IEC 62351 Part 9 - Key Management". I can see how this draft = relates to key management, but "part 9" of what? > =20 > [Herb]: I don=92t understand the question. So I will try to explain. = IEC 61850 is a set of communication standards developed under IEC = Technical Committee 57. IEC TC57 has WG15 that was formed to address = security for the breadth of standards that are developed under TC57, = including IEC 61850. In IEC, the designations within a family of = standards (e.g. 61850 or 62351) are called parts. IEC 61850 has over 10 = standards that are 61850-1 through 61850-10 (e.g. 10 parts). = Chapters/sub-chapters are called =93clauses=94 in IEC. So when it = mentions IEC 62351 Part 9 =96 Key Management, the official reference is = =93IEC 62351-9 Ed. 1.0 Power systems management and associated = information exchange - Data and communications security - Part 9: Cyber = security key management for power system equipment (Future IEC 62351-9 = TS Ed.1)=94. When IEC removes the ED 1.0, it means refer to the current = revisions (ED.2 has almost been completed). The =93Power systems = management and associated information exchange - Data and communications = security=94 is the charter of WG15 and the overall scope of 62351 (they = all have that in their title). Therefore, =93IEC 62351 Part 9 =96 Key = Management=94 could be referred to as =93IEC 62351-9=94, =93IEC 62351-9 = : Cyber security key management for power system equipment=94, or in = presentations =93IEC 62351-9=96 Key Management=94. So, I would change = to IEC 62351-9 (and give the full name). Sorry for the long = explanation. >=20 > =20 > =20 > Another thing that's missing for me, as one uninitiated in the ways of = the IEC, is what are we negotiating keys for? I get that it's not IPsec, = but at the end of the protocol, we have keys that are distributed to = group members. Now, what is this data layer that can now use them. A = reference to some standard ("IEC-61850-9-2" would be OK), but since = these are not widely available, some short description of what this = protocol looks like would be great. > =20 > [Herb]: The best I can do is to describe the use of the protocols. = IEC 61850 is used for the command/control of the power grid. There are = three prevalent uses for 61850: peer-to-peer communication (e.g. = client/server), multicast for high speed state exchange and control = (4msec time frame), sampled values used for high speed Current = Transformer/Voltage Transformer samples (this is a 15MB load per = source/network). Additionally, IEC 61850-90-5 is designed to route = GOOSE and a lower speed SV used for synchrophasor measurements (some = good information about synchrophasors can be found at: = https://www.naspi.org/). > =20 > Another generic comment is about the IANA considerations as well as = parts of section 2.2. Why do we need to establish new registries, that = are duplicates of IPsec registries with one additional value? I know = there has been some resistance to adding things there for stuff that's = "not IKE", but with this already done in RFC 6932 ([1],[2]), that ship = has left the station after the horses had bolted. > =20 > [Herb]: If I understand the question, originally, we had used a = =93private=94 value. It had been hoped that the IETF/IANA would provide = a standard number. It is not semantically correct for IEC to claim IKE, = when it is not. That would cause confusion in the IEC standards. = Obviously, this application of GDOI was not anticipated and thus some = type of expansion is needed. If IETF indicates that it won=92t extend = for an IEC standard (e.g. only IETF standards, that seem a bit odd. As = with all standards, the sea of application is always changing and = standards need to be changed to as the climate changes. IEC has always = referenced IETF RFCs. I can=92t officially speak on behalf of IEC, but = my personal opinion is that it is a bit strange to say the =93ship has = left the station=94 when a standards organization has a new use case. > =20 > Why is there an OID_LENGTH field? All ASN.1 structures are = self-describing in terms of length. There can be a good reason: so that = you can implement with a bitwise comparison rather than implementing an = ASN.1 parser. Please say so if that's the reason. > =20 > [Herb]: There are several reasons to use the OID. One is that it = allows other smart grid applications/protocols to expand the usage of = other domains (e.g. avoid the =93ship has left the station issue). The = other is to specifically encode it so easy comparisons can occur. Hope = that helps. > =20 > I didn't quite get where each of the OIDs in the ID payload (figure 2) = and the TEK payload (figure 4) come from. Are they the same? Appendix A = suggests that they're not. So, > - what does "type of traffic" mean?=20 > - Appendix A says "OID=3D" in the TEK payload. What is = k? > =20 > [Herb]: The use of GDOI, for 90-5, is intended to have keys that are = based upon a combination of content/protocol/destination. There are 3 = protocols (CS, GOOSE, SV). All three define the content to be = transferred to a particular destination as a set of Data called = DataSets. SV and GOOSE can be sent via 90-5 or directly as an = Ethertype. Therefore, the combinations/permutations lead to the = following list in 90-5: > =20 > 61850_ETHERNET_GOOSE > Specifies that the payload is requesting a key for a IEC 61850-8-1 = GOOSE APDU, with IEC 62351-6 signature, that is being sent to a = particular destination Ethernet address. > 1.2.840.10070.61850.8.1.1 > 61850_UDP_ADDR_GOOSE > Specifies that the payload is requesting a key for a IEC 61850-90-5 = GOOSE APDU that is being sent to a particular destination IP address. > 1.2.840.10070.61850.8.1.2 > 61850_UDP _Tunnel > Specifies that the payload is requesting a key for a IEC 61850-90-5 = Tunnel APDU that is being sent to a particular destination IP address. > 1.2.840.10070.61850.8.1.4 > 61850_ETHERNET_SV > Specifies that the payload is requesting a key for a IEC 61850-9-2 SV = APDU, with IEC 62351-6 signature, that is being sent to a particular = destination Ethernet address. > 1.2.840.10070.61850.9.2.1 > 61850_UDP_ADDR_SV > Specifies that the payload is requesting a key for a IEC 61850-90-5 SV = APDU that is being sent to a particular destination IP address. > 1.2.840.10070.61850.9.2.2 > 61850_IP_ISO9506 > Specifies that the payload is requesting a key for a IEC 61850-8-1 ISO = 9506 endpoint. This payload definition is out-of-scope of this = specification. > 1.2.840.10070.61850.8.1.4 > =20 > =20 > One last thing: KeyID is the SPI. This is explicitly said in 2.2.4, = but mentioned earlier in 2.2. Why is it 1 octet rather than 4? There is = a ton of IPsec library code that assumes SPI length to be 4. Are the = three bytes worth it? > =20 > [Herb]: If 4 is the normal, then lets make it 4. What is the value = ordering (Network transmission or other)? > =20 > Yoav > =20 > [1] = http://www.iana.org/assignments/ipsec-registry/ipsec-registry.xhtml#ipsec-= registry-10 > [2] http://tools.ietf.org/html/rfc6932 =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 --Apple-Mail=_37B97ABD-4464-4145-ABD4-C0475BCE5040 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIEgDCCBHww ggJkoAMCAQICCQCdWMxKNutUeTANBgkqhkiG9w0BAQsFADAiMQswCQYDVQQGEwJVUzETMBEGA1UE ChMKSUVDQSwgSW5jLjAeFw0xMzA0MDMxNDUxMThaFw0xNDA0MDMxNDUxMThaMDgxCzAJBgNVBAYT AlVTMRMwEQYDVQQKEwpJRUNBLCBJbmMuMRQwEgYDVQQDEwtTZWFuIFR1cm5lcjCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBAOpCGCRptT1m+bIpLTmbahZLZ0Qe4X99f8SgTQ7QISvUfpmn tfOD1oA1AttXlOULEERYubzvDnUTXvstFomQx0XTA67IaV+mw9ODRtG1hPN/erdKX6sU6rH4tsEb ba3Drr/I0HT3YVvD3SjWtGXjF12XLvTP6+LfMIIDTCAPiEd9KPG23D7skVu/4BvvmdLFI96OARhg wQ86M+lTIn83KRJlbbfAeIevbRx/rUB7D+uvMdWxOzR0KZJhd6dEeTXVwBXZG4rnQ4uFM+mRSiD4 rxDCyOuIuOzR07tnOyCRio6sRipOZvwQUWttdsgMEs6IxLdWsaTXcs1HjCsxrdedovMCAwEAAaOB njCBmzAOBgNVHQ8BAf8EBAMCBeAwHwYDVR0jBBgwFoAUAHRsSeXJUmFxTVY4q2HJ8uHl+w0wGwYD VR0RBBQwEoEQVHVybmVyU0BpZWNhLmNvbTAyBgNVHR8EKzApMCegJaAjhiFodHRwOi8vd3d3Lmll Y2EuY29tL2NybHMvaWVjYS5jcmwwFwYDVR0gBBAwDjAMBgorBgEEAYHXAAAAMA0GCSqGSIb3DQEB CwUAA4ICAQAimDYm77ppTi4vK6qJSUhyvCDMGb8mngiEXEYKxsfdHPWoDO7+06j7dAZ8sDD9/FtE kiUMyoNGSUmKHR+tGperVnNiM/Zk6WwCJv8dYZwhGXNQeEGzeys/UkFv7CFX7uDSn8GQeB8sOAZ1 N1hxV/TvT8qXvcRxP5+aWTAGAq3TKtCQxZjuU74L3st2hZiOhJlhjhqz0K5FIwWzXUK9uwhZe1th GUpDbRustVgmKN2Xa0pzwqI1VUO0jnWt24A4u59xo6DJQXzQVMhCx0xhpemuT9BrsBDTX8eJdI1i Wv9wp3ivSrfHjKXp8y8OGD+usiG40HCjj0W9C+dH0VfbgrB6QOI4vA9+kTg4mANth1cxyxwPYOSJ v0zi1qR0eDIGI//2v2/s6TmGuNqbnRa26Ldv5gGqS7xj32Fiaby6UOXs4+aAIWGZEOH+BXjozcvE eGBwjU/VRQYu6itR28PaNhNVji4D5ITaGxWWiycqK1EUaFraWHtk7W100ROX69xTeFVZP86D2ymi /aohl5Vb1vlYHdqlbgqjDRl9dPbTxVCXEHf+jkexcuwlLTvr7F+5DIN6c/EbCpRqQx3edy193L48 OGyRDh1/Wmzpew0VWWAWOSXGl/P9VzXf3Z6GPt7flN/V9iEJAa3Mo+w+eIdzJkHBWR+yJcqQcCRM MSyishMwLDGCAjgwggI0AgEBMC8wIjELMAkGA1UEBhMCVVMxEzARBgNVBAoTCklFQ0EsIEluYy4C CQCdWMxKNutUeTAJBgUrDgMCGgUAoIHfMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTEzMTEwMzE3MDI1MVowIwYJKoZIhvcNAQkEMRYEFL7oPL8Eilh1Dsw9jrstQ90u LsgMMD4GCSsGAQQBgjcQBDExMC8wIjELMAkGA1UEBhMCVVMxEzARBgNVBAoTCklFQ0EsIEluYy4C CQCdWMxKNutUeTBABgsqhkiG9w0BCRACCzExoC8wIjELMAkGA1UEBhMCVVMxEzARBgNVBAoTCklF Q0EsIEluYy4CCQCdWMxKNutUeTANBgkqhkiG9w0BAQEFAASCAQAUbPl+wvk/DataO+vE+0xVPmeW CFl6QE15B5kycIr3s3FcjMCrq+EI/PjJG7GNxhCpUTynwSsogQaAvfFn/94JPpcqQi6M0GykDjij prkpmZXN92xpPVJbCXnU3U2CmGZVjC32qsImpgNTPFIs1k8Ndj0z21OtRBNrftjgVeCi2jxbizaU VkWCUYiql9q9T/7F5EfmOZdjEODlfXY491yg03l6TO7uz/2vkqgJK6LZEzYmp/ySFYBE9wrc70UX pSTfOWwGr18uvRtw2Csdwp9phCIIvlNbGJNIXene5MaaUFV4O4n0HQYcPC6GJM0G9D3b7hcH0vIP 8Fq9WHvk+le/AAAAAAAA --Apple-Mail=_37B97ABD-4464-4145-ABD4-C0475BCE5040-- From ynir@checkpoint.com Sun Nov 3 10:54:51 2013 Return-Path: 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 5DF1021E80FB for ; Sun, 3 Nov 2013 10:54:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.495 X-Spam-Level: X-Spam-Status: No, score=-10.495 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 H+AMERDWE1eY for ; Sun, 3 Nov 2013 10:54:47 -0800 (PST) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 9D55621E8116 for ; Sun, 3 Nov 2013 10:54:44 -0800 (PST) Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id rA3IsPDu024688; Sun, 3 Nov 2013 20:54:25 +0200 X-CheckPoint: {52769A9A-1-1B221DC2-1FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.106]) by DAG-EX10.ad.checkpoint.com ([169.254.3.213]) with mapi id 14.03.0123.003; Sun, 3 Nov 2013 20:54:25 +0200 From: Yoav Nir To: "Herb Falk " Thread-Topic: [MSEC] Key Management protocol (GDOI - 6407) forward Thread-Index: Ac67FJGyoGPYHJStQ3mYygEDVBEZfAAEfu0gABl+LQAABa9lgACNPdEAAADvBAAAAE6HgAAAcUCABpwUlYAADn5l8AALBa6A Date: Sun, 3 Nov 2013 18:54:24 +0000 Message-ID: <48FD832C-F312-42D6-A63C-F878507ACC6D@checkpoint.com> References: <418E74FA535F654FAB3CAAE12902E2940156AA80@SISCO-SBS.sisconet.local> <7417090A-55F1-42ED-B051-1EB197DAAB52@checkpoint.com> <5245E431.8070208@concordia.ca> <5249980C.2090201@ieca.com> <5249A05F.6060207@ieca.com> <85CF9F24-C02C-491D-A000-487B7A524F97@checkpoint.com> <0EC5982A-FAF2-4A67-9F4E-720CE0912DDC@checkpoint.com> <418E74FA535F654FAB3CAAE12902E294015A2B47@SISCO-SBS.sisconet.local> In-Reply-To: <418E74FA535F654FAB3CAAE12902E294015A2B47@SISCO-SBS.sisconet.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.20.239] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: multipart/alternative; boundary="_000_48FD832CF31242D6A63CF878507ACC6Dcheckpointcom_" MIME-Version: 1.0 Cc: "msec@ietf.org" , Jeff Gooding/SCE/EIX , "Maik Seewald \(maseewal\)" , "Andrew.Free@sce.com" , "Madani, Vahid" , "Adamiak, Mark \(GE Energy Management\)" , Sean Turner , "Thanos, Daniel \(GE Energy Management\)" , "Novosel, Damir" , "Alex Apostolov \(alex.apostolov@omicronusa.com\)" Subject: Re: [MSEC] Key Management protocol (GDOI - 6407) forward X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Nov 2013 18:54:51 -0000 --_000_48FD832CF31242D6A63CF878507ACC6Dcheckpointcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable At Sean's request, I'm sending this again to the SecDir list. I fixed the B= ER/DER thing, and removed the line about 4-byte SPI, but not the rest. See below On Nov 3, 2013, at 4:18 AM, "Herb Falk >" > wrote: See below. Herbert Falk Solutions Architect SISCO, INC. 6605 19 =BD Mile Rd. Sterling Heights, MI 48314 (586) 254-0020 x-105 "In matters of style, swim with the current; in matters of principle, sta= nd like a rock." [Thomas Jefferson] NOTICE: This communication may contain privileged or other confidential inf= ormation. If you are not the intended recipient, or believe that you have = received this communication in error, please do not print, copy, retransmit= , disseminate, or otherwise use the information. Also, please indicate to= the sender that you have received this communication in error, and delete = the copy you received. Thank you. -----Original Message----- From: Yoav Nir [mailto:ynir@checkpoint.com] Sent: Sunday, November 03, 2013 1:44 AM To: Sean Turner Cc: msec@ietf.org; Jeff Gooding/SCE/EIX; Maik Seewald= (maseewal); Andrew.Free@sce.com; Madani, Vahid= ; Adamiak, Mark (GE Energy Management); Novosel, Damir; Thanos, Daniel (GE = Energy Management); Herb Falk >= ; Alex Apostolov (alex.apostolov@omicronusa.com) Subject: Re: [MSEC] Key Management protocol (GDOI - 6407) forward Hi As promised. See below. Sean, do you want me to post it like a SecDir rev= iew on the secdir/iesg/draft lists? On Sep 30, 2013, at 9:14 AM, Yoav Nir > wrote: > OK, I'll do it. > > At the latest, on the 20-hour journey to Vancouver. Hopefully earlier. > > Yoav > > On Sep 30, 2013, at 7:01 PM, Sean Turner > wrote: > >> IEC is usually paired with ISO ;) There's the rub right - I read it and= was like sure I take your word Brian. I think that you could treat it kin= d of like a secdir review and that would be sufficient for me. >> Hi, there. At Sean's request, I've done a SecDir-ish review of draft-weis-gdoi-iec6235= 1-9-02. I think it is in pretty good shape, but I do have some concerns. First, an apology: the draft embeds OIDs in IKE packets. Throughout this re= view I use the term "ASN.1" for both the objects and the encoding. I do rea= lize that ASN means abstract syntax notation, and that the correct term to = use for the encoding ia DER, but this is a very common misuse. The draft do= es get this correct. [Herb]: BER encoding is what was intended. I am somewhat confused by the IEC standards numbers. The abstract and intro= duction mostly discuss IEC 61850, which is the "power utility automation" f= amily of standards. On the other hand, the number in the title of the draft= is IEC 62351. There is a reference to a document called "IEC 62351 Part 9 = - Key Management". I can see how this draft relates to key management, but = "part 9" of what? [Herb]: I don=92t understand the question. So I will try to explain. IEC= 61850 is a set of communication standards developed under IEC Technical Co= mmittee 57. IEC TC57 has WG15 that was formed to address security for the = breadth of standards that are developed under TC57, including IEC 61850. I= n IEC, the designations within a family of standards (e.g. 61850 or 62351) = are called parts. IEC 61850 has over 10 standards that are 61850-1 through= 61850-10 (e.g. 10 parts). Chapters/sub-chapters are called =93clauses=94= in IEC. So when it mentions IEC 62351 Part 9 =96 Key Management, the offi= cial reference is =93IEC 62351-9 Ed. 1.0 Power systems management and asso= ciated information exchange - Data and communications security - Part 9: Cy= ber security key management for power system equipment (Future IEC 62351-9 = TS Ed.1)=94. When IEC removes the ED 1.0, it means refer to the current re= visions (ED.2 has almost been completed). The =93Power systems management = and associated information exchange - Data and communications security=94 i= s the charter of WG15 and the overall scope of 62351 (they all have that in= their title). Therefore, =93IEC 62351 Part 9 =96 Key Management=94 could = be referred to as =93IEC 62351-9=94, =93IEC 62351-9 : Cyber security key ma= nagement for power system equipment=94, or in presentations =93IEC 62351-9= =96 Key Management=94. So, I would change to IEC 62351-9 (and give the fu= ll name). Sorry for the long explanation. [Yoav] OK. I guess the IEC standards have a more complicated naming convent= ion than RFCs .I'm just missing an overall title for 62351. Another thing that's missing for me, as one uninitiated in the ways of the = IEC, is what are we negotiating keys for? I get that it's not IPsec, but at= the end of the protocol, we have keys that are distributed to group member= s. Now, what is this data layer that can now use them. A reference to some = standard ("IEC-61850-9-2" would be OK), but since these are not widely avai= lable, some short description of what this protocol looks like would be gre= at. [Herb]: The best I can do is to describe the use of the protocols. IEC 618= 50 is used for the command/control of the power grid. There are three prev= alent uses for 61850: peer-to-peer communication (e.g. client/server), mul= ticast for high speed state exchange and control (4msec time frame), sample= d values used for high speed Current Transformer/Voltage Transformer sample= s (this is a 15MB load per source/network). Additionally, IEC 61850-90-5 = is designed to route GOOSE and a lower speed SV used for synchrophasor meas= urements (some good information about synchrophasors can be found at: https= ://www.naspi.org/). [Yoav] That's fine. I'd be happy with text saying "This is UDP communicatio= ns, over port X, either multicast or unicast, where we protect only the pay= load with the keys" (I'm making this up. I have no idea what the protocol = looks like, which is my point) Another generic comment is about the IANA considerations as well as parts o= f section 2.2. Why do we need to establish new registries, that are duplica= tes of IPsec registries with one additional value? I know there has been so= me resistance to adding things there for stuff that's "not IKE", but with t= his already done in RFC 6932 ([1],[2]), that ship has left the station afte= r the horses had bolted. [Herb]: If I understand the question, originally, we had used a =93private= =94 value. It had been hoped that the IETF/IANA would provide a standard n= umber. It is not semantically correct for IEC to claim IKE, when it is not= . That would cause confusion in the IEC standards. Obviously, this applic= ation of GDOI was not anticipated and thus some type of expansion is needed= . If IETF indicates that it won=92t extend for an IEC standard (e.g. only = IETF standards, that seem a bit odd. As with all standards, the sea of app= lication is always changing and standards need to be changed to as the clim= ate changes. IEC has always referenced IETF RFCs. I can=92t officially s= peak on behalf of IEC, but my personal opinion is that it is a bit strange = to say the =93ship has left the station=94 when a standards organization h= as a new use case. [Yoav] As I said, that ship has sailed. We have added stuff of "other stand= ards", and those standards are 802.11, and not IKE. Just as the group descr= iption for "224-bit Brainpool ECP group" says "Not for RFC 2409", an entry = for "ID_OID" can say the same. Besides, it's not for an outside standard. T= his draft is going to become an RFC. Why is there an OID_LENGTH field? All ASN.1 structures are self-describing= in terms of length. There can be a good reason: so that you can implement = with a bitwise comparison rather than implementing an ASN.1 parser. Please = say so if that's the reason. [Herb]: There are several reasons to use the OID. One is that it allows o= ther smart grid applications/protocols to expand the usage of other domains= (e.g. avoid the =93ship has left the station issue). The other is to spec= ifically encode it so easy comparisons can occur. Hope that helps. I didn't quite get where each of the OIDs in the ID payload (figure 2) and = the TEK payload (figure 4) come from. Are they the same? Appendix A suggest= s that they're not. So, - what does "type of traffic" mean? - Appendix A says "OID=3D" in the TEK payload. What is k? [Herb]: The use of GDOI, for 90-5, is intended to have keys that are based= upon a combination of content/protocol/destination. There are 3 protocols= (CS, GOOSE, SV). All three define the content to be transferred to a part= icular destination as a set of Data called DataSets. SV and GOOSE can be s= ent via 90-5 or directly as an Ethertype. Therefore, the combinations/perm= utations lead to the following list in 90-5: 61850_ETHERNET_GOOSE Specifies that the payload is requesting a key for a IEC 61850-8-1 GOOSE AP= DU, with IEC 62351-6 signature, that is being sent to a particular destinat= ion Ethernet address. 1.2.840.10070.61850.8.1.1 61850_UDP_ADDR_GOOSE Specifies that the payload is requesting a key for a IEC 61850-90-5 GOOSE A= PDU that is being sent to a particular destination IP address. 1.2.840.10070.61850.8.1.2 61850_UDP _Tunnel Specifies that the payload is requesting a key for a IEC 61850-90-5 Tunnel = APDU that is being sent to a particular destination IP address. 1.2.840.10070.61850.8.1.4 61850_ETHERNET_SV Specifies that the payload is requesting a key for a IEC 61850-9-2 SV APDU,= with IEC 62351-6 signature, that is being sent to a particular destination= Ethernet address. 1.2.840.10070.61850.9.2.1 61850_UDP_ADDR_SV Specifies that the payload is requesting a key for a IEC 61850-90-5 SV APDU= that is being sent to a particular destination IP address. 1.2.840.10070.61850.9.2.2 61850_IP_ISO9506 Specifies that the payload is requesting a key for a IEC 61850-8-1 ISO 9506= endpoint. This payload definition is out-of-scope of this specification. 1.2.840.10070.61850.8.1.4 One last thing: KeyID is the SPI. This is explicitly said in 2.2.4, but men= tioned earlier in 2.2. Why is it 1 octet rather than 4? There is a ton of I= Psec library code that assumes SPI length to be 4. Are the three bytes wort= h it? [Herb]: If 4 is the normal, then lets make it 4. What is the value orderi= ng (Network transmission or other)? Actually, I had intended to remove that line when I realized that what you = were negotiating was not IPsec... Yoav [1] http://www.iana.org/assignments/ipsec-registry/ipsec-registry.xhtml#ips= ec-registry-10 [2] http://tools.ietf.org/html/rfc6932 Email secured by Check Point --_000_48FD832CF31242D6A63CF878507ACC6Dcheckpointcom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable At Sean's request, I'm sending this again to the SecDir list. I fixed the B= ER/DER thing, and removed the line about 4-byte SPI, but not the rest.

See below


On Nov 3, 2013, at 4:18 AM, "Herb Falk <herb@sisconet.com>" <Herb@sisconet.com>
 wrote:

See below.
 
Herbert Falk
Solutions Architect
SISCO, INC.
6605 19 =BD Mile Rd.
Sterling Heights, MI 48314
(586) 254-0020 x-105
 
 
            &nb= sp;            =             &nb= sp;            =             &nb= sp;            =    
"In matters of style, swim with the current;   in matters of= principle, stand like a rock." [Thomas Jefferson]
 
 
NOTICE: This communication may contain privileged or other confidential inf= ormation. If you are not the intended recipient, or believe that you have&n= bsp; received this communication in error, please do not print, copy, retra= nsmit,  disseminate, or otherwise use the information. Also,  please indicate to the sender that you have r= eceived this communication in error, and delete the copy you received. Than= k you.
 
-----Original Message-----
From: Yoav Nir [mailto:ynir@checkpoint.com] 
Sent: Sunday, November 03, 2013 1:44 AM
To: Sean Turner
Cc: msec@ietf.org; Jeff Gooding/SCE/EI= X; Maik Seewald (maseewal); Andrew.Free@sce.com; Madani, Vahid; Adamiak, Mark (GE Energy Management); Novosel, Damir; Thano= s, Daniel (GE Energy Management); Herb Falk <herb@siscon= et.com>; Alex Apostolov (alex.apostolov@= omicronusa.com)
Subject: Re: [MSEC] Key Management protocol (GDOI - 6407) forward
 
Hi
 
As promised.  See below.  Sean, do you want me to post it like a = SecDir review on the secdir/iesg/draft lists?
 
On Sep 30, 2013, at 9:14 AM, Yoav Nir <ynir@checkpoint.com&= gt; wrote:
 
> OK, I'll do it.
>
> At the latest, on the 20-hour journey to Vancouver. Hopefully earlier.=
>
> Yoav
>
> On Sep 30, 2013, at 7:01 PM, Sean Turner <turners@ieca.com> wrote:
>
>> IEC is usually paired with ISO ;)  There's the rub right - I = read it and was like sure I take your word Brian.  I think that you co= uld treat it kind of like a secdir review and that would be sufficient for = me.
>>
 
 
 
Hi, there.
 
At Sean's request, I've done a SecDir-ish review of draft-weis-gdoi-iec6235= 1-9-02. I think it is in pretty good shape, but I do have some concerns.
 
First, an apology: the draft embeds OIDs in IKE packets. Throughout this re= view I use the term "ASN.1" for both the objects and the encoding= . I do realize that ASN means abstract syntax notation, and that the correc= t term to use for the encoding ia DER, but this is a very common misuse. The draft does get this correct.<= /div>
 
[Herb]:  BER encoding is wha= t was intended.
 
I am somewhat confused by the IEC standards numbers. The abstract and intro= duction mostly discuss IEC 61850, which is the "power utility automati= on" family of standards. On the other hand, the number in the title of= the draft is IEC 62351. There is a reference to a document called "IEC 62351 Part 9 - Key Management". I can = see how this draft relates to key management, but "part 9" of wha= t?
 

[Herb]:  I don=92t understan= d the question.  So I will try to explain.  IEC 61850 is a set of= communication standards developed under IEC Technical Committee 57.  = IEC TC57 has WG15 that was formed to address security for the breadth of standards that are developed under TC57, including IEC 6185= 0.  In IEC, the designations within a family of standards (e.g. 61850 = or 62351) are called parts.  IEC 61850 has over 10 standards that are = 61850-1 through 61850-10 (e.g. 10 parts).   Chapters/sub-chapters are called =93clauses=94 in IEC.  S= o when it mentions IEC 62351 Part 9 =96 Key Management, the official refere= nce is  =93IEC 62351-9 Ed. 1.0 Power systems management and associated= information exchange - Data and communications security - Part 9: Cyber security key management for power system equipment (Future IEC 62= 351-9 TS Ed.1)=94.  When IEC removes the ED 1.0, it means refer to the= current revisions (ED.2 has almost been completed).  The =93Power sys= tems management and associated information exchange - Data and communications security=94 is the charter of WG15 and the overa= ll scope of 62351 (they all have that in their title).  Therefore, =93= IEC 62351 Part 9 =96 Key Management=94 could be referred to as =93IEC 62351= -9=94, =93IEC 62351-9 : Cyber security key management for power system equipment=94, or in presentations =93IEC 62351-9=96 Key M= anagement=94.   So, I would change to IEC 62351-9 (and give the f= ull name).  Sorry for the long explanation.

[Yoav] OK. I guess the IEC standards have a more complicated naming co= nvention than RFCs .I'm just missing an overall title for 62351. 

 
 
Another thing that's missing for me, as one uninitiated in the ways of the = IEC, is what are we negotiating keys for? I get that it's not IPsec, but at= the end of the protocol, we have keys that are distributed to group member= s. Now, what is this data layer that can now use them. A reference to some standard ("IEC-61850-9-2&q= uot; would be OK), but since these are not widely available, some short des= cription of what this protocol looks like would be great.
 

[Yoav] That's fine. I'd be happy with text saying "This is UDP co= mmunications, over port X, either multicast or unicast, where we protect on= ly the payload with the keys"  (I'm making this up. I have no ide= a what the protocol looks like, which is my point)

 
Another generic comment is about the IANA considerations as well as parts o= f section 2.2. Why do we need to establish new registries, that are duplica= tes of IPsec registries with one additional value? I know there has been so= me resistance to adding things there for stuff that's "not IKE", but with this already done in RFC 69= 32 ([1],[2]), that ship has left the station after the horses had bolted.
 
[Herb]:  If I understand the= question, originally, we had used a =93private=94 value.  It had been= hoped that the IETF/IANA would provide a standard number.  It is not = semantically correct for IEC to claim IKE, when it is not.  That would cause confusion in the IEC standards.  Obviousl= y, this application of GDOI was not anticipated and thus some type of expan= sion is needed.  If IETF indicates that it won=92t extend for an IEC s= tandard (e.g. only IETF standards, that seem a bit odd.  As with all standards, the sea of application is always changin= g and standards need to be changed to as the climate changes.  IEC has= always referenced IETF  RFCs.  I can=92t officially speak on beh= alf of IEC, but my personal opinion is that it is a bit strange to say the =93ship has left the station=94  when a standards = organization has a new use case.

[Yoav] As I said, that ship has sailed. We have added stuff of "o= ther standards", and those standards are 802.11, and not IKE. Just as = the group description for "224-bit Brainpool ECP group" says "Not for RFC 2409", an entry for "ID_OID" can say the = same. Besides, it's not for an outside standard. This draft is going to bec= ome an RFC.

 
Why is there an OID_LENGTH field?  All ASN.1 structures are self-descr= ibing in terms of length. There can be a good reason: so that you can imple= ment with a bitwise comparison rather than implementing an ASN.1 parser. Pl= ease say so if that's the reason.
 
[Herb]:  There are several r= easons to use the OID.  One is that it allows other smart grid applica= tions/protocols to expand the usage of other domains (e.g. avoid the =93shi= p has left the station issue).  The other is to specifically encode it so easy comparisons can occur.  Hope that help= s.
 
I didn't quite get where each of the OIDs in the ID payload (figure 2) and = the TEK payload (figure 4) come from. Are they the same? Appendix A suggest= s that they're not. So,
- what does "type of traffic" mean? 
  - Appendix A says "OID=3D<ASN.1 for k>" in the = TEK payload. What is k?
 
[Herb]:  The use of GDOI, fo= r 90-5, is intended to have keys that are based upon a combination of conte= nt/protocol/destination.  There are 3 protocols (CS, GOOSE, SV). = All three define the content to be transferred to a particular destination as a set of Data called DataSets.  SV and GO= OSE can be sent via 90-5 or directly as an Ethertype.  Therefore, the = combinations/permutations lead to the following list in 90-5:
 

61850_ETHERNET_GOO= SE

Specifies that the= payload is requesting a key for a IEC 61850-8-1 GOOSE APDU, with IEC&= nbsp;62351-6 signature, that is being sent to a particular destination Ethe= rnet address.

1.2.840.10070.6185= 0.8.1.1

61850_UDP_ADDR_GOO= SE

Specifies that the= payload is requesting a key for a IEC 61850-90-5 GOOSE APDU that is b= eing sent to a particular destination IP address.

1.2.840.10070.6185= 0.8.1.2

61850_UDP _Tunnel<= o:p>

Specifies that the= payload is requesting a key for a IEC 61850-90-5 Tunnel APDU that is = being sent to a particular destination IP address.

1.2.840.10070.6185= 0.8.1.4

61850_ETHERNET_SV<= o:p>

Specifies that the= payload is requesting a key for a IEC 61850-9-2 SV APDU, with IEC&nbs= p;62351-6 signature, that is being sent to a particular destination Etherne= t address.

1.2.840.10070.6185= 0.9.2.1

61850_UDP_ADDR_SV<= o:p>

Specifies that the= payload is requesting a key for a IEC 61850-90-5 SV APDU that is bein= g sent to a particular destination IP address.

1.2.840.10070.6185= 0.9.2.2

61850_IP_ISO9506

Specifies that the= payload is requesting a key for a IEC 61850-8-1 ISO 9506 endpoint. Th= is payload definition is out-of-scope of this specification.

1.2.840.10070.6185= 0.8.1.4
 
 
One last thing: KeyID is the SPI. This is explicitly said in 2.2.4, but men= tioned earlier in 2.2. Why is it 1 octet rather than 4? There is a ton of I= Psec library code that assumes SPI length to be 4. Are the three bytes wort= h it?
 
[Herb]:  If 4 is the normal,= then lets make it 4.  What is the value ordering (Network transmissio= n or other)?

Actually, I had intended to remove that line when I realized that what= you were negotiating was not IPsec...

 
Yoav
 


Email secured by Check Point 


--_000_48FD832CF31242D6A63CF878507ACC6Dcheckpointcom_-- From Herb@sisconet.com Sun Nov 3 04:18:25 2013 Return-Path: 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 857AF11E8165 for ; Sun, 3 Nov 2013 04:18:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 TuZqg1MZnzlZ for ; Sun, 3 Nov 2013 04:18:19 -0800 (PST) Received: from mail.sisconet.com (mail.sisconet.com [50.77.197.169]) by ietfa.amsl.com (Postfix) with ESMTP id 5FA5A11E80F9 for ; Sun, 3 Nov 2013 04:18:19 -0800 (PST) Received: from SISCO-SBS.sisconet.local ([fe80::2459:3d41:7314:dc1b]) by SISCO-SBS.sisconet.local ([fe80::2459:3d41:7314:dc1b%10]) with mapi id 14.03.0123.003; Sun, 3 Nov 2013 07:18:21 -0500 From: "Herb Falk " To: Yoav Nir , Sean Turner Thread-Topic: [MSEC] Key Management protocol (GDOI - 6407) forward Thread-Index: Ac67FJGyoGPYHJStQ3mYygEDVBEZfAAEfu0gABl+LQAABa9lgACNPdEAAADvBAAAAE6HgAAAcUCABpwUlYAADn5l8A== Date: Sun, 3 Nov 2013 12:18:20 +0000 Message-ID: <418E74FA535F654FAB3CAAE12902E294015A2B47@SISCO-SBS.sisconet.local> References: <418E74FA535F654FAB3CAAE12902E2940156AA80@SISCO-SBS.sisconet.local> <7417090A-55F1-42ED-B051-1EB197DAAB52@checkpoint.com> <5245E431.8070208@concordia.ca> <5249980C.2090201@ieca.com> <5249A05F.6060207@ieca.com> <85CF9F24-C02C-491D-A000-487B7A524F97@checkpoint.com> <0EC5982A-FAF2-4A67-9F4E-720CE0912DDC@checkpoint.com> In-Reply-To: <0EC5982A-FAF2-4A67-9F4E-720CE0912DDC@checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [69.14.220.69] Content-Type: multipart/alternative; boundary="_000_418E74FA535F654FAB3CAAE12902E294015A2B47SISCOSBSsiscone_" MIME-Version: 1.0 X-Mailman-Approved-At: Sun, 03 Nov 2013 13:16:23 -0800 Cc: "msec@ietf.org" , Jeff Gooding/SCE/EIX , "Maik Seewald \(maseewal\)" , "Andrew.Free@sce.com" , "Madani, Vahid" , "Adamiak, Mark \(GE Energy Management\)" , "Novosel, Damir" , "Thanos, Daniel \(GE Energy Management\)" , "Alex Apostolov \(alex.apostolov@omicronusa.com\)" Subject: Re: [MSEC] Key Management protocol (GDOI - 6407) forward X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Nov 2013 12:18:25 -0000 --_000_418E74FA535F654FAB3CAAE12902E294015A2B47SISCOSBSsiscone_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable See below. Herbert Falk Solutions Architect SISCO, INC. 6605 19 =BD Mile Rd. Sterling Heights, MI 48314 (586) 254-0020 x-105 "In matters of style, swim with the current; in matters of principle, sta= nd like a rock." [Thomas Jefferson] NOTICE: This communication may contain privileged or other confidential inf= ormation. If you are not the intended recipient, or believe that you have = received this communication in error, please do not print, copy, retransmit= , disseminate, or otherwise use the information. Also, please indicate to= the sender that you have received this communication in error, and delete = the copy you received. Thank you. -----Original Message----- From: Yoav Nir [mailto:ynir@checkpoint.com] Sent: Sunday, November 03, 2013 1:44 AM To: Sean Turner Cc: msec@ietf.org; Jeff Gooding/SCE/EIX; Maik Seewald (maseewal); Andrew.Fr= ee@sce.com; Madani, Vahid; Adamiak, Mark (GE Energy Management); Novosel, D= amir; Thanos, Daniel (GE Energy Management); Herb Falk ;= Alex Apostolov (alex.apostolov@omicronusa.com) Subject: Re: [MSEC] Key Management protocol (GDOI - 6407) forward Hi As promised. See below. Sean, do you want me to post it like a SecDir rev= iew on the secdir/iesg/draft lists? On Sep 30, 2013, at 9:14 AM, Yoav Nir > wrote: > OK, I'll do it. > > At the latest, on the 20-hour journey to Vancouver. Hopefully earlier. > > Yoav > > On Sep 30, 2013, at 7:01 PM, Sean Turner > wrote: > >> IEC is usually paired with ISO ;) There's the rub right - I read it and= was like sure I take your word Brian. I think that you could treat it kin= d of like a secdir review and that would be sufficient for me. >> Hi, there. At Sean's request, I've done a SecDir-ish review of draft-weis-gdoi-iec6235= 1-9-02. I think it is in pretty good shape, but I do have some concerns. First, an apology: the draft embeds OIDs in IKE packets. Throughout this re= view I use the term "ASN.1" for both the objects and the encoding. I do rea= lize that ASN means abstract syntax notation, and that the correct term to = use for the encoding ia DER, but this is a very common misuse. The draft do= es get this correct. [Herb]: BER encoding is what was intended. I am somewhat confused by the IEC standards numbers. The abstract and intro= duction mostly discuss IEC 61850, which is the "power utility automation" f= amily of standards. On the other hand, the number in the title of the draft= is IEC 62351. There is a reference to a document called "IEC 62351 Part 9 = - Key Management". I can see how this draft relates to key management, but = "part 9" of what? [Herb]: I don't understand the question. So I will try to explain. IEC 6= 1850 is a set of communication standards developed under IEC Technical Comm= ittee 57. IEC TC57 has WG15 that was formed to address security for the br= eadth of standards that are developed under TC57, including IEC 61850. In = IEC, the designations within a family of standards (e.g. 61850 or 62351) ar= e called parts. IEC 61850 has over 10 standards that are 61850-1 through 6= 1850-10 (e.g. 10 parts). Chapters/sub-chapters are called "clauses" in IE= C. So when it mentions IEC 62351 Part 9 - Key Management, the official ref= erence is "IEC 62351-9 Ed. 1.0 Power systems management and associated inf= ormation exchange - Data and communications security - Part 9: Cyber securi= ty key management for power system equipment (Future IEC 62351-9 TS Ed.1)".= When IEC removes the ED 1.0, it means refer to the current revisions (ED.= 2 has almost been completed). The "Power systems management and associated= information exchange - Data and communications security" is the charter of= WG15 and the overall scope of 62351 (they all have that in their title). = Therefore, "IEC 62351 Part 9 - Key Management" could be referred to as "IEC= 62351-9", "IEC 62351-9 : Cyber security key management for power system eq= uipment", or in presentations "IEC 62351-9- Key Management". So, I would = change to IEC 62351-9 (and give the full name). Sorry for the long explana= tion. Another thing that's missing for me, as one uninitiated in the ways of the = IEC, is what are we negotiating keys for? I get that it's not IPsec, but at= the end of the protocol, we have keys that are distributed to group member= s. Now, what is this data layer that can now use them. A reference to some = standard ("IEC-61850-9-2" would be OK), but since these are not widely avai= lable, some short description of what this protocol looks like would be gre= at. [Herb]: The best I can do is to describe the use of the protocols. IEC 618= 50 is used for the command/control of the power grid. There are three prev= alent uses for 61850: peer-to-peer communication (e.g. client/server), mul= ticast for high speed state exchange and control (4msec time frame), sample= d values used for high speed Current Transformer/Voltage Transformer sample= s (this is a 15MB load per source/network). Additionally, IEC 61850-90-5 = is designed to route GOOSE and a lower speed SV used for synchrophasor meas= urements (some good information about synchrophasors can be found at: https= ://www.naspi.org/). Another generic comment is about the IANA considerations as well as parts o= f section 2.2. Why do we need to establish new registries, that are duplica= tes of IPsec registries with one additional value? I know there has been so= me resistance to adding things there for stuff that's "not IKE", but with t= his already done in RFC 6932 ([1],[2]), that ship has left the station afte= r the horses had bolted. [Herb]: If I understand the question, originally, we had used a "private" = value. It had been hoped that the IETF/IANA would provide a standard numbe= r. It is not semantically correct for IEC to claim IKE, when it is not. T= hat would cause confusion in the IEC standards. Obviously, this applicatio= n of GDOI was not anticipated and thus some type of expansion is needed. I= f IETF indicates that it won't extend for an IEC standard (e.g. only IETF s= tandards, that seem a bit odd. As with all standards, the sea of applicati= on is always changing and standards need to be changed to as the climate ch= anges. IEC has always referenced IETF RFCs. I can't officially speak on = behalf of IEC, but my personal opinion is that it is a bit strange to say t= he "ship has left the station" when a standards organization has a new use= case. Why is there an OID_LENGTH field? All ASN.1 structures are self-describing= in terms of length. There can be a good reason: so that you can implement = with a bitwise comparison rather than implementing an ASN.1 parser. Please = say so if that's the reason. [Herb]: There are several reasons to use the OID. One is that it allows o= ther smart grid applications/protocols to expand the usage of other domains= (e.g. avoid the "ship has left the station issue). The other is to specif= ically encode it so easy comparisons can occur. Hope that helps. I didn't quite get where each of the OIDs in the ID payload (figure 2) and = the TEK payload (figure 4) come from. Are they the same? Appendix A suggest= s that they're not. So, - what does "type of traffic" mean? - Appendix A says "OID=3D" in the TEK payload. What is k? [Herb]: The use of GDOI, for 90-5, is intended to have keys that are based= upon a combination of content/protocol/destination. There are 3 protocols= (CS, GOOSE, SV). All three define the content to be transferred to a part= icular destination as a set of Data called DataSets. SV and GOOSE can be s= ent via 90-5 or directly as an Ethertype. Therefore, the combinations/perm= utations lead to the following list in 90-5: 61850_ETHERNET_GOOSE Specifies that the payload is requesting a key for a IEC 61850-8-1 GOOSE AP= DU, with IEC 62351-6 signature, that is being sent to a particular destinat= ion Ethernet address. 1.2.840.10070.61850.8.1.1 61850_UDP_ADDR_GOOSE Specifies that the payload is requesting a key for a IEC 61850-90-5 GOOSE A= PDU that is being sent to a particular destination IP address. 1.2.840.10070.61850.8.1.2 61850_UDP _Tunnel Specifies that the payload is requesting a key for a IEC 61850-90-5 Tunnel = APDU that is being sent to a particular destination IP address. 1.2.840.10070.61850.8.1.4 61850_ETHERNET_SV Specifies that the payload is requesting a key for a IEC 61850-9-2 SV APDU,= with IEC 62351-6 signature, that is being sent to a particular destination= Ethernet address. 1.2.840.10070.61850.9.2.1 61850_UDP_ADDR_SV Specifies that the payload is requesting a key for a IEC 61850-90-5 SV APDU= that is being sent to a particular destination IP address. 1.2.840.10070.61850.9.2.2 61850_IP_ISO9506 Specifies that the payload is requesting a key for a IEC 61850-8-1 ISO 9506= endpoint. This payload definition is out-of-scope of this specification. 1.2.840.10070.61850.8.1.4 One last thing: KeyID is the SPI. This is explicitly said in 2.2.4, but men= tioned earlier in 2.2. Why is it 1 octet rather than 4? There is a ton of I= Psec library code that assumes SPI length to be 4. Are the three bytes wort= h it? [Herb]: If 4 is the normal, then lets make it 4. What is the value orderi= ng (Network transmission or other)? Yoav [1] http://www.iana.org/assignments/ipsec-registry/ipsec-registry.xhtml#ips= ec-registry-10 [2] http://tools.ietf.org/html/rfc6932 --_000_418E74FA535F654FAB3CAAE12902E294015A2B47SISCOSBSsiscone_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

See below.

 

Herbert Falk

Solutions Architect

SISCO, INC.

6605 19 =BD Mile Rd.

Sterling Heights, MI 48314

(586) 254-0020 x-105

 

 

        &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;       

"In matters of style, swim with the current;=    in matters of principle, stand like a rock." [Thomas Jeff= erson]

 

 

NOTICE: This communication may contain privileged= or other confidential information. If you are not the intended recipient, = or believe that you have  received this communication in error, please= do not print, copy, retransmit,  disseminate, or otherwise use the information. Also,  please indicate to the sende= r that you have received this communication in error, and delete the copy y= ou received. Thank you.

 

-----Original Message-----
From: Yoav Nir [mailto:ynir@checkpoint.com]
Sent: Sunday, November 03, 2013 1:44 AM
To: Sean Turner
Cc: msec@ietf.org; Jeff Gooding/SCE/EIX; Maik Seewald (maseewal); Andrew.Fr= ee@sce.com; Madani, Vahid; Adamiak, Mark (GE Energy Management); Novosel, D= amir; Thanos, Daniel (GE Energy Management); Herb Falk <herb@sisconet.co= m>; Alex Apostolov (alex.apostolov@omicronusa.com)
Subject: Re: [MSEC] Key Management protocol (GDOI - 6407) forward

 

Hi

 

As promised.  See below.  Sean, do you = want me to post it like a SecDir review on the secdir/iesg/draft lists?

 

On Sep 30, 2013, at 9:14 AM, Yoav Nir <ynir@checkpoint.com> wrote:

 

> OK, I'll do it.

>

> At the latest, on the 20-hour journey to Van= couver. Hopefully earlier.

>

> Yoav

>

> On Sep 30, 2013, at 7:01 PM, Sean Turner <= ;turners@ieca.com> wrote:

>

>> IEC is usually paired with ISO ;)  = There's the rub right - I read it and was like sure I take your word Brian.=   I think that you could treat it kind of like a secdir review and tha= t would be sufficient for me.

>>

 

 

 

Hi, there.

 

At Sean's request, I've done a SecDir-ish review = of draft-weis-gdoi-iec62351-9-02. I think it is in pretty good shape, but I= do have some concerns.

 

First, an apology: the draft embeds OIDs in IKE p= ackets. Throughout this review I use the term "ASN.1" for both th= e objects and the encoding. I do realize that ASN means abstract syntax not= ation, and that the correct term to use for the encoding ia DER, but this is a very common misuse. The draft does get = this correct.

 

[Herb]:  BER e= ncoding is what was intended.

 

I am somewhat confused by the IEC standards numbe= rs. The abstract and introduction mostly discuss IEC 61850, which is the &q= uot;power utility automation" family of standards. On the other hand, = the number in the title of the draft is IEC 62351. There is a reference to a document called "IEC 62351 Part 9 - = Key Management". I can see how this draft relates to key management, b= ut "part 9" of what?

 

[Herb]:&nbs= p; I don’t understand the question.  So I will try to explain.&n= bsp; IEC 61850 is a set of communication standards developed under IEC Tech= nical Committee 57.  IEC TC57 has WG15 that was formed to address security for the breadth of standards that are developed under TC5= 7, including IEC 61850.  In IEC, the designations within a family of s= tandards (e.g. 61850 or 62351) are called parts.  IEC 61850 has over 1= 0 standards that are 61850-1 through 61850-10 (e.g. 10 parts).   Chapters/sub-chapters are called “claus= es” in IEC.  So when it mentions IEC 62351 Part 9 – Key Ma= nagement, the official reference is  “IEC 62351-9 Ed. 1.0 Power = systems management and associated information exchange - Data and communica= tions security - Part 9: Cyber security key management for power system equipmen= t (Future IEC 62351-9 TS Ed.1)”.  When IEC removes the ED 1.0, i= t means refer to the current revisions (ED.2 has almost been completed).&nb= sp; The “Power systems management and associated information exchange - Data and communications security” is the char= ter of WG15 and the overall scope of 62351 (they all have that in their tit= le).  Therefore, “IEC 62351 Part 9 – Key Management”= could be referred to as “IEC 62351-9”, “IEC 62351-9 : Cy= ber security key management for power system equipment”, or in presentat= ions “IEC 62351-9– Key Management”.   So, I wou= ld change to IEC 62351-9 (and give the full name).  Sorry for the long= explanation.

 

 

Another thing that's missing for me, as one unini= tiated in the ways of the IEC, is what are we negotiating keys for? I get t= hat it's not IPsec, but at the end of the protocol, we have keys that are d= istributed to group members. Now, what is this data layer that can now use them. A reference to some standar= d ("IEC-61850-9-2" would be OK), but since these are not widely a= vailable, some short description of what this protocol looks like would be = great.

 

[Herb]: The best I = can do is to describe the use of the protocols.  IEC 61850 is used for= the command/control of the power grid.  There are three prevalent use= s for 61850:  peer-to-peer communication (e.g. client/server), multicast for high speed state exchange and control (4msec= time frame), sampled values used for high speed Current Transformer/Voltag= e Transformer samples  (this is a 15MB load per source/network). = Additionally, IEC 61850-90-5 is designed to route GOOSE and a lower speed SV used for synchrophasor measurements (s= ome good information about synchrophasors can be found at: https://www.nasp= i.org/).

 

Another generic comment is about the IANA conside= rations as well as parts of section 2.2. Why do we need to establish new re= gistries, that are duplicates of IPsec registries with one additional value= ? I know there has been some resistance to adding things there for stuff that's "not IKE", but with this= already done in RFC 6932 ([1],[2]), that ship has left the station after t= he horses had bolted.

 

[Herb]:  If I = understand the question, originally, we had used a “private” va= lue.  It had been hoped that the IETF/IANA would provide a standard nu= mber.  It is not semantically correct for IEC to claim IKE, when it is not.  That would cause confusion in the IEC standards.&nbs= p; Obviously, this application of GDOI was not anticipated and thus some ty= pe of expansion is needed.  If IETF indicates that it won’t exte= nd for an IEC standard (e.g. only IETF standards, that seem a bit odd.  As with all standards, the sea of application is alw= ays changing and standards need to be changed to as the climate changes.&nb= sp; IEC has always referenced IETF  RFCs.  I can’t official= ly speak on behalf of IEC, but my personal opinion is that it is a bit strange to say the “ship has left the station”&nbs= p; when a standards organization has a new use case.

 

Why is there an OID_LENGTH field?  All ASN.1= structures are self-describing in terms of length. There can be a good rea= son: so that you can implement with a bitwise comparison rather than implem= enting an ASN.1 parser. Please say so if that's the reason.

 

[Herb]:  There= are several reasons to use the OID.  One is that it allows other smar= t grid applications/protocols to expand the usage of other domains (e.g. av= oid the “ship has left the station issue).  The other is to specifically encode it so easy comparisons can occur.  Ho= pe that helps.

 

I didn't quite get where each of the OIDs in the = ID payload (figure 2) and the TEK payload (figure 4) come from. Are they th= e same? Appendix A suggests that they're not. So,

- what does "type of traffic" mean?&nbs= p;

  - Appendix A says "OID=3D<ASN= .1 for k>" in the TEK payload. What is k?

 

[Herb]:  The u= se of GDOI, for 90-5, is intended to have keys that are based upon a combin= ation of content/protocol/destination.  There are 3 protocols (CS, GOO= SE, SV).  All three define the content to be transferred to a particular destination as a set of Data called DataSets.  SV and= GOOSE can be sent via 90-5 or directly as an Ethertype.  Therefore, t= he combinations/permutations lead to the following list in 90-5:=

 

61850_= ETHERNET_GOOSE

Specif= ies that the payload is requesting a key for a IEC 61850-8-1 GOOSE APD= U, with IEC 62351-6 signature, that is being sent to a particular dest= ination Ethernet address.

1.2.84= 0.10070.61850.8.1.1

61850_= UDP_ADDR_GOOSE

Specif= ies that the payload is requesting a key for a IEC 61850-90-5 GOOSE AP= DU that is being sent to a particular destination IP address.

1.2.84= 0.10070.61850.8.1.2

61850_= UDP _Tunnel

Specif= ies that the payload is requesting a key for a IEC 61850-90-5 Tunnel A= PDU that is being sent to a particular destination IP address.

1.2.84= 0.10070.61850.8.1.4

61850_= ETHERNET_SV

Specif= ies that the payload is requesting a key for a IEC 61850-9-2 SV APDU, = with IEC 62351-6 signature, that is being sent to a particular destina= tion Ethernet address.

1.2.84= 0.10070.61850.9.2.1

61850_= UDP_ADDR_SV

Specif= ies that the payload is requesting a key for a IEC 61850-90-5 SV APDU = that is being sent to a particular destination IP address.

1.2.84= 0.10070.61850.9.2.2

61850_= IP_ISO9506

Specif= ies that the payload is requesting a key for a IEC 61850-8-1 ISO 9506 = endpoint. This payload definition is out-of-scope of this specification.

1.2.84= 0.10070.61850.8.1.4

 

 

One last thing: KeyID is the SPI. This is explici= tly said in 2.2.4, but mentioned earlier in 2.2. Why is it 1 octet rather t= han 4? There is a ton of IPsec library code that assumes SPI length to be 4= . Are the three bytes worth it?

 

[Herb]:  If 4 = is the normal, then lets make it 4.  What is the value ordering (Netwo= rk transmission or other)?

 

Yoav

 

[1] http://www.iana.org/a= ssignments/ipsec-registry/ipsec-registry.xhtml#ipsec-registry-10=

[2] http://tools.ietf.o= rg/html/rfc6932      

 

 

 

 

 

 

 

--_000_418E74FA535F654FAB3CAAE12902E294015A2B47SISCOSBSsiscone_--