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

• Status
• Email expansions
• History

• Versions
• 00

Review
review-weis-gdoi-iec62351-9-08-secdir-lc-nir-2016-10-06

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