From bew@cisco.com Fri Oct 11 13:58:13 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 0E24D11E80EC for ; Fri, 11 Oct 2013 13:58:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 ef-OkVTBnW-v for ; Fri, 11 Oct 2013 13:58:00 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id E739F21F9BC2 for ; Fri, 11 Oct 2013 13:57:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6103; q=dns/txt; s=iport; t=1381525079; x=1382734679; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=YG8JD735ISPGbui2lLjoe47qmAD09RiSpMkoF0Ii8eQ=; b=WUwhUCzgihSaPsVh4pizJOMLHYo6fBXV8THaYjF05aF0izCTxIDTrV9Y 63Y8SLleVqunwotTdy8kwCjYP7tR/YbHoj/Z1zciJcQoa2icZnsgDezCZ suMGq7EUatUPXXxXnAjAvIvIzUDulTwzARzXyINEFodhzjqK7PhtSSwlv E=; X-IronPort-AV: E=Sophos;i="4.93,1082,1378857600"; d="scan'208";a="91947540" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-3.cisco.com with ESMTP; 11 Oct 2013 20:57:58 +0000 Received: from dhcp-128-107-151-21.cisco.com (dhcp-128-107-151-21.cisco.com [128.107.151.21]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r9BKvv5H028858 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 11 Oct 2013 20:57:57 GMT Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Brian Weis In-Reply-To: <85CF9F24-C02C-491D-A000-487B7A524F97@checkpoint.com> Date: Fri, 11 Oct 2013 13:57:59 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <5065EAC9-B10D-47AB-B2EA-96E9FBC20935@cisco.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> To: Yoav Nir X-Mailer: Apple Mail (2.1508) Cc: "msec@ietf.org" , Jeff Gooding/SCE/EIX , Herb Falk , "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: Fri, 11 Oct 2013 20:58:13 -0000 Many thanks, Yoav & Sean. Brian =20 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 kind of like a secdir review and that would be sufficient for me. >>=20 >> spt >>=20 >> On 9/30/13 11:52 AM, Yoav Nir wrote: >>> I could, I guess. >>>=20 >>> Does it matter if prior to reading it I have never heard of IEC = 62351-9 in particular, or IEC in general? >>>=20 >>> Yoav >>>=20 >>> On Sep 30, 2013, at 6:26 PM, Sean Turner wrote: >>>=20 >>>> For the record Brian has approached me about AD-sponsoring = draft-weis-gdoi-iec62351-9-02. I don't think it's actually an update of = 6407 it's more of here's how IEC 62351 would use RFC 6407. >>>>=20 >>>> After talking with Brian in Berlin, I have but one dilemma = AD-sponsoring such a draft is that it is intended for proposed standard = and as best I can tell there's been one review (thanks Steffan). = Knowing that the msec community in the IETF is pretty small this might = be a tall order, but is there anybody else out there will to give it a = review? (cough, hint) Yoav, Vincent :) >>>>=20 >>>> spt >>>>=20 >>>> On 9/27/13 4:01 PM, William Atwood wrote: >>>>> Actually, he is probably referring to the "6407 update draft", = which is >>>>> draft-weis-gdoi-iec62351-9-02. This is an update to 6407 = precisely to >>>>> serve the IEC needs. I suspect that the email is a plea for fast = action >>>>> on progressing draft-weis to RFC. >>>>>=20 >>>>> Bill >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On 27/09/2013 1:18 PM, Yoav Nir wrote: >>>>>> Hi >>>>>>=20 >>>>>> Just to be clear, there is no such thing as a "draft RFC". Drafts >>>>>> become RFCs, at which point they're done. You may be referring to = the >>>>>> fact that RFC 6407 is labeled "proposed standard". This is a = label >>>>>> that the IETF attaches to documents for which there is relatively >>>>>> little implementation experience. The label is not automatically >>>>>> changed after a while. Even things that are widely implemented = and >>>>>> used by millions such as IKEv2 (RFC 5996), IPsec (RFC 4301), TLS = (RFC >>>>>> 5246), and HTTP (RFC 2616), without a doubt the most popular = protocol >>>>>> on the Internet) is at "draft standard" - a classification that = does >>>>>> not exist any more, but was below "full standard". >>>>>>=20 >>>>>> I'm adding Sean Turner, the Security Area Director, because he's = been >>>>>> handling many similar requests recently. >>>>>>=20 >>>>>> Hope this helps >>>>>>=20 >>>>>> Yoav >>>>>>=20 >>>>>> On Sep 27, 2013, at 5:15 AM, Herb Falk >>>>> > >>>>> > wrote: >>>>>>=20 >>>>>>> IEC TC57 WG10 (61850) and IEC TC57 WG15 (Security) has been >>>>>>> developing a technology/standard for use as a secure multicast = for >>>>>>> its use in power grid applications using synchrophasors and = other >>>>>>> technologies relevant to smartgrid deployments globally. >>>>>>> As part of the effort, some extensions to GDOI were identified. = The >>>>>>> 6407 draft incorporates and improves some of the enhancements = already >>>>>>> identified. IEC TC57 WG15 is waiting for the draft RFC to = transition >>>>>>> to an RFC so it can be referenced as a normative standard in IEC = 62351-9. >>>>>>> There are several utility vendors and utilities, in particular = SCE >>>>>>> (Southern California Edison), that are awaiting this transition = so >>>>>>> that their cyber security frameworks can be updated. Delays in = the >>>>>>> transition from draft to RFC will delay implementation of = several >>>>>>> projects and implementations. >>>>>>> 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, stand like a rock." [Thomas Jefferson] >>>>>>> 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. >>>>>>> = ------------------------------------------------------------------------ >>>>>>> _______________________________________________ >>>>>>> MSEC mailing list >>>>>>> MSEC@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/msec >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> MSEC mailing list >>>>>> MSEC@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/msec >>>>>=20 >>>>> -- >>>>> Dr. J.W. Atwood, Eng. tel: +1 (514) 848-2424 x3046 >>>>> Distinguished Professor Emeritus fax: +1 (514) 848-2830 >>>>> Department of Computer Science >>>>> and Software Engineering >>>>> Concordia University EV 3.185email:william.atwood@concordia.ca >>>>> 1455 de Maisonneuve Blvd. Westhttp://users.encs.concordia.ca/~bill >>>>> Montreal, Quebec Canada H3G 1M8 >>>>>=20 >>>>=20 >>>> Email secured by Check Point >>>=20 >>>=20 >>=20 >> Email secured by Check Point >=20 > _______________________________________________ > MSEC mailing list > MSEC@ietf.org > https://www.ietf.org/mailman/listinfo/msec --=20 Brian Weis Security, Enterprise Networking Group, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com From bew@cisco.com Fri Oct 11 15:43:32 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 08EA321F8596 for ; Fri, 11 Oct 2013 15:43:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 jgGWh1EIJmgB for ; Fri, 11 Oct 2013 15:43:26 -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 58C3021F8546 for ; Fri, 11 Oct 2013 15:43:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1191; q=dns/txt; s=iport; t=1381531392; x=1382740992; h=from:content-transfer-encoding:subject:date:message-id: cc:to:mime-version; bh=ddhwuerdGgZ522CIOCnoZPe/kiDlVhFM1jIMjASeo4w=; b=DXX0DASnvpE2FHNiRGLWZ5dPIlHQ/xXeXaWWedMhjYngxGE/aRyGE8MZ PAHH1NwFwvcuuzMK/TjhS9FDVdY/EWXGYnSKzakQm4zBGBPrnhorBumhU WpZdsd7EZ+Rxw4P3GLad6JiHAX4EocblQyW62vDwyYxmv4DIvhOB6JKtA A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai0LAE1+WFKrRDoI/2dsb2JhbABagwc4rVKUWYEiFm0HgmY/gT4cC4dxAQy8C49NgyaBBAOJPI5JgS+QU4NE X-IronPort-AV: E=Sophos;i="4.93,478,1378857600"; d="scan'208";a="91233499" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-1.cisco.com with ESMTP; 11 Oct 2013 22:43:00 +0000 Received: from dhcp-128-107-151-21.cisco.com (dhcp-128-107-151-21.cisco.com [128.107.151.21]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r9BMgxvD008421 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 11 Oct 2013 22:42:59 GMT From: Brian Weis Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 11 Oct 2013 15:43:00 -0700 Message-Id: <1C26F45B-4DC6-44C1-9EB9-50ABDA2DBFAC@cisco.com> To: "msec@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) Cc: draft-weis-gdoi-rekey-ack@tools.ietf.org Subject: [MSEC] GDOI Rekey Acknowledgement Draft 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, 11 Oct 2013 22:43:32 -0000 Dear MSEC community, This draft describing an update to the GDOI rekey process was just = posted. The authors welcome comments sent to this list. Thanks, Brian =3D=3D=3D=3D=3D=3D=3D A new version of I-D, draft-weis-gdoi-rekey-ack-00.txt has been successfully posted to the IETF repository. Filename: draft-weis-gdoi-rekey-ack Revision: 00 Title: GDOI GROUPKEY-PUSH Acknowledgement Message Creation date: 2013-10-10 Group: Individual Submission Number of pages: 16 URL: = http://www.ietf.org/internet-drafts/draft-weis-gdoi-rekey-ack-00.txt Status: = http://datatracker.ietf.org/doc/draft-weis-gdoi-rekey-ack Htmlized: http://tools.ietf.org/html/draft-weis-gdoi-rekey-ack-00 Abstract: The Group Domain of Interpretation (RFC 6407) includes the ability for a Group Controller/Key Server (GCKS) to provide a set of current Group Member (GM) devices with additional security associations (e.g., to rekey expiring security associations). This memo adds the ability of a GCKS to request the GM devices to return an acknowledgement of receipt of its rekey message, and specifies the acknowledgement method. From bew@cisco.com Fri Oct 11 17:10:57 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 DFCEA11E81A1 for ; Fri, 11 Oct 2013 17:10:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.57 X-Spam-Level: X-Spam-Status: No, score=-110.57 tagged_above=-999 required=5 tests=[AWL=-0.029, BAYES_00=-2.599, HTML_EMBEDS=0.056, HTML_MESSAGE=0.001, 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 uBibLo9QcNao for ; Fri, 11 Oct 2013 17:10:53 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 1703511E8187 for ; Fri, 11 Oct 2013 17:10:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16083; q=dns/txt; s=iport; t=1381536653; x=1382746253; h=mime-version:subject:from:in-reply-to:date:cc:message-id: references:to; bh=g3h3R5K7jEL8iWXZ26YbTE6KtTvyiVsQBOW2dAUx1D4=; b=a9IAMjN5UfZm6K2lqG+87XyBCUgXtsQGQ93eXOvPicVjS18PKgGnrVBb 4VsCfJzXGUXq1iVDx4IUCxM8SiPcKJFFqttbDNeFCt5taAR+eds8Vck4e 459VNmv4wYL3t1IWPY0QGjRq7TFFtTqvqvc1VtqlZB+D46YHcOZp5mnuS 8=; X-IronPort-AV: E=Sophos;i="4.93,479,1378857600"; d="scan'208,217";a="94468422" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-4.cisco.com with ESMTP; 12 Oct 2013 00:10:51 +0000 Received: from dhcp-128-107-151-21.cisco.com (dhcp-128-107-151-21.cisco.com [128.107.151.21]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r9C0AnYQ015076 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 12 Oct 2013 00:10:50 GMT Content-Type: multipart/alternative; boundary="Apple-Mail=_27AE1584-F134-48AB-A7B1-D8A46D02469C" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Brian Weis In-Reply-To: Date: Fri, 11 Oct 2013 17:10:50 -0700 Message-Id: <37B6C947-2DEA-440A-9698-997EFEF97ACB@cisco.com> References: To: Paul Lambert X-Mailer: Apple Mail (2.1508) 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: Sat, 12 Oct 2013 00:10:58 -0000 --Apple-Mail=_27AE1584-F134-48AB-A7B1-D8A46D02469C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Paul, On Sep 27, 2013, at 2:52 PM, Paul Lambert wrote: >=20 >> IEC TC57 WG10 (61850) and IEC TC57 WG15 (Security) has been = developing a technology/standard for use as a secure multicast for its = use in power grid applications using synchrophasors and other = technologies relevant to smartgrid deployments globally. >> =20 >> As part of the effort, some extensions to GDOI were identified. The = 6407 draft incorporates and improves some of the enhancements already = identified. IEC TC57 WG15 is waiting for the draft RFC to transition to = an RFC so it can be referenced as a normative standard in IEC 62351-9. >> =20 >> There are several utility vendors and utilities, in particular SCE = (Southern California Edison), that are awaiting this transition so that = their cyber security frameworks can be updated. Delays in the = transition from draft to RFC will delay implementation of several = projects and implementations. >=20 >=20 > Good to see such applications. =20 Thanks for your encouragement. > What encapsulation mode is specified for this multicast service? = Just curious since I have other industry requirements that are very = similar and need better multicast security. The data transports are defined in the IEC 61850-90 family of standards, = and are a part of the frame formats used within and between power = substations. I don't think they is generally re-usable to other = industries. But some of the payloads defined in this Internet-Draft might be = applicable for key management in other industries. In particular the OID = Identification (ID) payload could be used by any protocol using an OID = as an identity. Thanks, Brian >=20 > Thanks in advance, >=20 > Paul >=20 >=20 >> =20 >> =20 >> =20 >> =20 >> =20 >> Herbert Falk >> Solutions Architect >> SISCO, INC. >> 6605 19 1=8E2 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 >=20 >=20 >=20 > _______________________________________________ > MSEC mailing list > MSEC@ietf.org > https://www.ietf.org/mailman/listinfo/msec --=20 Brian Weis Security, Enterprise Networking Group, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com --Apple-Mail=_27AE1584-F134-48AB-A7B1-D8A46D02469C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi = Paul,

On Sep 27, 2013, at 2:52 PM, Paul Lambert <paul@marvell.com> = wrote:


IEC TC57 WG10 (61850) = and IEC TC57 WG15 (Security) has been developing a technology/standard = for use as a secure multicast for its use in power grid applications = using synchrophasors and other technologies relevant to smartgrid deployments globally.
 
As part of the effort, = some extensions to GDOI were identified.  The 6407 draft = incorporates and improves some of the enhancements already = identified.  IEC TC57 WG15 is waiting for the draft RFC to = transition to an RFC so it can be referenced as a normative standard in IEC = 62351-9.
 
There are several = utility vendors and utilities, in particular SCE (Southern California = Edison), that are awaiting this transition so that their cyber security = frameworks can be updated.  Delays in the transition from draft to RFC will delay implementation of several projects and = implementations.

Good to see such applications. =  

Thanks for your = encouragement.

What encapsulation mode is specified for = this multicast service?   Just curious since I have other industry = requirements that are very similar and need better multicast = security.

The data = transports are defined in the IEC 61850-90 family of standards, and = are a part of the frame formats used within and between power = substations. I don't think they is generally re-usable to other = industries.

But some of the payloads defined in = this Internet-Draft might be applicable for key management in other = industries. In particular the OID Identification (ID) payload could be = used by any protocol using an OID as an = identity.

Thanks,
Brian

 
 
 

 

 
Herbert= Falk
Solutions = Architect
SISCO, = INC.
6605 19 1=8E2 Mile = Rd.
Sterling Heights, MI = 48314
(586) 254-0020 = x-105
 
        &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;            =         
"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 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.
 


_______________________________________________
MSEC mailing = list
MSEC@ietf.org
https://www.ietf.org/ma= ilman/listinfo/msec

bew@cisco.com

= --Apple-Mail=_27AE1584-F134-48AB-A7B1-D8A46D02469C-- From paul@marvell.com Mon Oct 14 18:10:41 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 73EFC11E80E7 for ; Mon, 14 Oct 2013 18:10:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.208 X-Spam-Level: X-Spam-Status: No, score=-2.208 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_EMBEDS=0.056, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] 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 35f11IyO9--3 for ; Mon, 14 Oct 2013 18:10:36 -0700 (PDT) Received: from mx0a-0016f401.pphosted.com (mx0a-0016f401.pphosted.com [67.231.148.174]) by ietfa.amsl.com (Postfix) with ESMTP id 589F411E80EC for ; Mon, 14 Oct 2013 18:10:35 -0700 (PDT) Received: from pps.filterd (m0045849.ppops.net [127.0.0.1]) by mx0a-0016f401.pphosted.com (8.14.5/8.14.5) with SMTP id r9F1AO3n005845; Mon, 14 Oct 2013 18:10:30 -0700 Received: from sc-owa02.marvell.com ([199.233.58.137]) by mx0a-0016f401.pphosted.com with ESMTP id 1fexe8negb-1 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 14 Oct 2013 18:10:30 -0700 Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by sc-owa02.marvell.com ([10.93.76.22]) with mapi; Mon, 14 Oct 2013 18:10:30 -0700 From: Paul Lambert To: Brian Weis Date: Mon, 14 Oct 2013 18:10:28 -0700 Thread-Topic: [MSEC] Key Management protocol (GDOI - 6407) forward Thread-Index: Ac7JQ1ZH623ZFZeWRFuL5jHSu7j86Q== Message-ID: In-Reply-To: <37B6C947-2DEA-440A-9698-997EFEF97ACB@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.7.130812 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CE81E145255E7paulmarvellcom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-10-14_05:2013-10-15, 2013-10-14, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1310140136 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: Tue, 15 Oct 2013 01:10:41 -0000 --_000_CE81E145255E7paulmarvellcom_ Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable Brian, Thanks for the info =85 The data transports are defined in the IEC 61850-90 family of standards, an= d are a part of the frame formats used within and between power substations= . I don't think they is generally re-usable to other industries. But some of the payloads defined in this Internet-Draft might be applicable= for key management in other industries. In particular the OID Identificati= on (ID) payload could be used by any protocol using an OID as an identity. In MSEC or the 61850 series I do not see how the group key distribution han= dles the issues of nonce/key uniqueness for algorithm modes like CCM or GCM= . I'd assumed that this multicast group would need to address this very im= portant security requirement. I'm sure it must just be my quick read of MSEC that I'm missing something, = but =85 How does the MSEC or 61850 protocols handle the limitations of AES= -CCM or AES-GCM and provide a guarantee of transmitted nonce/key uniqueness= for multicast groups? I was hoping to find in the MSEC a new algorithm mode (which I believe is t= he preferred answer to the issue) or perhaps another mechanism. The Wi-Fi= multicast security solutions currently require N squared messages to give = each device it's own group key because of the nonce/key uniqueness requirem= ent. This is a limitation (IMO) of CCM and GCM. IN some environments or p= rotocols it might be possible to coordinate or control the nonce to make su= re it is not repeated for a group of devices. This is quite difficult for = consumer device since if reset they would forget state and potentially repe= at a nonce (unless some device coordinates nonce usage =96 impossible in ad= hoc environments). Regards, Paul Thanks, Brian Thanks in advance, Paul Herbert Falk Solutions Architect SISCO, INC. 6605 19 1=8E2 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. ________________________________ _______________________________________________ MSEC mailing list MSEC@ietf.org https://www.ietf.org/mailman/listinfo/msec -- Brian Weis Security, Enterprise Networking Group, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com --_000_CE81E145255E7paulmarvellcom_ Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable

Brian,

Thanks for the info =85


The data transports are d= efined in the IEC 61850-90 family of standards, and are a part of the = frame formats used within and between power substations. I don't think they= is generally re-usable to other industries.

But s= ome of the payloads defined in this Internet-Draft might be applicable for = key management in other industries. In particular the OID Identification (I= D) payload could be used by any protocol using an OID as an identity.
=

In MSEC or the 61850 se= ries I do not see how the group key distribution handles the issues of nonc= e/key uniqueness for algorithm modes like CCM or GCM.  I'd assumed tha= t this multicast group would need to address this very important security r= equirement.  

I'm sure it must just be my qui= ck read of MSEC that I'm missing something, but  =85 How does the MSEC= or 61850 protocols handle the limitations of AES-CCM or AES-GCM and provid= e a guarantee of transmitted nonce/key uniqueness for multicast groups? &nb= sp;

I was hoping to find in the MSEC a new algorit= hm mode (which I believe is the preferred answer to the issue) or perhaps a= nother mechanism.   The Wi-Fi multicast security solutions currently r= equire N squared messages to give each device it's own group key because of= the nonce/key uniqueness requirement.  This is a limitation (IMO) of = CCM and GCM.  IN some environments or protocols it might be possible t= o coordinate or control the nonce to make sure it is not repeated for a gro= up of devices.  This is quite difficult for consumer device since if r= eset they would forget state and potentially repeat a nonce (unless some de= vice coordinates nonce usage =96 impossible in ad hoc environments).
<= div>

Regards,

Paul



Thanks,
Brian


Thanks in advance,

Paul


=
<= div class=3D"MsoNormal"> 
 
 

 

 
= Herbert Falk
Solutions Architect
=
SISC= O, INC.
6605 19 1=8E2 Mile Rd.
Sterli= ng Heights, MI 48314
(586) 254-0020 x-105
 
     &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;         
"In matters of style, swim with the current;   in matter= s of principle, stand like a rock." [Thomas Jefferson]
 
 =
NOTICE: This c= ommunication may contain privileged or other confidential information. If y= ou 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. Als= o,  please indicate to the sender that you have received this communic= ation in error, and delete the copy you received. Thank you.
 = ;


_______________________________________________
MSEC mailing list
MSEC@ietf.org
https://www.ietf.org= /mailman/listinfo/msec

-- 
Brian Weis
Security, Enterprise Networking Group, Cisco Systems
Telephone: +1 408 526 4796
Email: bew@cisco.com
<= /div>


--_000_CE81E145255E7paulmarvellcom_-- From bew@cisco.com Tue Oct 15 09:41:18 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 7E67421F9D94 for ; Tue, 15 Oct 2013 09:41:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.447 X-Spam-Level: X-Spam-Status: No, score=-110.447 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, HTML_EMBEDS=0.056, HTML_MESSAGE=0.001, 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 dJCCLhOZzgvY for ; Tue, 15 Oct 2013 09:41:14 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 813DF11E813D for ; Tue, 15 Oct 2013 09:40:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=19488; q=dns/txt; s=iport; t=1381855251; x=1383064851; h=mime-version:subject:from:in-reply-to:date:cc:message-id: references:to; bh=lVv+z8KNT/TbNCS46Caf/rcra5bwbZCskZVsdJ//CwQ=; b=TJYe2Zu7dnkwThL4UEicoZ7ChdAD/5Iz38hxzcQc8USIzK77Efli+LFQ SDupyD2xvtJVBIjUhOATQEmP03yxkls5I5GuyStwEyevgatxc9hI/94nE QsV1SWpRHZkoOUUDg+bdzjhjgUfsr3rh+30iWMBvDXSNFvvAbeKZZR32J E=; X-IronPort-AV: E=Sophos;i="4.93,500,1378857600"; d="scan'208,217";a="94778698" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-2.cisco.com with ESMTP; 15 Oct 2013 16:40:51 +0000 Received: from dhcp-10-155-137-5.cisco.com (dhcp-10-155-137-5.cisco.com [10.155.137.5]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r9FGeopI031600 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 15 Oct 2013 16:40:50 GMT Content-Type: multipart/alternative; boundary="Apple-Mail=_431A41BD-AB48-4ED3-B1C6-A64FBBAA05D1" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Brian Weis In-Reply-To: Date: Tue, 15 Oct 2013 09:40:50 -0700 Message-Id: References: To: Paul Lambert X-Mailer: Apple Mail (2.1510) 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: Tue, 15 Oct 2013 16:41:18 -0000 --Apple-Mail=_431A41BD-AB48-4ED3-B1C6-A64FBBAA05D1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1250 Hi Paul, On Oct 14, 2013, at 6:10 PM, Paul Lambert wrote: >=20 > Brian, >=20 > Thanks for the info =85 >=20 >>=20 >> The data transports are defined in the IEC 61850-90 family of = standards, and are a part of the frame formats used within and between = power substations. I don't think they is generally re-usable to other = industries. >>=20 >> But some of the payloads defined in this Internet-Draft might be = applicable for key management in other industries. In particular the OID = Identification (ID) payload could be used by any protocol using an OID = as an identity. >=20 >=20 > In MSEC or the 61850 series I do not see how the group key = distribution handles the issues of nonce/key uniqueness for algorithm = modes like CCM or GCM. I'd assumed that this multicast group would need = to address this very important security requirement. =20 >=20 > I'm sure it must just be my quick read of MSEC that I'm missing = something, but =85 How does the MSEC or 61850 protocols handle the = limitations of AES-CCM or AES-GCM and provide a guarantee of transmitted = nonce/key uniqueness for multicast groups? =20 You're right, this is very important. You can find a general description = of the MSEC solution in RFC 6054 . = Briefly, the Nonce space is segmented so that each group members has a = unique part of the nonce space. The GDOI protocol supports this in RFC = 6407 by distributing unique upper bits of the nonce (SID). > I was hoping to find in the MSEC a new algorithm mode (which I believe = is the preferred answer to the issue) or perhaps another mechanism. = The Wi-Fi multicast security solutions currently require N squared = messages to give each device it's own group key because of the nonce/key = uniqueness requirement. This is a limitation (IMO) of CCM and GCM. IN = some environments or protocols it might be possible to coordinate or = control the nonce to make sure it is not repeated for a group of = devices. This is quite difficult for consumer device since if reset = they would forget state and potentially repeat a nonce (unless some = device coordinates nonce usage =96 impossible in ad hoc environments). The MSEC protocols all assume a centralized key management service, = which carefully allocates the SIDs. As you say, in order to repeat the = devices have to request an SID after a reset but they also have to = request the rest of the keying state as well. The controller always = returns a new SID to ensure the old nonces are not reused. Another = system using a centralized controller could likely do something similar. Hope that helps, Brian >=20 >=20 > Regards, >=20 > Paul >=20 >=20 >>=20 >> Thanks, >> Brian >>=20 >>>=20 >>> Thanks in advance, >>>=20 >>> Paul >>>=20 >>>=20 >>>> =20 >>>> =20 >>>> =20 >>>> =20 >>>> =20 >>>> Herbert Falk >>>> Solutions Architect >>>> SISCO, INC. >>>> 6605 19 1=8E2 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 >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> MSEC mailing list >>> MSEC@ietf.org >>> https://www.ietf.org/mailman/listinfo/msec >>=20 >> --=20 >> Brian Weis >> Security, Enterprise Networking Group, Cisco Systems >> Telephone: +1 408 526 4796 >> Email: bew@cisco.com >>=20 >=20 >=20 >=20 --=20 Brian Weis Security, Enterprise Networking Group, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com --Apple-Mail=_431A41BD-AB48-4ED3-B1C6-A64FBBAA05D1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1250 Hi = Paul,

On Oct 14, 2013, at 6:10 PM, Paul Lambert <paul@marvell.com> = wrote:


The data = transports are defined in the IEC 61850-90 family of standards, and = are a part of the frame formats used within and between power = substations. I don't think they is generally re-usable to other = industries.

But some of the payloads defined in = this Internet-Draft might be applicable for key management in other = industries. In particular the OID Identification (ID) payload could be = used by any protocol using an OID as an = identity.

In MSEC or = the 61850 series I do not see how the group key distribution handles the = issues of nonce/key uniqueness for algorithm modes like CCM or GCM. =  I'd assumed that this multicast group would need to address this = very important security requirement.  

I'm = sure it must just be my quick read of MSEC that I'm missing something, = but  =85 How does the MSEC or 61850 protocols handle the = limitations of AES-CCM or AES-GCM and provide a guarantee of transmitted = nonce/key uniqueness for multicast groups? =  

You're right, this is very = important. You can find a general description of the MSEC solution in = RFC 6054 <http://tools.ietf.org/html/rfc= 6054>. Briefly, the Nonce space is segmented so that each group = members has a unique part of the nonce space. The GDOI protocol supports = this in RFC 6407 by distributing unique upper bits of the nonce = (SID).


Thanks in = advance,

Paul


=
 
 
 
 
 
Herbert= Falk
Solutions = Architect
SISCO, = INC.
6605 19 1=8E2 Mile = Rd.
Sterling Heights, MI = 48314
(586) 254-0020 = x-105
 
        &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;            =         
"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 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.
 


_______________________________________________
MSEC mailing list
MSEC@ietf.org
https://www.ietf.org/m= ailman/listinfo/msec

-- 
Brian Weis
Security, Enterprise Networking Group, Cisco Systems
Telephone: +1 408 526 4796
Email: bew@cisco.com




bew@cisco.com

= --Apple-Mail=_431A41BD-AB48-4ED3-B1C6-A64FBBAA05D1-- From paul@marvell.com Tue Oct 15 19:50: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 AE64C21F866E for ; Tue, 15 Oct 2013 19:50:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.208 X-Spam-Level: X-Spam-Status: No, score=-2.208 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_EMBEDS=0.056, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] 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 h3Qehfod8YiA for ; Tue, 15 Oct 2013 19:50:12 -0700 (PDT) Received: from mx0b-0016f401.pphosted.com (mx0b-0016f401.pphosted.com [67.231.156.173]) by ietfa.amsl.com (Postfix) with ESMTP id CA64211E8209 for ; Tue, 15 Oct 2013 19:50:11 -0700 (PDT) Received: from pps.filterd (m0045851.ppops.net [127.0.0.1]) by mx0b-0016f401.pphosted.com (8.14.5/8.14.5) with SMTP id r9G2o77k012005; Tue, 15 Oct 2013 19:50:07 -0700 Received: from sc-owa02.marvell.com ([199.233.58.137]) by mx0b-0016f401.pphosted.com with ESMTP id 1fhar51we1-8 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 15 Oct 2013 19:50:06 -0700 Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by sc-owa02.marvell.com ([10.93.76.22]) with mapi; Tue, 15 Oct 2013 19:50:05 -0700 From: Paul Lambert To: Brian Weis Date: Tue, 15 Oct 2013 19:50:04 -0700 Thread-Topic: [MSEC] Key Management protocol (GDOI - 6407) forward Thread-Index: Ac7KGmp2roSjtKRnTiKhJPNIIp5u4g== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.7.130812 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CE834B4B25AE9paulmarvellcom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-10-16_01:2013-10-15, 2013-10-16, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1310150152 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: Wed, 16 Oct 2013 02:50:16 -0000 --_000_CE834B4B25AE9paulmarvellcom_ Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable Brian, Thanks for the help below. It's a bit confusing trying to find how the SID= is set, but I'll keep keep looking. Are there any reference implementations of test vectors for MSEC? Paul Hi Paul, On Oct 14, 2013, at 6:10 PM, Paul Lambert > wrote: Brian, Thanks for the info =85 The data transports are defined in the IEC 61850-90 family of standards, an= d are a part of the frame formats used within and between power substations= . I don't think they is generally re-usable to other industries. But some of the payloads defined in this Internet-Draft might be applicable= for key management in other industries. In particular the OID Identificati= on (ID) payload could be used by any protocol using an OID as an identity. In MSEC or the 61850 series I do not see how the group key distribution han= dles the issues of nonce/key uniqueness for algorithm modes like CCM or GCM= . I'd assumed that this multicast group would need to address this very im= portant security requirement. I'm sure it must just be my quick read of MSEC that I'm missing something, = but =85 How does the MSEC or 61850 protocols handle the limitations of AES= -CCM or AES-GCM and provide a guarantee of transmitted nonce/key uniqueness= for multicast groups? You're right, this is very important. You can find a general description of= the MSEC solution in RFC 6054 . Briefl= y, the Nonce space is segmented so that each group members has a unique par= t of the nonce space. The GDOI protocol supports this in RFC 6407 by distri= buting unique upper bits of the nonce (SID). I was hoping to find in the MSEC a new algorithm mode (which I believe is t= he preferred answer to the issue) or perhaps another mechanism. The Wi-Fi= multicast security solutions currently require N squared messages to give = each device it's own group key because of the nonce/key uniqueness requirem= ent. This is a limitation (IMO) of CCM and GCM. IN some environments or p= rotocols it might be possible to coordinate or control the nonce to make su= re it is not repeated for a group of devices. This is quite difficult for = consumer device since if reset they would forget state and potentially repe= at a nonce (unless some device coordinates nonce usage =96 impossible in ad= hoc environments). The MSEC protocols all assume a centralized key management service, which c= arefully allocates the SIDs. As you say, in order to repeat the devices hav= e to request an SID after a reset but they also have to request the rest of= the keying state as well. The controller always returns a new SID to ensu= re the old nonces are not reused. Another system using a centralized contro= ller could likely do something similar. Hope that helps, Brian Regards, Paul Thanks, Brian Thanks in advance, Paul Herbert Falk Solutions Architect SISCO, INC. 6605 19 1=8E2 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. ________________________________ _______________________________________________ MSEC mailing list MSEC@ietf.org https://www.ietf.org/mailman/listinfo/msec -- Brian Weis Security, Enterprise Networking Group, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com -- Brian Weis Security, Enterprise Networking Group, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com --_000_CE834B4B25AE9paulmarvellcom_ Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable

Brian,

Thanks for the help below.  It's a bit confusing tryin= g to find how the SID is set, but I'll keep keep looking.

Are there any reference implementations of test vectors for MSEC?

Paul


Hi Paul,

On Oct 14, 2013, at 6:10 PM, Paul Lambert <paul@marvell.com> wrote:


<= div>Brian,

Thanks for the info =85

<= /div>

<= div>The data transports are defined in the IEC 61850-90 family of stan= dards, and are a part of the frame formats used within and between power su= bstations. I don't think they is generally re-usable to other industries.

But some of the payloads defined in this Internet-D= raft might be applicable for key management in other industries. In particu= lar the OID Identification (ID) payload could be used by any protocol using= an OID as an identity.

= In MSEC or the 61850 series I do not see how the group key distribution han= dles the issues of nonce/key uniqueness for algorithm modes like CCM or GCM= .  I'd assumed that this multicast group would need to address this ve= ry important security requirement.  

I'm sure it must just be my quick read of = MSEC that I'm missing something, but  =85 How does the MSEC or 61850 p= rotocols handle the limitations of AES-CCM or AES-GCM and provide a guarant= ee of transmitted nonce/key uniqueness for multicast groups?  

You're right, this is very important. You can find a general description of= the MSEC solution in RFC 6054 <http://tools.ietf.org/html/rfc6054>. Briefly, the Nonce space= is segmented so that each group members has a unique part of the nonce space. The GDOI protocol supports this in R= FC 6407 by distributing unique upper bits of the nonce (SID).

I was hoping to find in the MSEC = a new algorithm mode (which I believe is the preferred answer to the issue)= or perhaps another mechanism.   The Wi-Fi multicast security solution= s currently require N squared messages to give each device it's own group key because of the nonce/key uniqueness requirement.  This is a limit= ation (IMO) of CCM and GCM.  IN some environments or protocols it migh= t be possible to coordinate or control the nonce to make sure it is not rep= eated for a group of devices.  This is quite difficult for consumer device since if reset they would forget state and p= otentially repeat a nonce (unless some device coordinates nonce usage =96 i= mpossible in ad hoc environments).

The MSEC protocols all assume a centralized key management service, which c= arefully allocates the SIDs. As you say, in order to repeat the devices hav= e to request an SID after a reset but they also have to request the rest of= the keying state as well.  The controller always returns a new SID to ensure the old nonces are not reuse= d. Another system using a centralized controller could likely do something = similar.

Hope that helps,
Brian



Reg= ards,

Paul



= Thanks,
Brian


Thanks in advance,

Paul


 
=  
<= span style=3D"color:#1F497D"> 
 
 
Herbert Falk
Solutions Architect<= /div>
SISCO, INC.
6605 19 1=8E2 Mile Rd.
S= terling Heights, MI 48314
<= span style=3D"font-size:8.0pt;color:#595959">(586) 254-0020 x-105
 
     = ;            &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;          
"In matters of style, swim with the current;   in matter= s of principle, stand like a rock." [Thomas Jefferson]
 
 =
NOTICE: This c= ommunication may contain privileged or other confidential information. If y= ou 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. Als= o,  please indicate to the sender that you have received this communic= ation in error, and delete the copy you received. Thank you.
 = ;


_______________________________________________
MSEC mailing list
MSEC@ietf.org
= https://www.ietf.org= /mailman/listinfo/msec

-- 
Brian Weis
Security, Enterprise Networking Group, Cisco Systems
Telephone: +1 408 526 4796
Email: bew@cisco.com
<= /div>



=
-- 
Brian Weis
Security, Enterprise Networking Group, Cisco Systems
Telephone: +1 408 526 4796
Email: bew@cisco.com
<= /div>


--_000_CE834B4B25AE9paulmarvellcom_-- From bew@cisco.com Wed Oct 16 08:41:57 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 CE16F11E82D9 for ; Wed, 16 Oct 2013 08:41:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.931 X-Spam-Level: X-Spam-Status: No, score=-109.931 tagged_above=-999 required=5 tests=[AWL=-0.458, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, HTML_EMBEDS=0.056, HTML_MESSAGE=0.001, 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 Qv1Xgsl20M5F for ; Wed, 16 Oct 2013 08:41:52 -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 962F911E82FA for ; Wed, 16 Oct 2013 08:41:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=24923; q=dns/txt; s=iport; t=1381938103; x=1383147703; h=mime-version:subject:from:in-reply-to:date:cc:message-id: references:to; bh=x5DNYyIx8J/fEPkC817T0TxpUEhxGFeKCIXWRsitcyU=; b=DQ4D+QerLqrkjUHjmpPgJCk7NSOOVJ5MXEsUikshDa5dx+wjXmeqTyqh AqL5AKMROgrjvHrUza6c78Bkg9ROlbydxOq1sCpVU0xYoJAA7oIPGoLxg 0d3TuXy4dAJdgB54cZISccMv4KXsUej30O9xM4fnOsX3D68bZTmaaBSBB 0=; X-IronPort-AV: E=Sophos;i="4.93,508,1378857600"; d="scan'208,217";a="91567021" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-1.cisco.com with ESMTP; 16 Oct 2013 15:41:41 +0000 Received: from [10.154.128.162] ([10.154.128.162]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r9GFfevp017748 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 16 Oct 2013 15:41:40 GMT Content-Type: multipart/alternative; boundary="Apple-Mail=_0E5BAEFC-79B1-4ABC-B13E-7EFF4E3A752E" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Brian Weis In-Reply-To: Date: Tue, 15 Oct 2013 21:15:24 -0700 Message-Id: References: To: Paul Lambert X-Mailer: Apple Mail (2.1510) 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: Wed, 16 Oct 2013 15:41:57 -0000 --Apple-Mail=_0E5BAEFC-79B1-4ABC-B13E-7EFF4E3A752E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1250 Hi Paul, On Oct 15, 2013, at 7:50 PM, Paul Lambert wrote: >=20 > Brian, >=20 > Thanks for the help below. It's a bit confusing trying to find how = the SID is set, but I'll keep keep looking. Section 3.5 of RFC 6407 gives an overview of the key server (KS) = operations that guarantee uniqueness of the SID values. The actual = distribution of the SID is done in the KD payload (fourth message in = Figure 2) along with keying material. See the SID "KD Type" in Section = 5.6, further defined in Section 5.6.4. By default the KS will distribute = one SID each time a group member "registers" to the KS. A group member can request more than one SID value if it believes it = will need them. For example, if it plans to install the policy in more = than one SA Database (SAD) it will need one per SAD). The request is = done in the GAP payload sent in message 2 of Figure 2. > Are there any reference implementations of test vectors for MSEC? No. Since the GDOI payload is an IKEv1 payload, it is encrypted under a = dynamic key and so actual test vectors would be difficult. Hope that helps, Brian >=20 > Paul >=20 >=20 >> Hi Paul, >>=20 >> On Oct 14, 2013, at 6:10 PM, Paul Lambert wrote: >>=20 >>>=20 >>> Brian, >>>=20 >>> Thanks for the info =85 >>>=20 >>>>=20 >>>> The data transports are defined in the IEC 61850-90 family of = standards, and are a part of the frame formats used within and between = power substations. I don't think they is generally re-usable to other = industries. >>>>=20 >>>> But some of the payloads defined in this Internet-Draft might be = applicable for key management in other industries. In particular the OID = Identification (ID) payload could be used by any protocol using an OID = as an identity. >>>=20 >>>=20 >>> In MSEC or the 61850 series I do not see how the group key = distribution handles the issues of nonce/key uniqueness for algorithm = modes like CCM or GCM. I'd assumed that this multicast group would need = to address this very important security requirement. =20 >>>=20 >>> I'm sure it must just be my quick read of MSEC that I'm missing = something, but =85 How does the MSEC or 61850 protocols handle the = limitations of AES-CCM or AES-GCM and provide a guarantee of transmitted = nonce/key uniqueness for multicast groups? =20 >>=20 >> You're right, this is very important. You can find a general = description of the MSEC solution in RFC 6054 = . Briefly, the Nonce space is = segmented so that each group members has a unique part of the nonce = space. The GDOI protocol supports this in RFC 6407 by distributing = unique upper bits of the nonce (SID). >>=20 >>> I was hoping to find in the MSEC a new algorithm mode (which I = believe is the preferred answer to the issue) or perhaps another = mechanism. The Wi-Fi multicast security solutions currently require N = squared messages to give each device it's own group key because of the = nonce/key uniqueness requirement. This is a limitation (IMO) of CCM and = GCM. IN some environments or protocols it might be possible to = coordinate or control the nonce to make sure it is not repeated for a = group of devices. This is quite difficult for consumer device since if = reset they would forget state and potentially repeat a nonce (unless = some device coordinates nonce usage =96 impossible in ad hoc = environments). >>=20 >> The MSEC protocols all assume a centralized key management service, = which carefully allocates the SIDs. As you say, in order to repeat the = devices have to request an SID after a reset but they also have to = request the rest of the keying state as well. The controller always = returns a new SID to ensure the old nonces are not reused. Another = system using a centralized controller could likely do something similar. >>=20 >> Hope that helps, >> Brian >>=20 >>>=20 >>>=20 >>> Regards, >>>=20 >>> Paul >>>=20 >>>=20 >>>>=20 >>>> Thanks, >>>> Brian >>>>=20 >>>>>=20 >>>>> Thanks in advance, >>>>>=20 >>>>> Paul >>>>>=20 >>>>>=20 >>>>>> =20 >>>>>> =20 >>>>>> =20 >>>>>> =20 >>>>>> =20 >>>>>> Herbert Falk >>>>>> Solutions Architect >>>>>> SISCO, INC. >>>>>> 6605 19 1=8E2 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 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> MSEC mailing list >>>>> MSEC@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/msec >>>>=20 >>>> --=20 >>>> Brian Weis >>>> Security, Enterprise Networking Group, Cisco Systems >>>> Telephone: +1 408 526 4796 >>>> Email: bew@cisco.com >>>>=20 >>>=20 >>>=20 >>>=20 >>=20 >> --=20 >> Brian Weis >> Security, Enterprise Networking Group, Cisco Systems >> Telephone: +1 408 526 4796 >> Email: bew@cisco.com >>=20 >=20 >=20 >=20 --=20 Brian Weis Security, Enterprise Networking Group, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com --Apple-Mail=_0E5BAEFC-79B1-4ABC-B13E-7EFF4E3A752E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1250 Hi = Paul,

On Oct 15, 2013, at 7:50 PM, Paul Lambert <paul@marvell.com> = wrote:


A group = member can request more than one SID value if it believes it will need = them. For example, if it plans to install the policy in more than one SA = Database (SAD) it will need one per SAD). The request is done in the GAP = payload sent in message 2 of Figure 2.

Are there any reference = implementations of test vectors for = MSEC?

No. Since the GDOI payload = is an IKEv1 payload, it is encrypted under a dynamic key and so actual = test vectors would be difficult.

Hope that = helps,
Brian


Hi Paul,

On Oct 14, 2013, at 6:10 PM, Paul Lambert <paul@marvell.com> = wrote:


The data = transports are defined in the IEC 61850-90 family of standards, and = are a part of the frame formats used within and between power = substations. I don't think they is generally re-usable to other = industries.

But some of the payloads defined in = this Internet-Draft might be applicable for key management in other = industries. In particular the OID Identification (ID) payload could be = used by any protocol using an OID as an = identity.

In MSEC or = the 61850 series I do not see how the group key distribution handles the = issues of nonce/key uniqueness for algorithm modes like CCM or GCM. =  I'd assumed that this multicast group would need to address this = very important security requirement.  

I'm sure it must just be my quick read = of MSEC that I'm missing something, but  =85 How does the MSEC or = 61850 protocols handle the limitations of AES-CCM or AES-GCM and provide = a guarantee of transmitted nonce/key uniqueness for multicast groups? =  

You're right, this is very important. You can find a general description = of the MSEC solution in RFC 6054 <http://tools.ietf.org/html/rfc= 6054>. Briefly, the Nonce space is segmented so that each group = members has a unique part of the nonce space. The GDOI protocol supports this = in RFC 6407 by distributing unique upper bits of the nonce = (SID).


Thanks in = advance,

Paul


=
 
 
 
 
 
Herbert= Falk
Solutions = Architect
SISCO, = INC.
6605 19 1=8E2 Mile = Rd.
Sterling Heights, MI = 48314
(586) 254-0020 = x-105
 
        &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;            =         
"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 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.
 


_______________________________________________
MSEC mailing list
MSEC@ietf.org
https://www.ietf.org/m= ailman/listinfo/msec

-- 
Brian Weis
Security, Enterprise Networking Group, Cisco Systems
Telephone: +1 408 526 4796
Email: bew@cisco.com




-- 
Brian Weis
Security, Enterprise Networking Group, Cisco Systems
Telephone: +1 408 526 4796
Email: bew@cisco.com




bew@cisco.com

= --Apple-Mail=_0E5BAEFC-79B1-4ABC-B13E-7EFF4E3A752E-- From paul@marvell.com Wed Oct 16 09:05:30 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 B0FD711E82FB for ; Wed, 16 Oct 2013 09:05:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.208 X-Spam-Level: X-Spam-Status: No, score=-2.208 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_EMBEDS=0.056, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] 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 aunz5yHrgs40 for ; Wed, 16 Oct 2013 09:05:25 -0700 (PDT) Received: from mx0b-0016f401.pphosted.com (mx0b-0016f401.pphosted.com [67.231.156.173]) by ietfa.amsl.com (Postfix) with ESMTP id 41D2D21F9D4C for ; Wed, 16 Oct 2013 09:05:24 -0700 (PDT) Received: from pps.filterd (m0045851.ppops.net [127.0.0.1]) by mx0b-0016f401.pphosted.com (8.14.5/8.14.5) with SMTP id r9GG58g1007196; Wed, 16 Oct 2013 09:05:19 -0700 Received: from sc-owa.marvell.com ([199.233.58.135]) by mx0b-0016f401.pphosted.com with ESMTP id 1fhar544kq-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 16 Oct 2013 09:05:18 -0700 Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by SC-OWA.marvell.com ([::1]) with mapi; Wed, 16 Oct 2013 09:05:17 -0700 From: Paul Lambert To: Brian Weis Date: Wed, 16 Oct 2013 09:05:15 -0700 Thread-Topic: [MSEC] Key Management protocol (GDOI - 6407) forward Thread-Index: Ac7KiYFCVTDu21W6S6y/glkbU/jvvA== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.7.130812 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CE84067925C65paulmarvellcom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-10-16_06:2013-10-16, 2013-10-16, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1310160059 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: Wed, 16 Oct 2013 16:05:30 -0000 --_000_CE84067925C65paulmarvellcom_ Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable Brian, Thanks for the pointer below. I now see how the SID works in IKE Section 3.5 of RFC 6407 gives an overview of the key server (KS) operations= that guarantee uniqueness of the SID values. The actual distribution of th= e SID is done in the KD payload (fourth message in Figure 2) along with ke= ying material. See the SID "KD Type" in Section 5.6, further defined in Se= ction 5.6.4. By default the KS will distribute one SID each time a group me= mber "registers" to the KS. A group member can request more than one SID value if it believes it will n= eed them. For example, if it plans to install the policy in more than one S= A Database (SAD) it will need one per SAD). The request is done in the GAP = payload sent in message 2 of Figure 2. Are there any reference implementations of test vectors for MSEC? No. Since the GDOI payload is an IKEv1 payload, it is encrypted under a dyn= amic key and so actual test vectors would be difficult. Yes =85 but still possible by showing full computations on both sides. No= t as necessary here since IKEv1 is a well known entity. Appreciate all the help. Will see if I can reuse any of the ideas =85 Paul Hope that helps, Brian Paul Hi Paul, On Oct 14, 2013, at 6:10 PM, Paul Lambert > wrote: Brian, Thanks for the info =85 The data transports are defined in the IEC 61850-90 family of standards, an= d are a part of the frame formats used within and between power substations= . I don't think they is generally re-usable to other industries. But some of the payloads defined in this Internet-Draft might be applicable= for key management in other industries. In particular the OID Identificati= on (ID) payload could be used by any protocol using an OID as an identity. In MSEC or the 61850 series I do not see how the group key distribution han= dles the issues of nonce/key uniqueness for algorithm modes like CCM or GCM= . I'd assumed that this multicast group would need to address this very im= portant security requirement. I'm sure it must just be my quick read of MSEC that I'm missing something, = but =85 How does the MSEC or 61850 protocols handle the limitations of AES= -CCM or AES-GCM and provide a guarantee of transmitted nonce/key uniqueness= for multicast groups? You're right, this is very important. You can find a general description of= the MSEC solution in RFC 6054 . Briefl= y, the Nonce space is segmented so that each group members has a unique par= t of the nonce space. The GDOI protocol supports this in RFC 6407 by distri= buting unique upper bits of the nonce (SID). I was hoping to find in the MSEC a new algorithm mode (which I believe is t= he preferred answer to the issue) or perhaps another mechanism. The Wi-Fi= multicast security solutions currently require N squared messages to give = each device it's own group key because of the nonce/key uniqueness requirem= ent. This is a limitation (IMO) of CCM and GCM. IN some environments or p= rotocols it might be possible to coordinate or control the nonce to make su= re it is not repeated for a group of devices. This is quite difficult for = consumer device since if reset they would forget state and potentially repe= at a nonce (unless some device coordinates nonce usage =96 impossible in ad= hoc environments). The MSEC protocols all assume a centralized key management service, which c= arefully allocates the SIDs. As you say, in order to repeat the devices hav= e to request an SID after a reset but they also have to request the rest of= the keying state as well. The controller always returns a new SID to ensu= re the old nonces are not reused. Another system using a centralized contro= ller could likely do something similar. Hope that helps, Brian Regards, Paul Thanks, Brian Thanks in advance, Paul Herbert Falk Solutions Architect SISCO, INC. 6605 19 1=8E2 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. ________________________________ _______________________________________________ MSEC mailing list MSEC@ietf.org https://www.ietf.org/mailman/listinfo/msec -- Brian Weis Security, Enterprise Networking Group, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com -- Brian Weis Security, Enterprise Networking Group, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com -- Brian Weis Security, Enterprise Networking Group, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com --_000_CE84067925C65paulmarvellcom_ Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable

=
Brian,

Thanks for the pointer below= .  I now see how the SID works in IKE

Section 3.5 of RFC 6407 gives an overview of the key server = (KS) operations that guarantee uniqueness of the SID values. The actual dis= tribution of the SID is done in the KD payload (fourth message in  Fig= ure 2) along with keying material.  See the SID "KD Type" in Section 5.6, further defined in Section 5.6.4. By d= efault the KS will distribute one SID each time a group member "regist= ers" to the KS.

A group member can request more than one SID value if i= t believes it will need them. For example, if it plans to install the polic= y in more than one SA Database (SAD) it will need one per SAD). The request= is done in the GAP payload sent in message 2 of Figure 2.
Are there any reference implementati= ons of test vectors for MSEC?
No. Since the GDOI payload is an IKEv1 payload, it is encrypted under a dyn= amic key and so actual test vectors would be difficult.
<= /blockquote>

Yes =85  but still possible by = showing full computations on both sides.  Not as necessary here since = IKEv1 is a well known entity.

Appreciate all the h= elp.  Will see if I can reuse any of the ideas =85

Paul





Hope that helps,
Brian


Paul


Hi Paul,

On Oct 14, 2013, at 6:10 PM, Paul Lambert <paul@marvell.com> wrote:


<= div>Brian,

Thanks for the info =85

<= /div>

<= div>The data transports are defined in the IEC 61850-90 family of stan= dards, and are a part of the frame formats used within and between power su= bstations. I don't think they is generally re-usable to other industries.

But some of the payloads defined in this Internet-D= raft might be applicable for key management in other industries. In particu= lar the OID Identification (ID) payload could be used by any protocol using= an OID as an identity.

= In MSEC or the 61850 series I do not see how the group key distribution han= dles the issues of nonce/key uniqueness for algorithm modes like CCM or GCM= .  I'd assumed that this multicast group would need to address this ve= ry important security requirement.  

I'm sure it must just be my quick read of = MSEC that I'm missing something, but  =85 How does the MSEC or 61850 p= rotocols handle the limitations of AES-CCM or AES-GCM and provide a guarant= ee of transmitted nonce/key uniqueness for multicast groups?  

You're right, this is very important. You can find a general description of= the MSEC solution in RFC 6054 <http://tools.ietf.org/html/rfc6054>. Briefly, the Nonce space= is segmented so that each group members has a unique part of the nonce space. The GDOI protocol supports this in R= FC 6407 by distributing unique upper bits of the nonce (SID).

I was hoping to find in the MSEC a new algorithm mode (which I believe is t= he preferred answer to the issue) or perhaps another mechanism.   The = Wi-Fi multicast security solutions currently require N squared messages to = give each device it's own group key because of the nonce/key uniqueness requirement.  This is a limitation (IMO) = of CCM and GCM.  IN some environments or protocols it might be possibl= e to coordinate or control the nonce to make sure it is not repeated for a = group of devices.  This is quite difficult for consumer device since if reset they would forget state and potentially= repeat a nonce (unless some device coordinates nonce usage =96 impossible = in ad hoc environments).

The MSEC protocols all assume a centralized key management service, which c= arefully allocates the SIDs. As you say, in order to repeat the devices hav= e to request an SID after a reset but they also have to request the rest of= the keying state as well.  The controller always returns a new SID to ensure the old nonces are not reuse= d. Another system using a centralized controller could likely do something = similar.

Hope that helps,
Brian



Reg= ards,

Paul



= Thanks,
Brian


Thanks in advance,

Paul


 
=  
<= span style=3D"color:#1F497D"> 
 
 
Herbert Falk
Solutions Architect<= /div>
SISCO, INC.
6605 19 1=8E2 Mile Rd.
S= terling Heights, MI 48314
<= span style=3D"font-size:8.0pt;color:#595959">(586) 254-0020 x-105
 
     = ;            &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;          
"In matters of style, swim with the current;   in matter= s of principle, stand like a rock." [Thomas Jefferson]
 
 =
NOTICE: This c= ommunication may contain privileged or other confidential information. If y= ou 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. Als= o,  please indicate to the sender that you have received this communic= ation in error, and delete the copy you received. Thank you.
 = ;


_______________________________________________
MSEC mailing list
MSEC@ietf.org
= https://www.ietf.org= /mailman/listinfo/msec

-- 
Brian Weis
Security, Enterprise Networking Group, Cisco Systems
Telephone: +1 408 526 4796
Email: bew@cisco.com
<= /div>



=
-- 
Brian Weis
Security, Enterprise Networking Group, Cisco Systems
Telephone: +1 408 526 4796
Email: bew@cisco.com
<= /div>



-- 
Brian Weis
Security, Enterprise Networking Group, Cisco Systems
Telephone: +1 408 526 4796
Email: bew@cisco.com
<= /div>


--_000_CE84067925C65paulmarvellcom_-- From bew@cisco.com Fri Oct 18 15:17: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 1105521F9A16 for ; Fri, 18 Oct 2013 15:17:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.59 X-Spam-Level: X-Spam-Status: No, score=-111.59 tagged_above=-999 required=5 tests=[AWL=1.010, 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 YOp1nefxsvPL for ; Fri, 18 Oct 2013 15:17:03 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 281C421F99FB for ; Fri, 18 Oct 2013 15:17:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7637; q=dns/txt; s=iport; t=1382134623; x=1383344223; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=ZRhAWPu14Kn/eqc9Lu673SX8ejsrr3lIqratSRS82aM=; b=kn3uuiIb2o37/YCrG5zivkeESqu5jOJwV4rtgItLjXVzBS7SAiIFDoRM VEGlurUA7dosmpehRdGHamanxFMavrDF1MRrced6djQegmY8eC9jmXT9S 1cVDPjAcuWTDdSkcGbnmvJQEP8RXrjf1/QJXnpB753JFCS1Zq/FOb1w1w k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqIKAG+yYVKrRDoJ/2dsb2JhbABXA4MHOKoVlGWBJRZ0giUBAQEDAScTPwUHBAsRBAEBAScHRgkIBhOIAAUBDMB/jg0RgQUjEAcGC4MOgQoDiT+OSoEvkFiDRIFQ X-IronPort-AV: E=Sophos;i="4.93,525,1378857600"; d="scan'208";a="95038666" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 18 Oct 2013 22:17:02 +0000 Received: from dhcp-128-107-147-33.cisco.com (dhcp-128-107-147-33.cisco.com [128.107.147.33]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r9IMH0Em018022 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 18 Oct 2013 22:17:00 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Brian Weis In-Reply-To: Date: Fri, 18 Oct 2013 15:17:00 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <300A6726-CF5E-48B8-8D02-F23394B45E60@cisco.com> References: <3CB35FCD-F9EA-4361-B290-3CBBE087C3B8@cisco.com> <5C96E649-6CF5-450E-9787-2C51D76DF2A5@cisco.com> To: "Fries, Steffen" X-Mailer: Apple Mail (2.1510) Cc: "msec@ietf.org" , Sean Turner , "draft-weis-gdoi-iec62351-9@tools.ietf.org" Subject: Re: [MSEC] Review comments, was RE: GDOI support for IEC 62351 X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Oct 2013 22:17:08 -0000 Hi Steffen, Many thanks for your detailed review. We've incorporated the changes and = will publish them in the next version of the document. On Aug 6, 2013, at 1:35 AM, "Fries, Steffen" = wrote: > Hi Brian, >=20 > Thank you for compiling the draft. Meanwhile I had the chance to = review the current draft. Most of the comments I have are actually more = editorial nits than technical. >=20 > Title: IEC 62351 Security Protocol support for GDOI > - After reading the document I would propose to change the title into = "GDOI enhancements supporting IEC 62351 Security Mechanisms". The reason = is that the payloads enhancements are defined for GDOI and are applied = within IEC 62351. But maybe that is philosophical. This makes sense. We're planning to change the title to "GDOI Protocol = Support for IEC 62351 Security Services". > Section 1.Introduction (page 3) > - In the first paragraph I would suggest to add the following = sentence: > "The protection of the frames is defined within IEC 62351-6." My co-authors tell me the precise wording would be "The protection of = frames is defined within IEC 62351-6 , IEC 61850-8-1, and IEC = 61850-9-2.", and we'll add that. > - Last paragraph (page 3): > /r "This document defines GDOI payloads to distribute policy and = keying > material for IEC 61850, and defines the necessary information to > ensure interoperability between IEC 61850 implementations." > /w "This document defines GDOI payloads to distribute policy and = keying > material to protect IEC 61850 data exchanges, and defines the = necessary information to > ensure interoperability between IEC 61850 implementations." >=20 > Section 1.1 (page 4) > - two abbreviations are missing: > - CK Current Key > - NK Next Key >=20 > Section 2 (page 5) > - I would suggest adding one sentence stating, which payloads are = being defined for IEC 61850 protection. All in all we have definitions = for ID, SA TEK, and the KD payloads. To be frank, I wasn't quite sure, = if it makes also sense to spent a subsection on the Security Association = Payload more or less just stating that it is always used with "SA = Attribute NP" set to 16 (SA TEK) as stated in the example in Appendix A.=20= We've added a short introduction to the payloads here. > Section 2.2 (page 7) > - Bullet list below figure 4 > /r "OIDs defined in IEC 61850 declare the type of traffic to be = encrypted." > /w "OIDs defined in IEC 61850 declare the type of traffic to be = protected."=20 > The application of the key material is defined in IEC 61850-90-5 (and = will be included in IEC 62351-6)=20 > and may be used for integrity protection and/or confidentiality = protection. >=20 > Section 2.2.3 (page 9) > - There are two confidentiality algorithms defined. Both are AES-CBC = with different key length. > IEC 61850-90-5 specifies AES-GCM with the two stated key length. This = should be double checked. The most recent IEC 62351-9 document now points to this document as the = definition of available algorithms to use. We decided to drop support for AES-GCM here because there doesn't seem = to be a safe way to use AES-GCM in the GOOSE and SV security transforms. = AES-GCM takes a counter as input, but there is no explicit counter = defined in the IEC documents by which the receiver would know what = counter to use for decryption (or for integrity protection if AES-GMAC = is used). > Section 2.3 (page 10) > - There are two attributes for the TEK key:=20 > - TEK_INTEGRITY_KEY if the key is associated with an IEC 61850-90-5 = defined integrity algorithm=20 > - TEK_ALGORITHM_KEY if the key is associated with an IEC 61850-90-5 = defined confidentiality algorithm > I would suggest to rename the TEK_ALGORITHM_KEY to = TEK_CONFIDENTIALITY_KEY to have the same association. This change would be a good idea, but the names are defined in RFC 6407 = and this document isn't at liberty to rename them. > Annex A (page 18) > - caption of figure states "Sample IEC-61850 SA Payload" -> should = this be enhanced to "Sample IEC-61850 SA and SA TEK Payload"? The SA TEK is considered part of the SA payload (see RFC 6407 Figure 2), = so the figure title is actually correct. > Annex A (page 19) > - I calculated the KD Length of SPI=3D1 in the example to 62 = (TEK_INTEGRITY_KEY, TEK_ALGORITHM_KEY, and the header). Currently 30 is = stated. This should be verified. Good catch! We'll fix the figure. Thanks, Brian >=20 > Okay so far for the review. As I said, mostly editorial. >=20 > Regards > Steffen =20 >=20 > Steffen Fries > Siemens AG > Corporate Technology > CT RTC ITS > Otto-Hahn-Ring 6 > 81739 Muenchen, Germany > Tel: +49 89 636-53403 > Fax: +49 89 636-48000 > mailto:steffen.fries@siemens.com >=20 > Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Gerhard = Cromme; Managing Board: Joe Kaeser, Chairman, President and Chief = Executive Officer; Roland Busch, Brigitte Ederer, Klaus Helmrich, = Barbara Kux, Hermann Requardt, Siegfried Russwurm, Peter Y. Solmssen, = Michael Suess; Registered offices: Berlin and Munich, Germany; = Commercial registries: Berlin Charlottenburg, HRB 12300, Munich, HRB = 6684; WEEE-Reg.-No. DE 23691322=20 >=20 >=20 >=20 > -----Original Message----- > From: msec-bounces@ietf.org [mailto:msec-bounces@ietf.org] On Behalf = Of Brian Weis > Sent: Freitag, 2. August 2013 21:28 > To: msec@ietf.org > Cc: draft-weis-gdoi-iec62351-9@tools.ietf.org; Sean Turner > Subject: Re: [MSEC] GDOI support for IEC 62351 >=20 > Folks, >=20 > Sean had some good feedback, and there is a new version now: = . GDOI = implementers should note that both RFC 3547 and RFC 6407 relied upon the = ID Types defined in the IPsec DOI, which wasn't quite the right thing to = do. So please note that Section 4 (IANA Considerations) now adds a = registry of ID types for the GDOI DOI. This came about because this I-D = adds a new value. >=20 > The GDOI DOI list of ID Types is copy-and-paste from the IPsec DOI, = plus the new ID type added. So all of the old values are still valid, = they are just administratively defined in the GDOI IANA registry now = rather than the IPsec registry. This should not have a negative effect = on implementations but it's worth pointing out. >=20 > Comments on the Internet-Draft are still requested. >=20 > Thanks, > Brian=20 >=20 > On Jul 23, 2013, at 1:56 AM, Brian Weis wrote: >=20 >> Greetings, >>=20 >> The IEC 62351 power utility automation standards group has chosen to = use GDOI (RFC 6407) as their key management method to distribute group = keys. The keys protect multicast traffic streams sent by devices = monitoring the power grid, and other multicast streams as well. To do = this they require some new GDOI payloads. This message is an invitation = to review and comment on the new definitions, which are defined in = . Since the = MSEC WG is not currently active, we hope to progress the draft as an = individual submission soon and would appreciate any feedback. If you = have comments, please post them to the MSEC list (msec@ietf.org) or send = them to the authors (draft-weis-gdoi-iec62351-9@tools.ietf.org).=20 >>=20 >> Thanks, >> Brian=20 --=20 Brian Weis Security, Enterprise Networking Group, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com From paul@marvell.com Fri Oct 18 18:14:41 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 49AAF11E810B for ; Fri, 18 Oct 2013 18:14:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.236 X-Spam-Level: X-Spam-Status: No, score=-2.236 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 N2NzU7a4eQRl for ; Fri, 18 Oct 2013 18:14:35 -0700 (PDT) Received: from mx0b-0016f401.pphosted.com (mx0b-0016f401.pphosted.com [67.231.156.173]) by ietfa.amsl.com (Postfix) with ESMTP id 4E7BD11E8100 for ; Fri, 18 Oct 2013 18:14:35 -0700 (PDT) Received: from pps.filterd (m0045851.ppops.net [127.0.0.1]) by mx0b-0016f401.pphosted.com (8.14.5/8.14.5) with SMTP id r9J1EWnY028877; Fri, 18 Oct 2013 18:14:32 -0700 Received: from sc-owa01.marvell.com ([199.233.58.136]) by mx0b-0016f401.pphosted.com with ESMTP id 1fjydj2v8t-11 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 18 Oct 2013 18:14:32 -0700 Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by SC-OWA01.marvell.com ([10.93.76.21]) with mapi; Fri, 18 Oct 2013 18:14:31 -0700 From: Paul Lambert To: Brian Weis , "Fries, Steffen" Date: Fri, 18 Oct 2013 18:14:29 -0700 Thread-Topic: [MSEC] Review comments, was RE: GDOI support for IEC 62351 Thread-Index: Ac7MaJAe3khdfnCsRUi1mQpWexQZEg== Message-ID: In-Reply-To: <300A6726-CF5E-48B8-8D02-F23394B45E60@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.7.130812 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-10-18_03:2013-10-18, 2013-10-18, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1310180149 Cc: "msec@ietf.org" , Sean Turner , "draft-weis-gdoi-iec62351-9@tools.ietf.org" Subject: Re: [MSEC] Review comments, was RE: GDOI support for IEC 62351 X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Oct 2013 01:14:41 -0000 > >We decided to drop support for AES-GCM here because there doesn't seem to >be a safe way to use AES-GCM in the GOOSE and SV security transforms. >AES-GCM takes a counter as input, but there is no explicit counter >defined in the IEC documents by which the receiver would know what >counter to use for decryption (or for integrity protection if AES-GMAC is >used). So what's used instead? Paul From steffen.fries@siemens.com Mon Oct 21 00:07:01 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 89F3111E8110 for ; Mon, 21 Oct 2013 00:07:01 -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 DJKRmPRXFeYU for ; Mon, 21 Oct 2013 00:06:53 -0700 (PDT) Received: from lizzard.sbs.de (lizzard.sbs.de [194.138.37.39]) by ietfa.amsl.com (Postfix) with ESMTP id A95AA11E810C for ; Mon, 21 Oct 2013 00:06:51 -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 r9L76jMf017584; Mon, 21 Oct 2013 09:06:45 +0200 Received: from DEFTHW99ET5MSX.ww902.siemens.net (defthw99et5msx.ww902.siemens.net [157.163.148.55]) by mail2.sbs.de (8.13.6/8.13.6) with ESMTP id r9L76iTH004636 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 21 Oct 2013 09:06:44 +0200 Received: from DENBGAT9ERJMSX.ww902.siemens.net (139.22.70.139) by DEFTHW99ET5MSX.ww902.siemens.net (157.163.148.55) with Microsoft SMTP Server (TLS) id 8.3.327.1; Mon, 21 Oct 2013 09:06:44 +0200 Received: from DENBGAT9EH2MSX.ww902.siemens.net ([169.254.6.199]) by DENBGAT9ERJMSX.ww902.siemens.net ([139.22.70.139]) with mapi id 14.03.0158.001; Mon, 21 Oct 2013 09:06:43 +0200 From: "Fries, Steffen" To: Brian Weis Thread-Topic: Review comments, was RE: [MSEC] GDOI support for IEC 62351 Thread-Index: AQHOzE/JK6u4xfZSYEa6VhKD1NQPopn+uR2g Date: Mon, 21 Oct 2013 07:06:43 +0000 Message-ID: References: <3CB35FCD-F9EA-4361-B290-3CBBE087C3B8@cisco.com> <5C96E649-6CF5-450E-9787-2C51D76DF2A5@cisco.com> <300A6726-CF5E-48B8-8D02-F23394B45E60@cisco.com> In-Reply-To: <300A6726-CF5E-48B8-8D02-F23394B45E60@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [139.22.70.48] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "msec@ietf.org" , Sean Turner , "draft-weis-gdoi-iec62351-9@tools.ietf.org" Subject: Re: [MSEC] Review comments, was RE: GDOI support for IEC 62351 X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 07:07:01 -0000 Hi Brian, Thanks for taking care of this. While the changes to most of the points are= clear, one comment to the switch from GCM to CBC for the confidentiality a= lgorithm. As IEC 61850-90-5 is referenced here for the definition of algori= thms directly (Section 2.2.3 (page 9)), I would recommend adding a short re= asoning, why there is a deviation from the algorithm.=20 I found a counter "SmpCnt" in the sampled value header, but this may not b= e increased constantly and is set to zero if the sampling is synchronized b= y clock signal. I'm not sure if this would be sufficient for GCM. I didn't = look up the GOOSE header so far.=20 What I missed is the definition of how to set the initialization vector. Bu= t I guess this is some homework for IEC 62351-6 or IEC 61850-8-1, or IEC 61= 850-9-2 and may not be addressed in this document. Best regards =09 Steffen=20 -----Original Message----- From: Brian Weis [mailto:bew@cisco.com]=20 Sent: Samstag, 19. Oktober 2013 00:17 To: Fries, Steffen Cc: msec@ietf.org; draft-weis-gdoi-iec62351-9@tools.ietf.org; Sean Turner Subject: Re: Review comments, was RE: [MSEC] GDOI support for IEC 62351 Hi Steffen, Many thanks for your detailed review. We've incorporated the changes and wi= ll publish them in the next version of the document. On Aug 6, 2013, at 1:35 AM, "Fries, Steffen" wr= ote: > Hi Brian, >=20 > Thank you for compiling the draft. Meanwhile I had the chance to review t= he current draft. Most of the comments I have are actually more editorial n= its than technical. >=20 > Title: IEC 62351 Security Protocol support for GDOI > - After reading the document I would propose to change the title into "GD= OI enhancements supporting IEC 62351 Security Mechanisms". The reason is th= at the payloads enhancements are defined for GDOI and are applied within IE= C 62351. But maybe that is philosophical. This makes sense. We're planning to change the title to "GDOI Protocol Supp= ort for IEC 62351 Security Services". > Section 1.Introduction (page 3) > - In the first paragraph I would suggest to add the following sentence: > "The protection of the frames is defined within IEC 62351-6." My co-authors tell me the precise wording would be "The protection of frame= s is defined within IEC 62351-6 , IEC 61850-8-1, and IEC 61850-9-2.", and w= e'll add that. > - Last paragraph (page 3): > /r "This document defines GDOI payloads to distribute policy and keying > material for IEC 61850, and defines the necessary information to > ensure interoperability between IEC 61850 implementations." > /w "This document defines GDOI payloads to distribute policy and keying > material to protect IEC 61850 data exchanges, and defines the necessary= information to > ensure interoperability between IEC 61850 implementations." >=20 > Section 1.1 (page 4) > - two abbreviations are missing: > - CK Current Key > - NK Next Key >=20 > Section 2 (page 5) > - I would suggest adding one sentence stating, which payloads are being d= efined for IEC 61850 protection. All in all we have definitions for ID, SA = TEK, and the KD payloads. To be frank, I wasn't quite sure, if it makes als= o sense to spent a subsection on the Security Association Payload more or l= ess just stating that it is always used with "SA Attribute NP" set to 16 (S= A TEK) as stated in the example in Appendix A.=20 We've added a short introduction to the payloads here. > Section 2.2 (page 7) > - Bullet list below figure 4 > /r "OIDs defined in IEC 61850 declare the type of traffic to be encrypte= d." > /w "OIDs defined in IEC 61850 declare the type of traffic to be protecte= d."=20 > The application of the key material is defined in IEC 61850-90-5 (and=20 > will be included in IEC 62351-6) and may be used for integrity protectio= n and/or confidentiality protection. >=20 > Section 2.2.3 (page 9) > - There are two confidentiality algorithms defined. Both are AES-CBC with= different key length. > IEC 61850-90-5 specifies AES-GCM with the two stated key length. This sh= ould be double checked. The most recent IEC 62351-9 document now points to this document as the def= inition of available algorithms to use. We decided to drop support for AES-GCM here because there doesn't seem to b= e a safe way to use AES-GCM in the GOOSE and SV security transforms. AES-GC= M takes a counter as input, but there is no explicit counter defined in the= IEC documents by which the receiver would know what counter to use for dec= ryption (or for integrity protection if AES-GMAC is used). > 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=20 > defined integrity algorithm > - TEK_ALGORITHM_KEY if the key is associated with an IEC 61850-90-5=20 > defined confidentiality algorithm I would suggest to rename the TEK_ALGO= RITHM_KEY to TEK_CONFIDENTIALITY_KEY to have the same association. This change would be a good idea, but the names are defined in RFC 6407 and= this document isn't at liberty to rename them. > Annex A (page 18) > - caption of figure states "Sample IEC-61850 SA Payload" -> should this = be enhanced to "Sample IEC-61850 SA and SA TEK Payload"? The SA TEK is considered part of the SA payload (see RFC 6407 Figure 2), so= the figure title is actually correct. > Annex A (page 19) > - I calculated the KD Length of SPI=3D1 in the example to 62 (TEK_INTEGRI= TY_KEY, TEK_ALGORITHM_KEY, and the header). Currently 30 is stated. This sh= ould be verified. Good catch! We'll fix the figure. Thanks, Brian >=20 > Okay so far for the review. As I said, mostly editorial. >=20 > 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 >=20 > Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Gerhard=20 > Cromme; Managing Board: Joe Kaeser, Chairman, President and Chief=20 > Executive Officer; Roland Busch, Brigitte Ederer, Klaus Helmrich,=20 > Barbara Kux, Hermann Requardt, Siegfried Russwurm, Peter Y. Solmssen,=20 > Michael Suess; Registered offices: Berlin and Munich, Germany;=20 > Commercial registries: Berlin Charlottenburg, HRB 12300, Munich, HRB=20 > 6684; WEEE-Reg.-No. DE 23691322 >=20 >=20 >=20 > -----Original Message----- > From: msec-bounces@ietf.org [mailto:msec-bounces@ietf.org] On Behalf=20 > Of Brian Weis > Sent: Freitag, 2. August 2013 21:28 > To: msec@ietf.org > Cc: draft-weis-gdoi-iec62351-9@tools.ietf.org; Sean Turner > Subject: Re: [MSEC] GDOI support for IEC 62351 >=20 > Folks, >=20 > Sean had some good feedback, and there is a new version now: . GDOI implementers should no= te 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 Se= ction 4 (IANA Considerations) now adds a registry of ID types for the GDOI = DOI. This came about because this I-D adds a new value. >=20 > The GDOI DOI list of ID Types is copy-and-paste from the IPsec DOI, plus = the new ID type added. So all of the old values are still valid, they are j= ust administratively defined in the GDOI IANA registry now rather than the = IPsec registry. This should not have a negative effect on implementations b= ut it's worth pointing out. >=20 > Comments on the Internet-Draft are still requested. >=20 > Thanks, > Brian >=20 > On Jul 23, 2013, at 1:56 AM, Brian Weis wrote: >=20 >> Greetings, >>=20 >> The IEC 62351 power utility automation standards group has chosen to use= GDOI (RFC 6407) as their key management method to distribute group keys. T= he keys protect multicast traffic streams sent by devices monitoring the po= wer 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 ho= pe to progress the draft as an individual submission soon and would appreci= ate 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@tool= s.ietf.org).=20 >>=20 >> Thanks, >> Brian -- Brian Weis Security, Enterprise Networking Group, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com From bew@cisco.com Mon Oct 21 11:10:41 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 C3DA811E83C9 for ; Mon, 21 Oct 2013 11:10:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.842 X-Spam-Level: X-Spam-Status: No, score=-110.842 tagged_above=-999 required=5 tests=[AWL=-0.243, BAYES_00=-2.599, 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 XfO2jIF7bUKr for ; Mon, 21 Oct 2013 11:10:35 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 6F49511E8377 for ; Mon, 21 Oct 2013 11:09:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=754; q=dns/txt; s=iport; t=1382378978; x=1383588578; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=J5WKN6m1aaMFLNYe2cLYZNCW/1J0ECcIhzHIFOqnn7g=; b=I83uMNOe5Lu8fkDxm1WPRYziDNCdSagRy7Qrj6U+zcJf3PljV6DI54I2 Q0i67c969uMWYsMgSnu+dTQyQne6JkuypWacwtxp7Ne/uUPBijJeHkyM4 vAiDmlkVxPx/L9VgHhLj5ufCT1yBLKQGDqd24roNIDpo4O4NNZSlvIRGc U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAFhtZVKrRDoG/2dsb2JhbABWA4MHvzKBLhZ0giUBAQEDATo/EAtGVwYTiAAFAborjhKBFiMQBxGDDoEKA4k/jkqSB4NEgVE X-IronPort-AV: E=Sophos;i="4.93,540,1378857600"; d="scan'208";a="92646898" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-3.cisco.com with ESMTP; 21 Oct 2013 18:09:36 +0000 Received: from dhcp-128-107-147-33.cisco.com (dhcp-128-107-147-33.cisco.com [128.107.147.33]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r9LI9ZJV012003 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 21 Oct 2013 18:09:35 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Brian Weis In-Reply-To: Date: Mon, 21 Oct 2013 11:09:34 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <1E12A57C-8EDE-45C4-871C-51AB24A8EAEE@cisco.com> References: To: Paul Lambert X-Mailer: Apple Mail (2.1510) Cc: "msec@ietf.org" , Sean Turner , "draft-weis-gdoi-iec62351-9@tools.ietf.org" Subject: Re: [MSEC] Review comments, was RE: GDOI support for IEC 62351 X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 18:10:42 -0000 Hi Paul, On Oct 18, 2013, at 6:14 PM, Paul Lambert wrote: >=20 >>=20 >> We decided to drop support for AES-GCM here because there doesn't = seem to >> be a safe way to use AES-GCM in the GOOSE and SV security transforms. >> AES-GCM takes a counter as input, but there is no explicit counter >> defined in the IEC documents by which the receiver would know what >> counter to use for decryption (or for integrity protection if = AES-GMAC is >> used). > So what's used instead? The draft specifies AES-CBC for confidentiality, and HMAC-SHA256 for = integrity. Brian >=20 > Paul >=20 --=20 Brian Weis Security, Enterprise Networking Group, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com From paul@marvell.com Mon Oct 21 20:55:57 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 8F5B111E8119 for ; Mon, 21 Oct 2013 20:55:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.244 X-Spam-Level: X-Spam-Status: No, score=-2.244 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 hhQ5B1XBEf9O for ; Mon, 21 Oct 2013 20:55:51 -0700 (PDT) Received: from mx0a-0016f401.pphosted.com (mx0a-0016f401.pphosted.com [67.231.148.174]) by ietfa.amsl.com (Postfix) with ESMTP id 0C40811E831B for ; Mon, 21 Oct 2013 20:55:49 -0700 (PDT) Received: from pps.filterd (m0045849.ppops.net [127.0.0.1]) by mx0a-0016f401.pphosted.com (8.14.5/8.14.5) with SMTP id r9M3tP1o008973; Mon, 21 Oct 2013 20:55:47 -0700 Received: from sc-owa01.marvell.com ([199.233.58.136]) by mx0a-0016f401.pphosted.com with ESMTP id 1fm29e1r5p-1 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 21 Oct 2013 20:55:47 -0700 Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by SC-OWA01.marvell.com ([10.93.76.21]) with mapi; Mon, 21 Oct 2013 20:55:46 -0700 From: Paul Lambert To: Brian Weis Date: Mon, 21 Oct 2013 20:55:44 -0700 Thread-Topic: [MSEC] Review comments, was RE: GDOI support for IEC 62351 Thread-Index: Ac7O2paUUPG2ZlG8S/6PwWSj3bt75w== Message-ID: In-Reply-To: <1E12A57C-8EDE-45C4-871C-51AB24A8EAEE@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.7.130812 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-10-21_05:2013-10-22, 2013-10-21, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1310210152 Cc: "msec@ietf.org" , Sean Turner , "draft-weis-gdoi-iec62351-9@tools.ietf.org" Subject: Re: [MSEC] Review comments, was RE: GDOI support for IEC 62351 X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Oct 2013 03:55:57 -0000 On 10/21/13 11:09 AM, "Brian Weis" wrote: >Hi Paul, > >On Oct 18, 2013, at 6:14 PM, Paul Lambert wrote: > >>=20 >>>=20 >>> We decided to drop support for AES-GCM here because there doesn't seem >>>to >>> be a safe way to use AES-GCM in the GOOSE and SV security transforms. >>> AES-GCM takes a counter as input, but there is no explicit counter >>> defined in the IEC documents by which the receiver would know what >>> counter to use for decryption (or for integrity protection if AES-GMAC >>>is >>> used). >> So what's used instead? > >The draft specifies AES-CBC for confidentiality, and HMAC-SHA256 for >integrity. Thanks. > >Brian > >>=20 >> Paul >>=20 > >--=20 >Brian Weis >Security, Enterprise Networking Group, Cisco Systems >Telephone: +1 408 526 4796 >Email: bew@cisco.com >