Hi Yoav,

A new version has been posted that we believe address each of your comments.
	<http://datatracker.ietf.org/doc/draft-weis-gdoi-iec62351-9/>
Let us know if you have further questions or suggestions.

Significant changes:
- Clarification that DER encoding is required
- Added a bit more text describing the relationship between IEC standards
- Moved a normative reference to be informative
- Small corrections to the example in Appendix A
- Added Appendix B (Implementation Considerations) to provide guidance in case some of your questions come up again

Thanks,
Brian

On Nov 4, 2013, at 2:04 AM, Brian Weis <bew@cisco.com> wrote:

> Hi Yoav,
> 
> Many thanks for your review.
> 
> On Nov 3, 2013, at 10:54 AM, Yoav Nir <ynir@checkpoint.com> wrote:
> 
>> 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.
> 
> The draft actually uses DER encoding, which I believe is the case for most ASN.1 encoding in RFCs. This should be stated to avoid confusion. 
> 
>> 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?
> 
> For the benefit of the secdir audience here's Herb's reply from the original email thread and your reply:
> 
>>> [Herb]:  I don’t understand the question.  So I will try to explain.  IEC 61850 is a set of communication standards developed under IEC Technical Committee 57.  IEC TC57 has WG15 that was formed to address security for the breadth of standards that are developed under TC57, including IEC 61850.  In IEC, the designations within a family of standards (e.g. 61850 or 62351) are called parts.  IEC 61850 has over 10 standards that are 61850-1 through 61850-10 (e.g. 10 parts).   Chapters/sub-chapters are called “clauses” in IEC.  So when it mentions IEC 62351 Part 9 – Key Management, the official reference is  “IEC 62351-9 Ed. 1.0 Power systems management and associated information exchange - Data and communications security - Part 9: Cyber security key management for power system equipment (Future IEC 62351-9 TS Ed.1)”.  When IEC removes the ED 1.0, it means refer to the current revisions (ED.2 has almost been completed).  The “Power systems management and associated information exchange - Data and communications security” is the charter of WG15 and the overall scope of 62351 (they all have that in their title).  Therefore, “IEC 62351 Part 9 – Key Management” could be referred to as “IEC 62351-9”, “IEC 62351-9 : Cyber security key management for power system equipment”, or in presentations “IEC 62351-9– Key Management”.   So, I would change to IEC 62351-9 (and give the full name).  Sorry for the long explanation.
>>> 
>> [Yoav] OK. I guess the IEC standards have a more complicated naming convention than RFCs .I'm just missing an overall title for 62351. 
> 
> We can summarize Herb's description above in the Introduction, if that would help.
> 
>> 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.
> 
> OK.
> 
>> 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.
> 
> This is a different situation from RFC 6932. (In fact, since GDOI is IKEv1-based what you're asking for will add to the RFC 2409 registries, which RFC 6932 says is discouraged.)
> 
> I have some sympathy for saying we should have one list of algorithms that all protocols should use, but in fact every protocol (in this case the IEC set of protocols) would have to declare which subset of the algorithm list they support in a normative fashion. That complexity does not belong in the notes section of [1], IMO. Non-IPsec protocol-specific subsets will change over time and have to be maintained somewhere ... a new protocol-specific registry is the right place to do that.
> 
> By the way, the IEC standards defines truncation values for HMAC-SHA256 that are not duplicates.
> 
>> 
>> 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.
> 
> The OID_LENGTH field is not strictly required, since the DER includes the length. Maintaining the length outside of the DER is valuable for payload manipulation where parsing the DER is not otherwise necessary (e.g., copying the DER into the payload, payload length sanity checks, etc.). We'll add that.
>> 
>> 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,
> 
> The OID in the ID payload will match the OID in the TEK payload if the group represented by the ID payload has only one multicast sender. This is shown in Appendix A (modulo a typo, see below). Sorry for the confusion.
> 
> To answer the broader question, there could be multiple multicast senders represented by the OID, so the group key server would return multiple TEKs, each with unique OID & OID specific payload. This can be made clearer in the draft.
> 
>> - what does "type of traffic" mean?
> 
> The IEC documents list several OID types, each of which is a "type of traffic". This can be expanded.
> 
>> 
>> - Appendix A says "OID=<ASN.1 for k>" in the TEK payload. What is k?
> 
> That is a typo. It should be "OID=<ASN.1 for 1.2.840.10070.61850.8.1.2>" matching the ID payload.
> 
> Thanks,
> Brian
> 
>> 
>> 
>> Yoav
>> 
>> [1] http://www.iana.org/assignments/ipsec-registry/ipsec-registry.xhtml#ipsec-registry-10
>> [2] http://tools.ietf.org/html/rfc6932	
>> 
>> 
>> _______________________________________________
>> secdir mailing list
>> secdir@ietf.org
>> https://www.ietf.org/mailman/listinfo/secdir
>> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview
> 
> -- 
> 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