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

Yoav Nir <ynir@checkpoint.com> Sun, 03 November 2013 06:44 UTC

Return-Path: <ynir@checkpoint.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 B76E211E81A9 for <msec@ietfa.amsl.com>; Sat, 2 Nov 2013 23:44:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.491
X-Spam-Level:
X-Spam-Status: No, score=-10.491 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a5DUXFIXAij1 for <msec@ietfa.amsl.com>; Sat, 2 Nov 2013 23:44:09 -0700 (PDT)
Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id AD78E11E81A5 for <msec@ietf.org>; Sat, 2 Nov 2013 23:44:06 -0700 (PDT)
Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id rA36hmUE002186; Sun, 3 Nov 2013 08:43:49 +0200
X-CheckPoint: {5275EF65-2-1B221DC2-1FFFF}
Received: from IL-EX10.ad.checkpoint.com ([169.254.2.106]) by DAG-EX10.ad.checkpoint.com ([169.254.3.213]) with mapi id 14.03.0123.003; Sun, 3 Nov 2013 08:43:48 +0200
From: Yoav Nir <ynir@checkpoint.com>
To: Sean Turner <turners@ieca.com>
Thread-Topic: [MSEC] Key Management protocol (GDOI - 6407) forward
Thread-Index: Ac67FJGyoGPYHJStQ3mYygEDVBEZfAAEfu0gABl+LQAABa9lgACNPdEAAADvBAAAAE6HgAAAcUCABpwUlYA=
Date: Sun, 03 Nov 2013 06:43:48 +0000
Message-ID: <0EC5982A-FAF2-4A67-9F4E-720CE0912DDC@checkpoint.com>
References: <CB6C229361B2E34190B3BF9F6EC922224DCCB760@EXCHMBSF323.Utility.pge.com> <418E74FA535F654FAB3CAAE12902E2940156AA80@SISCO-SBS.sisconet.local> <7417090A-55F1-42ED-B051-1EB197DAAB52@checkpoint.com> <5245E431.8070208@concordia.ca> <5249980C.2090201@ieca.com> <FE7558EA-CB7F-46B9-A973-00CBB0CE167A@checkpoint.com> <5249A05F.6060207@ieca.com> <85CF9F24-C02C-491D-A000-487B7A524F97@checkpoint.com>
In-Reply-To: <85CF9F24-C02C-491D-A000-487B7A524F97@checkpoint.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [172.31.20.63]
x-kse-antivirus-interceptor-info: scan successful
x-kse-antivirus-info: Clean
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <653B8385AA82A04F987F6BB3E7AD4FEB@ad.checkpoint.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "msec@ietf.org" <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>, "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: Sun, 03 Nov 2013 06:44:17 -0000

Hi

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

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

> OK, I'll do it. 
> 
> At the latest, on the 20-hour journey to Vancouver. Hopefully earlier.
> 
> Yoav
> 
> On Sep 30, 2013, at 7:01 PM, Sean Turner <turners@ieca.com> wrote:
> 
>> IEC is usually paired with ISO ;)  There's the rub right - I read it and was like sure I take your word Brian.  I think that you could treat it kind of like a secdir review and that would be sufficient for me.
>> 



Hi, there.

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

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

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

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

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

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

I didn't quite get where each of the OIDs in the ID payload (figure 2) and the TEK payload (figure 4) come from. Are they the same? Appendix A suggests that they're not. So,
 - what does "type of traffic" mean?  
  - Appendix A says "OID=<ASN.1 for k>" in the TEK payload. What is k?

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


Yoav

[1] http://www.iana.org/assignments/ipsec-registry/ipsec-registry.xhtml#ipsec-registry-10
[2] http://tools.ietf.org/html/rfc6932