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 rev. no specific revision (document currently at 10)
Type Early Review
Team Security Area Directorate (secdir)
Deadline 2016-10-25
Requested 2013-11-07
Draft last updated 2013-11-07
Completed reviews Genart Last Call review of -08 by Vijay Gurbani (diff)
Genart Last Call review of -09 by Vijay 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
Review review-weis-gdoi-iec62351-9-02-secdir-early-nir-2013-11-07
Reviewed rev. 02 (document currently at 10)
Review result Has Issues
Review completed: 2013-11-07

Review
review-weis-gdoi-iec62351-9-02-secdir-early-nir-2013-11-07

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