Group Domain of Interpretation (GDOI) Protocol Support for IEC 62351 Security Services
draft-weis-gdoi-iec62351-9-10

[Ballot comment]

Thanks for adding the suggested cautionary text.

OLD COMMENTS BELOW, I didn't check 'em.

- I'm left wondering why the IETF is doing this rather
than changing the registration rules for existing
registries (e.g. along the lines being followed for
TLS1.3) so that IEC could do the work themselves?

- The various algorithm codepoints listed at [GDOI-REG]
seem fairly outdated. Is it really a good idea to extend
those as is being done here by adding new registries for
modern ciphers? (It may be the case that we are doing
this because there is implementer energy for this, but
not for a general revamp of GDOI.)

[Ballot comment]
I would support adding a note as Stephen proposed in his Discuss, about the IETF's ability to evaluate this specification in the absence of access to referenced documents.

[Ballot discuss]

I'm not clear how to evaluate the security properties of
this protocol given that the IEC specs on which it builds
aren't visible to me. (Or at least I didn't find a
version I could access.) That's made worse by my relative
ignorance of GDOI as well.

So I wonder should the authors or IESG add a note to that
effect? Say along the lines of:

"This memo extends RFC6407 in order to define extensions
needed by IEC62351-9. With the current IANA registry
rules setup by RFC6407, this requires a standards action
by the IETF - essentially that means the production of
this document. As the relevant IEC specifications are not
available to the IETF community, it is not possible for
this RFC to fully describe the security considerations
applying. Implementers therefore need to depend on the
security analysis within the IEC specifications. As two
different SDOs are involved here, and since group key
management is inherently complex, it is possible some
security issues have not been identified, so additional
analysis of the security of the combined set of
specifications may be advisable."

I'd be fine with any wording that calls out that the IETF
can't really be sure of the overall outcome here. Note
that that's not in any way to doubt the authors' own
analysis - but given that we know it is quite possible
for fewer eyeballs to lead to gaps, and that this really
is a complicated beast solving a complicated problem, I'm
a bit concerned that we may miss something.

[Ballot comment]

- I'm left wondering why the IETF is doing this rather
than changing the registration rules for existing
registries (e.g. along the lines being followed for
TLS1.3) so that IEC could do the work themselves?

- The various algorithm codepoints listed at [GDOI-REG]
seem fairly outdated. Is it really a good idea to extend
those as is being done here by adding new registries for
modern ciphers? (It may be the case that we are doing
this because there is implementer energy for this, but
not for a general revamp of GDOI.)

(Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has completed its review of draft-weis-gdoi-iec62351-9-08.txt. If any part of this review is inaccurate, please let us know.

Upon approval of this document, we understand that there are five registry actions to complete.

First, in the GDOI ID Payload Type Values subregistry of the Group Domain of Interpretation (GDOI) Payloads registry located at:

https://www.iana.org/assignments/gdoi-payloads/

a new value is to be registered as follows:

Value: [ TBD-at-registration ]
ID Type: GDOI_PROTO_IEC_61850
Reference: [ RFC-to-be ]

Question --> We understand the next four requests in section 4 of the document to be requests for the creation of four new registries. For each registry: Where should this new registry be located? Is it a new registry on the List of all IANA maintained protocol parameter registries or is it a subregistry of an existing registry? If it is a subregistry of an existing registry, in which registry will it be contained?

Second, a new registry is to be created called the IEC62351-9 Authentication Values registry. The registry will be created in a location to be determined in consultation with the authors (see Question, above). The new registry will be managed through Expert Review and Private Use as defined by RFC 5226. There are initial values in the new registry as follows:

Name Value Reference
--------------------------+---------+-------------------
Reserved 0 [ RFC-to-be ]
NONE 1 [ RFC-to-be ]
HMAC-SHA256-128 2 [ RFC-to-be ]
HMAC-SHA256 3 [ RFC-to-be ]
AES-GMAC-128 4 [ RFC-to-be ]
AES-GMAC-256 5 [ RFC-to-be ]
Expert Review 6-61439 [ RFC-to-be ]
Private Use 61440-65535[ RFC-to-be ]

Third, a new registry is to be created called the IEC62351-9 Confidentiality Values registry. The registry will be created in a location to be determined in consultation with the authors (see Question, above). The new registry will be managed through Expert Review and Private Use as defined by RFC 5226. There are initial values in the new registry as follows:

Name Value Authenticated Encryption Reference
---------------------+-------------+------------------------+------------------------
Reserved 0 [ RFC-to-be ]
NONE 1 [ RFC-to-be ]
AES-CBC-128 2 N [ RFC-to-be ]
AES-CBC-256 3 N [ RFC-to-be ]
AES-GCM-128 4 Y [ RFC-to-be ]
AES-GCM-256 5 Y [ RFC-to-be ]
Expert Review 6-61439 [ RFC-to-be ]
Private Use 61440-65535 [ RFC-to-be ]

Fourth, a new registry is to be created called the GDOI SA TEK Attributes registry. The registry will be created in a location to be determined in consultation with the authors (see Question, above). The new registry will be managed through Expert Review and Private Use as defined by RFC 5226. There are initial values in the new registry as follows:

Attribute Value Type Reference
-----------------+---------------+---------+-----------------
Reserved 0 [ RFC-to-be ]
SA_ATD 1 V [ RFC-to-be ]
SA_KDA 2 B [ RFC-to-be ]
Expert Review 3-28671 [ RFC-to-be ]
Private Use 28672-32767 [ RFC-to-be ]

Fifth, a new registry is to be created called the GDOI Identification Payload registry. The registry will be created in a location to be determined in consultation with the authors (see Question, above). The new registry will be managed through Expert Review and Private Use as defined by RFC 5226. There are initial values in the new registry as follows:

Name Value Reference
-----------------------+-----------+----------------------+
Reserved 0 [ RFC-to-be ]
ID_IPV4_ADDR 1 [ RFC-to-be ]
ID_FQDN 2 [ RFC-to-be ]
ID_USER_FQDN 3 [ RFC-to-be ]
ID_IPV4_ADDR_SUBNET 4 [ RFC-to-be ]
ID_IPV6_ADDR 5 [ RFC-to-be ]
ID_IPV6_ADDR_SUBNET 6 [ RFC-to-be ]
ID_IPV4_ADDR_RANGE 7 [ RFC-to-be ]
ID_IPV6_ADDR_RANGE 8 [ RFC-to-be ]
ID_DER_ASN1_DN 9 [ RFC-to-be ]
ID_DER_ASN1_GN 10 [ RFC-to-be ]
ID_KEY_ID 11 [ RFC-to-be ]
ID_LIST 12 [ RFC-to-be ]
ID_OID 13 [ RFC-to-be ]
Expert Review 14-61439 [ RFC-to-be ]
Private Use 61440-65535 [ RFC-to-be ]

We understand that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.


Thank you,

Sabrina Tanamal
IANA Services Specialist
PTI

The following Last Call announcement was sent out:

From: The IESG
To: "IETF-Announce"
CC: Kathleen.Moriarty.ietf@gmail.com, draft-weis-gdoi-iec62351-9@ietf.org, joe@salowey.net
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (GDOI Protocol Support for IEC 62351 Security Services) to Proposed Standard


The IESG has received a request from an individual submitter to consider
the following document:
- 'GDOI Protocol Support for IEC 62351 Security Services'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2016-10-24. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  The IEC 61850 power utility automation family of standards describe
  methods using Ethernet and IP for distributing control and data
  frames within and between substations.  The IEC 61850-90-5 and IEC
  62351-9 standards specify the use of the Group Domain of
  Interpretation (GDOI) protocol (RFC 6407) to distribute security
  transforms for some IEC 61850 security protocols.  This memo defines
  GDOI payloads to support those security protocols.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-weis-gdoi-iec62351-9/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-weis-gdoi-iec62351-9/ballot/


No IPR declarations have been submitted directly on this I-D.

There is a possible downref to IEC-62351-9.

1. Summary

The document shepherd is Joe Salowey. The responsible Area Director is Kathleen Moriarty.

This document extends an IETF protocol (GDOI, published as RFC 7407), which distributes IPsec security association policy and keying material used to protect IP multicast packets . The IEC 61850 power utility automation family of standards defines it’s own transport security methods for multicast packets, and these standards specify the use of GDOI to provide the necessary policy and keying material. This draft specifies how the IEC 61850 policy and keying material is distributed within the GDOI protocol.

2. Review and Consensus

The document is an individual submission. The logical working group to have progressed this would have been the Multicast Security (MSEC) WG, which has been closed from some time. The document has been reviewed by several individuals in the IETF Security Area, as well as the IEC 61850 working group. An early SecDir review was published on -02 of this document, and the authors believe that each of the comments were addressed.: .

3. Intellectual Property

Each author has confirmed conformance with BCP 78/79. There are no IPR disclosures on the document.

4. Other Points

No other points have been identified.