[secdir] SecDir-ish Review of draft-weis-gdoi-iec62351-9-02

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

From: Yoav Nir <ynir@checkpoint.com>
To: "<secdir@ietf.org>" <secdir@ietf.org>, The IESG <iesg@ietf.org>, "draft-weis-gdoi-iec62351-9@tools.ietf.org" <draft-weis-gdoi-iec62351-9@tools.ietf.org>
Thread-Topic: SecDir-ish Review of draft-weis-gdoi-iec62351-9-02
Thread-Index: AQHO2MYb3pOxi66Il0e9xzu1/y7hHQ==
Date: Sun, 03 Nov 2013 18:54:21 +0000
Message-ID: <BABB2778-7560-4347-92A6-C191218C3EFB@checkpoint.com>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-ID: <182A91B1B980654692283DE866B5BEC9@ad.checkpoint.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [secdir] SecDir-ish Review of draft-weis-gdoi-iec62351-9-02
Precedence: list

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 BER, 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?

Yoav

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

[secdir] SecDir-ish Review of draft-weis-gdoi-iec… Yoav Nir
Re: [secdir] SecDir-ish Review of draft-weis-gdoi… Brian Weis
Re: [secdir] SecDir-ish Review of draft-weis-gdoi… Brian Weis