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

[Kathleen Moriarty <[e-mail]>]

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) <[e-mail]> 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.
>
> > 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]
>
>


-- 

Best regards,
Kathleen