Last Call Review of draft-weis-gdoi-iec62351-9-08
review-weis-gdoi-iec62351-9-08-secdir-lc-nir-2016-10-06-00

Hi.

I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG. These comments
were written primarily for the benefit of the security area directors. Document
editors and WG chairs should treat these comments just like any other last call
comments.

Summary: Ready with a question

The draft describes using GDOI with some extensions to transport keying
material for the IEC 61850 power utility automation family of standards.

I have previously reviewed version -02 of the draft three years ago ([1]).
Later versions addressed my issues about the document being too opaque for
people not versed in IEC protocols and terminology. It is still rather hard to
read without the relevant background, but that is to be expected in a document
targeted at a very specific audience (which I am not part of).

The Security Considerations section points to the section in RFC 6407 (GDOI).
Additional paragraphs point out that message authentication is mandatory, while
confidentiality is optional.  And yet the same paragraph makes confidentiality
a SHOULD if the packets are expected to traverse the public Internet. The last
sentence says that 128-bit AES-CBC is good enough for the foreseeable future,
"but some security policies may require the use of AES-CBC-256.” There is no
mention of why such policies may require this. The usual reason is to protect
against future attacks by quantum computers, but I think it’s fine to leave
that out.

My question is about the IEC-61850 SA TEK Payload described in Figure 4 in
section 2.2. It has separate fields for Auth Alg and Enc Alg. The Enc Alg field
has 4 possible values described in section 2.2.3, including AES-GCM-128 and
AES-GCM-256. AES-GCM is an AEAD algorithm. As such it should not be used in
conjunction with a MAC algorithm. Other protocols either omit the MAC algorithm
when an AEAD is used, or create a special ‘none’ value for such cases. Here
there are no None value (though there are two Reserved values in the IANA
considerations section). This makes it possible to have SA TEK payloads with
AES-GCM-128 and HMAC-SHA256-128.  How do you even do that? And why?

Yoav

[1]

https://mailarchive.ietf.org/arch/msg/secdir/-C5_XjfTk42DO013DkbA6q0tQmA