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

From: Yoav Nir <[email-masked]>
Date: Tue, 4 Oct 2016 19:38:33 +0300

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

---

From: "Brian Weis (bew)" <[email-masked]>
Date: Fri, 14 Oct 2016 18:08:14 +0000

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 <[email-masked]> wrote:
> 
> Hi.
> 
> 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.
> 

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

> _______________________________________________
> secdir mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/secdir
> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview

-- 
Brian Weis
Security, CSG, Cisco Systems
Telephone: +1 408 526 4796
Email: [email-masked]

---

From: Kathleen Moriarty <[email-masked]>
Date: Fri, 14 Oct 2016 15:07:02 -0400

Brian & Yoav,

Thank you for your review, Yoav and for catching a problem caused by my
review and a question I asked to see if the none was needed or not.  This
is an important change and as such, I'd like to see the updated text
published now rather than after last call ends so any other reviews are
able to see this change.  The shepherd, Brian and I all reviewed the text.

If Yoav is able to respond quickly, then I'd include any other changes if
they are needed, otherwise, it owuld be good to publish this updated
version and hold any other changes until after the last call period ends.

Thank you,
Kathleen

On Fri, Oct 14, 2016 at 2:08 PM, Brian Weis (bew) <[email-masked]> wrote:

> 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.
>
> > I have reviewed this document as part of the security directorate's
> ongoing effort to review all IETF documents being processed by the IESG.
> > 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?
>
> > 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
> >

-- 

Best regards,
Kathleen