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

[Sean Turner <[e-mail]>]

Yoav,

Please do submit it like a regular secdir review.

spt

On Nov 03, 2013, at 04:18, Herb Falk <[e-mail]> wrote:

> See below.
>  
> Herbert Falk
> Solutions Architect
> SISCO, INC.
> 6605 19 ½ Mile Rd.
> Sterling Heights, MI 48314
> [phone] x-105
>  
>  
>                                                                               
> "In matters of style, swim with the current;   in matters of principle, stand like a rock." [Thomas Jefferson]
>  
>  
> NOTICE: This communication may contain privileged or other confidential information. If you are not the intended recipient, or believe that you have  received this communication in error, please do not print, copy, retransmit,  disseminate, or otherwise use the information. Also,  please indicate to the sender that you have received this communication in error, and delete the copy you received. Thank you.
>  
> -----Original Message-----
> From: Yoav Nir [mailto:[e-mail]] 
> Sent: Sunday, November 03, 2013 1:44 AM
> To: Sean Turner
> Cc: [e-mail]; Jeff Gooding/SCE/EIX; Maik Seewald (maseewal); [e-mail]; Madani, Vahid; Adamiak, Mark (GE Energy Management); Novosel, Damir; Thanos, Daniel (GE Energy Management); Herb Falk <[e-mail]>; Alex Apostolov ([e-mail])
> Subject: Re: [MSEC] Key Management protocol (GDOI - 6407) forward
>  
> 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 <[e-mail]> 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 <[e-mail]> 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.
>  
> [Herb]:  BER encoding is what was intended.
>  
> 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?
>  
> [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.
> 
>  
>  
> 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.
>  
> [Herb]: The best I can do is to describe the use of the protocols.  IEC 61850 is used for the command/control of the power grid.  There are three prevalent uses for 61850:  peer-to-peer communication (e.g. client/server), multicast for high speed state exchange and control (4msec time frame), sampled values used for high speed Current Transformer/Voltage Transformer samples  (this is a 15MB load per source/network).  Additionally, IEC 61850-90-5 is designed to route GOOSE and a lower speed SV used for synchrophasor measurements (some good information about synchrophasors can be found at: https://www.naspi.org/).
>  
> 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.
>  
> [Herb]:  If I understand the question, originally, we had used a “private” value.  It had been hoped that the IETF/IANA would provide a standard number.  It is not semantically correct for IEC to claim IKE, when it is not.  That would cause confusion in the IEC standards.  Obviously, this application of GDOI was not anticipated and thus some type of expansion is needed.  If IETF indicates that it won’t extend for an IEC standard (e.g. only IETF standards, that seem a bit odd.  As with all standards, the sea of application is always changing and standards need to be changed to as the climate changes.  IEC has always referenced IETF  RFCs.  I can’t officially speak on behalf of IEC, but my personal opinion is that it is a bit strange to say the “ship has left the station”  when a standards organization has a new use case.
>  
> 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.
>  
> [Herb]:  There are several reasons to use the OID.  One is that it allows other smart grid applications/protocols to expand the usage of other domains (e.g. avoid the “ship has left the station issue).  The other is to specifically encode it so easy comparisons can occur.  Hope that helps.
>  
> 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?
>  
> [Herb]:  The use of GDOI, for 90-5, is intended to have keys that are based upon a combination of content/protocol/destination.  There are 3 protocols (CS, GOOSE, SV).  All three define the content to be transferred to a particular destination as a set of Data called DataSets.  SV and GOOSE can be sent via 90-5 or directly as an Ethertype.  Therefore, the combinations/permutations lead to the following list in 90-5:
>  
> 61850_ETHERNET_GOOSE
> Specifies that the payload is requesting a key for a IEC 61850-8-1 GOOSE APDU, with IEC 62351-6 signature, that is being sent to a particular destination Ethernet address.
> 1.2.840.10070.61850.8.1.1
> 61850_UDP_ADDR_GOOSE
> Specifies that the payload is requesting a key for a IEC 61850-90-5 GOOSE APDU that is being sent to a particular destination IP address.
> 1.2.840.10070.61850.8.1.2
> 61850_UDP _Tunnel
> Specifies that the payload is requesting a key for a IEC 61850-90-5 Tunnel APDU that is being sent to a particular destination IP address.
> 1.2.840.10070.61850.8.1.4
> 61850_ETHERNET_SV
> Specifies that the payload is requesting a key for a IEC 61850-9-2 SV APDU, with IEC 62351-6 signature, that is being sent to a particular destination Ethernet address.
> 1.2.840.10070.61850.9.2.1
> 61850_UDP_ADDR_SV
> Specifies that the payload is requesting a key for a IEC 61850-90-5 SV APDU that is being sent to a particular destination IP address.
> 1.2.840.10070.61850.9.2.2
> 61850_IP_ISO9506
> Specifies that the payload is requesting a key for a IEC 61850-8-1 ISO 9506 endpoint. This payload definition is out-of-scope of this specification.
> 1.2.840.10070.61850.8.1.4
>  
>  
> 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?
>  
> [Herb]:  If 4 is the normal, then lets make it 4.  What is the value ordering (Network transmission or other)?
>  
> Yoav
>  
> [1] http://www.iana.org/assignments/ipsec-registry/ipsec-registry.xhtml#ipsec-registry-10
> [2] http://tools.ietf.org/html/rfc6932      
>  
>  
>  
>  
>  
>  
>