Subject: [dtn] Default Security Context version -02

From: "Birrane, Edward J." <[email-masked]>
Date: Mon, 22 Feb 2021 04:40:19 +0000

All,

  I have issued a -02 version of the default security context document with the following updates:

- References have been updated
- A security considerations section has been added and discusses general key handling and some fragmentation discussion from the mailing list.
- A GCM considerations section has been added for the BCB-AES-GCM security context which covers considerations mentioned below.
- The key considerations section of each security context emphasizes the need to protect keys.

-Ed

---
Edward J. Birrane, III, Ph.D.
Embedded Applications Group Supervisor
Space Exploration Sector
Johns Hopkins Applied Physics Laboratory
(W) 443-778-7423 / (F) 443-228-3839

> -----Original Message-----
> From: R. Atkinson <[email-masked]>
> Sent: Friday, February 19, 2021 10:11 AM
> To: Birrane, Edward J. <[email-masked]>; Burleigh, Scott C
> <[email-masked]>
> Cc: Magnus Westerlund <[email-masked]>; iesg-
> [email-masked]; [email-masked]
> Subject: [EXT] Re: [dtn] Default-sc-01
> 
> APL external email warning: Verify sender [email-masked] before clicking
> links or attachments
> 
> All,
> 
> I would be very surprised if the IETF Security Area were interested in
> spending much time reviewing a document that lacked a "Security
> Considerations” section, since that part of the document often is the primary
> focus of IETF Security Area reviews.
> 
> This note perhaps provides some suggestions with an eye towards creating a
> “Security Considerations” section for this document.  I think reviews will go
> more easily if the document has a meaningful “Security Considerations”
> section before it goes out for review.
> 
> 
> 1. The reference to RFC-4634 likely should be replaced by a reference to RFC-
> 6234 — or BETTER by these two more authoritative and equally
> public/accessible references, one for the HMAC procedure and the second
> for SHA-2:
> 
> “US NIST, “The Keyed-Hash Message Authentication Code (HMAC)”, FIPS-
> 198-1, US NIST, Gaithersburg, MD, USA, July 2008.
> http://csrc.nist.gov/publications”
> 
> “US NIST, “Secure Hash Standard (SHS)”, FIPS 180-4, US NIST, Gaithersburg,
> MD, USA, August 2015.  http://csrc.nist.gov/publications”
> 
> 
> 2.  In Section 3.5, I am startled that the document provides no advice to
> protect keys when stored or distributed.  The existing text in 3.5 should be
> edited and also the "Security Considerations” section ought to strongly
> recommend that and also note that in the event any key(s) are
> compromised, then neither authentication nor integrity will be provided.
> 
> 3. In Section 4 & in Security Considerations, special attention should be made
> to the cautions about the uniqueness requirements for GCM which are
> noted in Section 8 & also in Appendix A of [AES-GCM].  This is critical
> whenever GCM is used.  Sadly, this requirement of GCM is either ignored or
> not understood by many implementers of other IETF protocols which use
> GCM.  So it is important to call this out specifically.  Perhaps also add a citation
> to [AES-GCM] to the last paragraph of Section 4.3.1 of this document and
> point specifically to Appendix A in that citation.
> 
> This document’s "Security Considerations" also should discuss the attacks on
> GCM described in Appendix B and the corresponding mitigations described in
> Appendix C of [AES-GCM].
> 
> Appendix D of [AES-GCM] discusses limitations relative to replay attacks,
> which also should be mentioned and discussed in this document's “Security
> Considerations”.
> 
> (Aside:  I have no special issues with GCM as a cryptographic mode to specify
> here, but GCM does have specific requirements which implementers need
> to follow and which ordinary software/firmware developers generally are
> not aware of.  An important purpose for IETF “Security Considerations”
> sections is to point these types of things out very clearly, so a naive but well-
> intentioned developer can implement in a reasonably secure way. :-)
> 
> 4. I would suggest reviewing the text in RFC-8152, Section 17, “Security
> Considerations” with an eye to adapting that text for inclusion in the
> “Security Considerations” section needed for this document.
> 
> Yours,
> 
> Ran
> 
> > On Feb 19, 2021, at 00:27, Burleigh, Scott C (US 312B)
> <scott.c.burleigh=[email-masked]> wrote:
> >
> > Hi, Magnus.  Here are the Document Shepherd write-up and accompanying
> Document Announcement I've come up with for the BPSec Default Security
> Contexts specification.  There are nits, but we would like to address them in
> the course of the review.
> >
> > Scott
> > <defsc shepherd writeup.docx><defsc document
> announcement.txt>___________________________________________
> ____
> > dtn mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/dtn