From bew@cisco.com Fri Aug 2 12:28:05 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 3A90311E80E7 for ; Fri, 2 Aug 2013 12:28:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.754 X-Spam-Level: X-Spam-Status: No, score=-111.754 tagged_above=-999 required=5 tests=[AWL=0.845, BAYES_00=-2.599, GB_I_INVITATION=-2, RCVD_IN_DNSWL_HI=-8, 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 RQlAmUQ4IBEQ for ; Fri, 2 Aug 2013 12:28:00 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 83E3E11E80C5 for ; Fri, 2 Aug 2013 12:28:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2058; q=dns/txt; s=iport; t=1375471680; x=1376681280; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=ARk1Sh1QOuEwZxtz3SPmridBwHSqzp/g4zUCgg3vMxo=; b=ehHHNmnwysZPkg3MDkOuIdKqJlTxzclE1vxaQKNSyI4ce1Q0TyBeJ0p6 sTyljEjaJMa/4dZnVCVWFMkSNPdEIYPBcq0jx75AV69E817MpNPnCAJ9l +jPh/0y7LFEmxl1jcyGV0RQD3AOULrhqxKCClL9vxvgoXJOYtCCMISf2I I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AloHANEH/FGrRDoI/2dsb2JhbABXA4MGNatLlAiBHhZ0giQBAQEDATo/BQsLRlcZiAoFDbkJjlARgQQjEAcRBYMDdAOXX4EqkCSDGTqBNQ X-IronPort-AV: E=Sophos;i="4.89,803,1367971200"; d="scan'208";a="85209342" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-1.cisco.com with ESMTP; 02 Aug 2013 19:27:59 +0000 Received: from sjc-vpn3-711.cisco.com (sjc-vpn3-711.cisco.com [10.21.66.199]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r72JRtLu002522 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 2 Aug 2013 19:27:57 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Brian Weis In-Reply-To: <3CB35FCD-F9EA-4361-B290-3CBBE087C3B8@cisco.com> Date: Fri, 2 Aug 2013 21:27:55 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <5C96E649-6CF5-450E-9787-2C51D76DF2A5@cisco.com> References: <3CB35FCD-F9EA-4361-B290-3CBBE087C3B8@cisco.com> To: msec@ietf.org X-Mailer: Apple Mail (2.1503) Cc: draft-weis-gdoi-iec62351-9@tools.ietf.org, Sean Turner Subject: Re: [MSEC] GDOI support for IEC 62351 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: Fri, 02 Aug 2013 19:28:05 -0000 Folks, 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. 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=20 On Jul 23, 2013, at 1:56 AM, Brian Weis wrote: > 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 Brian Weis Security, Enterprise Networking Group, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com From steffen.fries@siemens.com Tue Aug 6 01:35:22 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 9AE3F21F9AE3 for ; Tue, 6 Aug 2013 01:35:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.249 X-Spam-Level: X-Spam-Status: No, score=-12.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_INVITATION=-2, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wODXY+CUrtsB for ; Tue, 6 Aug 2013 01:35:17 -0700 (PDT) Received: from lizzard.sbs.de (lizzard.sbs.de [194.138.37.39]) by ietfa.amsl.com (Postfix) with ESMTP id A4CCB21F90CC for ; Tue, 6 Aug 2013 01:35:15 -0700 (PDT) Received: from mail2.sbs.de (localhost [127.0.0.1]) by lizzard.sbs.de (8.13.6/8.13.6) with ESMTP id r768Z7Rb030633; Tue, 6 Aug 2013 10:35:09 +0200 Received: from defthw99et6msx.ww902.siemens.net ([157.163.148.61]) by mail2.sbs.de (8.13.6/8.13.6) with ESMTP id r768Z6JJ028644 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 6 Aug 2013 10:35:07 +0200 Received: from DENBGAT9ERCMSX.ww902.siemens.net (139.22.70.82) by DEFTHW99ET6MSX.ww902.siemens.net (157.163.148.61) with Microsoft SMTP Server (TLS) id 8.3.298.1; Tue, 6 Aug 2013 10:35:06 +0200 Received: from DENBGAT9EH2MSX.ww902.siemens.net ([169.254.6.86]) by DENBGAT9ERCMSX.ww902.siemens.net ([139.22.70.82]) with mapi id 14.03.0146.000; Tue, 6 Aug 2013 10:35:06 +0200 From: "Fries, Steffen" To: Brian Weis , "msec@ietf.org" Thread-Topic: Review comments, was RE: [MSEC] GDOI support for IEC 62351 Thread-Index: AQHOj7Z3AbSbgsEbm0iv4yUajEgAMpmHvMjQ Date: Tue, 6 Aug 2013 08:35:05 +0000 Message-ID: References: <3CB35FCD-F9EA-4361-B290-3CBBE087C3B8@cisco.com> <5C96E649-6CF5-450E-9787-2C51D76DF2A5@cisco.com> In-Reply-To: <5C96E649-6CF5-450E-9787-2C51D76DF2A5@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [139.22.70.9] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-weis-gdoi-iec62351-9@tools.ietf.org" , Sean Turner Subject: [MSEC] Review comments, was RE: GDOI support for IEC 62351 X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 08:35:22 -0000 Hi Brian, Thank you for compiling the draft. Meanwhile I had the chance to review the= current draft. Most of the comments I have are actually more editorial nit= s 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 def= ined for IEC 61850 protection. All in all we have definitions for ID, SA TE= K, 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 les= s 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 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 wil= l be included in IEC 62351-6)=20 and may be used for integrity protection and/or confidentiality protectio= n. Section 2.2.3 (page 9) - There are two confidentiality algorithms defined. Both are AES-CBC with d= ifferent key length. IEC 61850-90-5 specifies AES-GCM with the two stated key length. This sho= uld be double checked. 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 defin= ed integrity algorithm=20 - TEK_ALGORITHM_KEY if the key is associated with an IEC 61850-90-5 defin= ed confidentiality algorithm I would suggest to rename the TEK_ALGORITHM_KEY to TEK_CONFIDENTIALITY_KE= Y 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"? =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 shou= ld be verified. Okay so far for the review. As I said, mostly editorial. Regards Steffen =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 Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Gerhard Crom= me; Managing Board: Joe Kaeser, Chairman, President and Chief Executive Off= icer; Roland Busch, Brigitte Ederer, Klaus Helmrich, Barbara Kux, Hermann R= equardt, Siegfried Russwurm, Peter Y. Solmssen, Michael Suess; Registered o= ffices: Berlin and Munich, Germany; Commercial registries: Berlin Charlotte= nburg, HRB 12300, Munich, HRB 6684; WEEE-Reg.-No. DE 23691322=20 -----Original Message----- From: msec-bounces@ietf.org [mailto:msec-bounces@ietf.org] On Behalf Of Bri= an 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: . GDOI implementers should note= that both RFC 3547 and RFC 6407 relied upon the ID Types defined in the IP= sec DOI, which wasn't quite the right thing to do. So please note that Sect= ion 4 (IANA Considerations) now adds a registry of ID types for the GDOI DO= I. 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 th= e new ID type added. So all of the old values are still valid, they are jus= t administratively defined in the GDOI IANA registry now rather than the IP= sec 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=20 On Jul 23, 2013, at 1:56 AM, Brian Weis wrote: > 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. Th= e keys protect multicast traffic streams sent by devices monitoring the pow= er 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 t= he new definitions, which are defined in . Since the MSEC WG is not currently active, we hop= e to progress the draft as an individual submission soon and would apprecia= te any feedback. If you have comments, please post them to the MSEC list (m= sec@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 Brian Weis Security, Enterprise Networking Group, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com _______________________________________________ MSEC mailing list MSEC@ietf.org https://www.ietf.org/mailman/listinfo/msec From steffen.fries@siemens.com Tue Aug 6 23:11:08 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 9C63B11E810F for ; Tue, 6 Aug 2013 23:11:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.249 X-Spam-Level: X-Spam-Status: No, score=-12.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_INVITATION=-2, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VD2zdRdSO+2z for ; Tue, 6 Aug 2013 23:11:03 -0700 (PDT) Received: from lizzard.sbs.de (lizzard.sbs.de [194.138.37.39]) by ietfa.amsl.com (Postfix) with ESMTP id DD0CE21F997E for ; Tue, 6 Aug 2013 23:11:02 -0700 (PDT) Received: from mail1.sbs.de (localhost [127.0.0.1]) by lizzard.sbs.de (8.13.6/8.13.6) with ESMTP id r776AtXP015125; Wed, 7 Aug 2013 08:10:56 +0200 Received: from DEFTHW99ET9MSX.ww902.siemens.net ([157.163.148.60]) by mail1.sbs.de (8.13.6/8.13.6) with ESMTP id r776AsLw013859 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 7 Aug 2013 08:10:54 +0200 Received: from DENBGAT9ERKMSX.ww902.siemens.net (139.22.70.145) by DEFTHW99ET9MSX.ww902.siemens.net (157.163.148.60) with Microsoft SMTP Server (TLS) id 8.3.298.1; Wed, 7 Aug 2013 08:10:54 +0200 Received: from DEFTHW99EH4MSX.ww902.siemens.net ([169.254.2.80]) by DENBGAT9ERKMSX.ww902.siemens.net ([139.22.70.145]) with mapi id 14.03.0146.000; Wed, 7 Aug 2013 08:10:54 +0200 From: "Fries, Steffen" To: Brian Weis , "msec@ietf.org" Thread-Topic: [MSEC] Review comments, was RE: GDOI support for IEC 62351 Thread-Index: AQHOkzTfq63b70hJh0mz+m2CyFlTkg== Date: Wed, 7 Aug 2013 06:10:53 +0000 Message-ID: References: <3CB35FCD-F9EA-4361-B290-3CBBE087C3B8@cisco.com> <5C96E649-6CF5-450E-9787-2C51D76DF2A5@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [139.22.70.54] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-weis-gdoi-iec62351-9@tools.ietf.org" , Sean Turner Subject: Re: [MSEC] Review comments, was RE: GDOI support for IEC 62351 X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2013 06:11:08 -0000 Hi Brian, While re-reading my message I realized that I was only focused on the conte= nt 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 discu= ssed different approaches of securing this type of communication and the gr= oup-based approach based on GDOI was the one that coped best with the requi= rements. Hence, having this draft ensures the applicability within IEC 6235= 1 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 Fri= es, 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 nit= s 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 def= ined for IEC 61850 protection. All in all we have definitions for ID, SA TE= K, 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 les= s 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 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 wil= l be included in IEC 62351-6)=20 and may be used for integrity protection and/or confidentiality protectio= n. Section 2.2.3 (page 9) - There are two confidentiality algorithms defined. Both are AES-CBC with d= ifferent key length. IEC 61850-90-5 specifies AES-GCM with the two stated key length. This sho= uld be double checked. 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 defin= ed integrity algorithm=20 - TEK_ALGORITHM_KEY if the key is associated with an IEC 61850-90-5 defin= ed confidentiality algorithm I would suggest to rename the TEK_ALGORITHM_KEY to TEK_CONFIDENTIALITY_KE= Y 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"? =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 shou= ld be verified. Okay so far for the review. As I said, mostly editorial. Regards Steffen =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 Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Gerhard Crom= me; Managing Board: Joe Kaeser, Chairman, President and Chief Executive Off= icer; Roland Busch, Brigitte Ederer, Klaus Helmrich, Barbara Kux, Hermann R= equardt, Siegfried Russwurm, Peter Y. Solmssen, Michael Suess; Registered o= ffices: Berlin and Munich, Germany; Commercial registries: Berlin Charlotte= nburg, HRB 12300, Munich, HRB 6684; WEEE-Reg.-No. DE 23691322=20 -----Original Message----- From: msec-bounces@ietf.org [mailto:msec-bounces@ietf.org] On Behalf Of Bri= an 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: . GDOI implementers should note= that both RFC 3547 and RFC 6407 relied upon the ID Types defined in the IP= sec DOI, which wasn't quite the right thing to do. So please note that Sect= ion 4 (IANA Considerations) now adds a registry of ID types for the GDOI DO= I. 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 th= e new ID type added. So all of the old values are still valid, they are jus= t administratively defined in the GDOI IANA registry now rather than the IP= sec 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=20 On Jul 23, 2013, at 1:56 AM, Brian Weis wrote: > 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. Th= e keys protect multicast traffic streams sent by devices monitoring the pow= er 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 t= he new definitions, which are defined in . Since the MSEC WG is not currently active, we hop= e to progress the draft as an individual submission soon and would apprecia= te any feedback. If you have comments, please post them to the MSEC list (m= sec@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 Brian Weis Security, Enterprise Networking Group, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com _______________________________________________ MSEC mailing list MSEC@ietf.org https://www.ietf.org/mailman/listinfo/msec _______________________________________________ MSEC mailing list MSEC@ietf.org https://www.ietf.org/mailman/listinfo/msec From magnus.westerlund@ericsson.com Mon Aug 26 02:46:49 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 03E8B11E8181 for ; Mon, 26 Aug 2013 02:46:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.592 X-Spam-Level: X-Spam-Status: No, score=-105.592 tagged_above=-999 required=5 tests=[AWL=0.657, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, 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 LqGSiNILL887 for ; Mon, 26 Aug 2013 02:46:42 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 57CED11E812F for ; Mon, 26 Aug 2013 02:46:35 -0700 (PDT) X-AuditID: c1b4fb2d-b7f738e000003ee3-41-521b23f935b7 Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 2E.0E.16099.9F32B125; Mon, 26 Aug 2013 11:46:33 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.17) by smtp.internal.ericsson.com (153.88.183.53) with Microsoft SMTP Server id 14.2.328.9; Mon, 26 Aug 2013 11:46:32 +0200 Message-ID: <521B243F.1010405@ericsson.com> Date: Mon, 26 Aug 2013 11:47:43 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: References: <521B211E.4010707@ericsson.com> In-Reply-To: <521B211E.4010707@ericsson.com> X-Enigmail-Version: 1.5.2 X-Forwarded-Message-Id: <521B211E.4010707@ericsson.com> Content-Type: multipart/mixed; boundary="------------040707040005000800030004" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrHKsWRmVeSWpSXmKPExsUyM+Jvje5PZekggxWnjS3OvDjI5MDosWTJ T6YAxigum5TUnMyy1CJ9uwSujN1L5QveW1Xs+HOIsYHxkUkXIyeHhICJxIR5exkhbDGJC/fW s3UxcnEICRxmlGi+2A2WEBJYxijx7HQ1iM0roC0x79ROZhCbRUBV4teeGSwgNpuAhcTNH41s ILaoQLBE+/avbBD1ghInZz4BqxEREJbYfP4kO4gtLOAusfT5N1aI+doSZw5cArM5BXQkWqf+ ZYc4SFJi26JjULa5xP19V8H2MgsESCw+epQRprehqYN1AqPgLCTrZiEpg7D1JKZcbYGy5SW2 v53DDGGnSDSfeYpFvE6it/cK+yyw1fwS7afPAMVB4bKRUeJ6y3QmCGcXo8SbbaugMlMYJW5s fwKWYRH4wixx/fc1Noh+RYm+RRPAZrEIKEjMbmhghOhYzSjxdPMKZogiDYkZKy8AJTjAFq49 pDwLGid9Z5tZIWxeidNTjkPNXMIoceCHPsSc84wSj0+dY4Vw9jFKfJy2EqrDROLFuUdsEImj QJdv7ISqWs4osanlJuMsaJTeWDeJaRY0Sru3zQGzYVE6CxyloRKb9s0HO1VEQElix6RtUGdD oghkqITAfk6Ja293sS1gNFnFyJ6bmJmTXm64iRGYRg9u+a27g/HUOZFDjNIcLErivJv0zgQK CaQnlqRmp6YWpBbFF5XmpBYfYmTi4JRqYJTv7vqdHbnQMrTePdL0t0DAR3XpEButFi4V0XhZ NS/RtAwWmchpUVs117Uv6ja+I5bSu4X9rUrn7Oi1D2X3Put6wnQ4kuHf8ncT92jta+aN/uwU l93GOtfoftzsW6EznD67m/zfz+kVJOQZVn/v7cUrWevtpxyb/S4qWuefW2fpUfdW8UxNJZbi jERDLeai4kQA2PJ5mHEDAAA= Subject: [MSEC] Fwd: [AVTCORE] WG last call on draft-ietf-avtcore-aria-srtp-04 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: Mon, 26 Aug 2013 09:46:49 -0000 --------------040707040005000800030004 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Hi MSEC people, If there is still any people on this list, I like to inform you about this AVTCORE WG last call where a new SRTP crypto transform registers the crypto transform for use with MIKEY. IF anyone has time to look at it would be greatly appreciated. Thanks Magnus Westerlund AVTCORE WG chair --------------040707040005000800030004 Content-Type: message/rfc822; name="[AVTCORE] WG last call on draft-ietf-avtcore-aria-srtp-04.eml" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename*0="[AVTCORE] WG last call on draft-ietf-avtcore-aria-srtp-04.em"; filename*1="l" X-Mozilla-Keys: Received: from sessmg10.ericsson.net (153.88.183.147) by smtp.internal.ericsson.com (153.88.183.76) with Microsoft SMTP Server id 14.2.328.9; Mon, 26 Aug 2013 11:34:36 +0200 Received: from mail.ietf.org (mail.ietf.org [12.22.58.30]) by sessmg10.ericsson.net (Symantec Mail Security) with SMTP id DC.2B.05165.B212B125; Mon, 26 Aug 2013 11:34:35 +0200 (CEST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A720911E8179; Mon, 26 Aug 2013 02:34:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1377509671; bh=kH6GpNK7VmAKFY3xjt6qoL7fnxZoWks6Yh0wAo2kKe4=; h=Message-ID:Date:From:MIME-Version:To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=t9A4uQK5pqLMtUlV18CZrampTBynSIoc1WamdT4kc+Wf9h9Cozy6sfDbfKEdVE/XW rZ3/2wD3jQzDjON2f0UQSUhBM87Pu4YVscXMbnIix56M45s12cUzR20q5uvBGhq5YQ BaqHWHAiJ/1hvZYBbcmJyoZJ5roBtFYC0zjqsejo= X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C409921F99E8 for ; Mon, 26 Aug 2013 02:33:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.569 X-Spam-Level: X-Spam-Status: No, score=-105.569 tagged_above=-999 required=5 tests=[AWL=0.680, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, 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 sg5p96d1+rQ5 for ; Mon, 26 Aug 2013 02:33:45 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 3FF3A11E8183 for ; Mon, 26 Aug 2013 02:33:17 -0700 (PDT) X-AuditID: c1b4fb3e-b7f808e00000142d-79-521b212a6eca Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id DF.6C.16099.7D02B125; Mon, 26 Aug 2013 11:33:12 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.148) by smtp.internal.ericsson.com (153.88.183.62) with Microsoft SMTP Server id 14.2.328.9; Mon, 26 Aug 2013 11:33:11 +0200 Message-ID: <521B211E.4010707@ericsson.com> Date: Mon, 26 Aug 2013 11:34:22 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 To: IETF AVTCore WG X-Enigmail-Version: 1.5.2 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrBJsWRWlGSWpSXmKPExsXCI2Ylp6utKB1kcGmXkUXT3S3sFhdmHma0 2HSzwGLT8pVMFu+uH2W36F05j9Xixol2JoutvQ2sFhdO/mG2uLT+HpPFzLnxFndW3mK0mPsz 0KL3ehOLxYFbjewW+w98Y7O49/Mrm8X0VluLI6feMTsIe/z6epUtgDGKyyYlNSezLLVI3y6B K+PG1e0sBVc4K5b8+83awDiBo4uRk0NCwETixblHbBC2mMSFe+uBbC4OIYEdjBJ/ls9hgnCm MUq8aDkH5rAIfGGWuP77GlSLokTfognsIDaLgILE7IYGRoiO1YwSe37ugSrSkJix8gJQggPI 5pdYe0gZZl3f2WZWCJtP4uKLH0wQ9hJGiQM/9CHmXGSUuLXvAAuEs49RYsORtcwwh8+YuBVq 21FGiY6/nVDOckaJY0umgc3lFdCWuLFuEhPEfaoS3dvmgNlsAhYSN380gp0nKhAqsWnffGaI ekGJkzOfsIDYIgJKEjsmbYPaJimxbdExdpAFEgKzWCVeTPnKCJIQFnCSuPv0MBtM0e19Lxlh 7K7eJ+CAERAQkJi3ZCfYYh4BO4kb27+yQtiFEtOObmWawKgxC8luEJtZQE/ixtQpbBC2tsSy ha+ZFzAyr2IULU4tLs5NNzTQSy3KTC4uzs/Ty0st2cQITF4Ht/y228F47aHhIUZJDiYlUd6V 8tJBQnxJ+SmVGYnFGfFFpTmpxYcYpTlYlMR5LTTOBAoJpCeWpGanphakFsFkZTg4lCR494F0 ChalpqdWpGXmlCCkmTg4DzFKcPAoifCuAanhLS5IzC3OTIfIn2JUlBLnPQCSEABJZJTmwfXC MsAlRlkpYV5GBgYGIR6gvbmZJajyrxjFORiVhHlngkzhycwrgZv+CmgxE9Dig8slQRaXJCKk pBoY1ymVHM7OiJSPs51ideziGktpV5WL23tczffP/9LsraHif6RkftVC7dhdc74tzllqayUq IOL8edW5Z9+mKV03940y9+pTdUmW+2ek2Ms5Q7+xd+vMpV9WVd2PF2rz5i39d70umylSttlL +4z8kRyVipvp7DoTWQLvlHn4/4zQ3y5X+PNBVpoSS3FGoqEWc1FxIgBWTnhz+wMAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrEJMWRmVeSWpSXmKPExsUyM+Jvje4NBekgg/a3XBYve1ayOzB6LFny kymAMYrLJiU1J7MstUjfLoErY/GlnIJ9HBWHFrYyNTC2sncxcnJICJhIzJi4lRHCFpO4cG89 WxcjF4eQwGFGiTUPJzNCOMsZJebsfwfWwSugLXFj3SQmEJtFQFWie9scMJtNwELi5o9GNhBb VCBYon37VzaIekGJkzOfsIDYIgJKEjsmbWMGsYWB6jfMbWSC2CwpsW3RMbD5zAJ6ElOutjBC 2PISzVtng9ULAe1taOpgncDIPwvJ2FlIWmYhaVnAyLyKkT03MTMnvdxwEyMwnA5u+a27g/HU OZFDjNIcLErivJv0zgQKCaQnlqRmp6YWpBbFF5XmpBYfYmTi4JRqYHSKTZ/Dckj00zbLYK7C HOUdHG0Fh4P+ekcF5h//HKDZubs/oiNfcIZR/M1U2eQ5DT/D5ku9LUtcdDGxvNZjo4FIhdTE v2+0j1vsuLjZK+Rn9vKGyzN6Fp5+qcz2KNAkPGwOx7ILSacmarrqTjidwPTigV3DbL8nEafC fYuPMRjX1UyaKZe/WYmlOCPRUIu5qDgRANvKMMj1AQAA Subject: [AVTCORE] WG last call on draft-ietf-avtcore-aria-srtp-04 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: Errors-To: avt-bounces@ietf.org Return-Path: avt-bounces@ietf.org X-MS-Exchange-Organization-AuthSource: ESESSHC019.ericsson.se X-MS-Exchange-Organization-AuthAs: Anonymous X-MS-Exchange-Organization-AVStamp-Mailbox: MSFTFF;1;0;0 0 0 MIME-Version: 1.0 WG, This starts the WG last call on draft-ietf-avtcore-aria-srtp-04 to be published as proposed standard. Please provide any feedback or review comments by September 16. Even if you have just read it and found no issue, please state so. Draft: https://datatracker.ietf.org/doc/draft-ietf-avtcore-aria-srtp In addition any comments about current or planned implementation of this draft are appreciated. As a WG chair I really want some persons that really understand crypto algorithms and/or the key-management mechanisms used to review this and will solicit reviews outside of the WG also. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 F=E4r=F6gatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ Audio/Video Transport Core Maintenance avt@ietf.org https://www.ietf.org/mailman/listinfo/avt --------------040707040005000800030004--