Skip to main content

Early Review of draft-weis-gdoi-iec62351-9-02
review-weis-gdoi-iec62351-9-02-secdir-early-nir-2013-11-07-00

Request Review of draft-weis-gdoi-iec62351-9
Requested revision No specific revision (document currently at 10)
Type Early Review
Team Security Area Directorate (secdir)
Deadline 2016-10-25
Requested 2013-11-07
Authors Brian Weis , Maik Seewald , Herb Falk
I-D last updated 2013-11-07
Completed reviews Genart Last Call review of -08 by Vijay K. Gurbani (diff)
Genart Last Call review of -09 by Vijay K. Gurbani (diff)
Secdir Early review of -02 by Yoav Nir (diff)
Secdir Last Call review of -08 by Yoav Nir (diff)
Opsdir Last Call review of -08 by Carlos Pignataro (diff)
Assignment Reviewer Yoav Nir
State Completed
Request Early review on draft-weis-gdoi-iec62351-9 by Security Area Directorate Assigned
Reviewed revision 02 (document currently at 10)
Result Has issues
Completed 2013-11-07
review-weis-gdoi-iec62351-9-02-secdir-early-nir-2013-11-07-00
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