Re: [MSEC] Key Management protocol (GDOI - 6407) forward

Paul Lambert <paul@marvell.com> Tue, 15 October 2013 01:10 UTC

Return-Path: <paul@marvell.com>
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 <msec@ietfa.amsl.com>; 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 <msec@ietfa.amsl.com>; 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 <msec@ietf.org>; 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 <paul@marvell.com>
To: Brian Weis <bew@cisco.com>
Date: Mon, 14 Oct 2013 18:10:28 -0700
Thread-Topic: [MSEC] Key Management protocol (GDOI - 6407) forward
Thread-Index: Ac7JQ1ZH623ZFZeWRFuL5jHSu7j86Q==
Message-ID: <CE81E145.255E7%paul@marvell.com>
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" <msec@ietf.org>, Jeff Gooding/SCE/EIX <Jeff.Gooding@sce.com>, "Maik Seewald (maseewal)" <maseewal@cisco.com>, "Andrew.Free@sce.com" <Andrew.Free@sce.com>, "Madani, Vahid" <VxM6@pge.com>, "Adamiak, Mark (GE Energy Management)" <mark.adamiak@ge.com>, "Novosel, Damir" <DNovosel@Quanta-Technology.com>, "Thanos, Daniel (GE Energy Management)" <Daniel.Thanos@ge.com>, "Herb Falk <herb@sisconet.com>" <Herb@sisconet.com>, "Alex Apostolov (alex.apostolov@omicronusa.com)" <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 <msec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/msec>, <mailto:msec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/msec>
List-Post: <mailto:msec@ietf.org>
List-Help: <mailto:msec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/msec>, <mailto:msec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 15 Oct 2013 01:10:41 -0000

Brian,

Thanks for the info …


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  … 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 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 – impossible in ad hoc environments).


Regards,

Paul



Thanks,
Brian


Thanks in advance,

Paul







Herbert Falk
Solutions Architect
SISCO, INC.
6605 19 1Ž2 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<mailto: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<mailto:bew@cisco.com>