Re: [secdir] SecDir Review of draft-weis-gdoi-iec62351-9-08

["Brian Weis (bew)" <[e-mail]>]

Hi Yoav,

Thanks for your careful review. A last minute change before publishing -08 caused some inconsistencies that you have noted below, and I’ve added some comments inline addressing those inconsistencies.

> On Oct 4, 2016, at 9:38 AM, Yoav Nir <[e-mail]> wrote:
> 
> 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.

This text was not precisely matching the operational realities of networks where this standard will be used. This became even more apparent when addressing the last issue that you noted below.  In reality, there are a number of operational environments where these devices will be deployed: in some cases they are in a private network where traffic does not need to protected on a private network, and a site security policy will protect the traffic with network-level encryption (such as an IPsec tunnel) when it leaves the private network. In other cases, the application traffic needs to be protected at the end host. 

While authentication is a firm requirement when a cipher is used, there are cases where neither authentication nor confidentiality is absolutely required. In a simple world this would result in a distributed policy where a group member were configured with exactly which flows did not requiring protection and does not need to ask a central Group Controller/Key Server (GCKS) how to protect the flow. But a system using a centralized key management system generally is one where configuring such granulated distributed policy is not operationally feasible. Therefore, it can make sense for the group member to ask the GCKS on a flow by flow basis how to protect it, and sometimes get a response that it is not to be protected. This is especially true during a migration period, where the policy for each flow is individually converted from unprotected to protected by the GCKS administrator.

Addressing this need requires re-instating the NONE value in both Authentication Algorithm and Confidentiality Algorithm lists. (These values had been present in -07).  We also propose the following additions to the Security Considerations section to clarify how these are used. Does it seem adequate to you?

   IEC 62351 Security Services describes a variety of policy choices for
   protecting network traffic, including the option of specifying no
   protection at all.  This is enabled with the use of NONE as an
   Authentication Algorithm and/or Confidentiality Algorithm.  The
   following guidance is given regarding the use of NONE.

   o  Setting both Authentication Algorithm and Confidentiality
      Algorithm to NONE is possible, but NOT RECOMMENDED.  Setting such
      a policy is sometimes necessary during a migration period, when
      traffic is being protected incrementally and some traffic has not
      yet been scheduled for protection.  Alternatively, site security
      policy for some packet flows requires inspection of packet data on
      the private network followed by network-layer encryption before
      delivery to a public network.

   o  Setting the Confidentiality Algorithm to NONE, but setting the
      Authentication Algorithm to a MAC can be an acceptable policy in
      the following conditions: the disclosed information in the data
      packets is comprised of raw data values, and the disclosure of the
      data files is believed to be of no more value to an observer than
      traffic analysis on the frequency and size of packets protected
      for confidentiality.  Alternatively, site security policy for some
      packet flows requires inspection of packet data on the private
      network followed by network-layer encryption before delivery to a
      public network.

   o  Setting the Authentication Algorithm to NONE, but setting the
      Confidentiality Algorithm to an algorithm that does not includes
      authentication is not safe, and MUST NOT be specified.


> 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?

The removal of the NONE value from the Authentication Algorithm list (present in -07) caused this problem, just as you imply. It will be reinstated, accompanied by some precise text describing with which Confidentially Algorithms MUST and MUST not be accompanied by  the NONE Authentication Algorithm value. I.e., the defined AES-CBC algorithms MUST NOT be used with a NONE Authentication Algorithm, and AES-GCM algorithms MUST be used with an Authentication Algorithm. The example payloads in Appendix A will also be corrected.

Thanks,
Brian

> 
> Yoav
> 
> [1] https://mailarchive.ietf.org/arch/msg/secdir/-C5_XjfTk42DO013DkbA6q0tQmA
> _______________________________________________
> secdir mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/secdir
> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview

-- 
Brian Weis
Security, CSG, Cisco Systems
Telephone: [phone]
Email: [e-mail]