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

Brian Weis <bew@cisco.com> Wed, 16 October 2013 15:41 UTC

Return-Path: <bew@cisco.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 CE16F11E82D9 for <msec@ietfa.amsl.com>; 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 <msec@ietfa.amsl.com>; 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 <msec@ietf.org>; 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 <bew@cisco.com>
In-Reply-To: <CE834B4B.25AE9%paul@marvell.com>
Date: Tue, 15 Oct 2013 21:15:24 -0700
Message-Id: <E87892BC-C8F4-4250-BE62-C2A41ED13E43@cisco.com>
References: <CE834B4B.25AE9%paul@marvell.com>
To: Paul Lambert <paul@marvell.com>
X-Mailer: Apple Mail (2.1510)
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: Wed, 16 Oct 2013 15:41:57 -0000

Hi Paul,

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

> 
> 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.

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

> 
> Paul
> 
> 
>> Hi Paul,
>> 
>> On Oct 14, 2013, at 6:10 PM, Paul Lambert <paul@marvell.com>; wrote:
>> 
>>> 
>>> 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?  
>> 
>> 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 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 – 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
>> 
>>> 
>>> 
>>> 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
>>>>> 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