Default Security Contexts for Bundle Protocol Security (BPSec)
draft-ietf-dtn-bpsec-default-sc-11

[Ballot comment]
I continue to be impressed with how the DTN WG and authors update their
documents in response to the review comments -- the changes are
carefully thought out and the entire document treated as a whole.  Thank
you!

Looking at the diff from -08 to -10, just a few final remarks:

Sections 3.3.3 and 4.3.4 still have some text about ignoring
unrecognized scope flags, which is not exactly problematic in light of
the (new) text about "MUST NOT be altered" between source and
destination, but it's also unclear how much value it adds.  One might
assume that any new scope flag will change processing in some manner and
thus result in a validation failure if used by the security source and
unrecognized at the security acceptor.

Section 4.5

  The security provided by block ciphers is reduced as more data is
  processed with the same key.  The total number of blocks processed
  with a single key for AES-GCM is recommended to be less than 2^64, as

I suggest s/total number of blocks/total number of AES blocks/ since BP
also deals in (potentially larger) blocks.

Section 4.7.1

  CBOR byte string.  Therefore, the plain text used during encryption
  MUST be calculated as the value of the block-type-specific data field
  of the security target excluding any CBOR encoding.

I think this is already pretty clear, but I'd consider s/any/the BP/,
since the contents of the block-type-specific data field might well be
CBOR encoded themselves, and we don't want to strip any of that
"internal" CBOR encoding.

Section 4.8.2

      The authentication tag MUST be present in the BCB security context
      parameters field.  This tag MUST be 128 bits in length.

I think this still needs a bit of tweaking to handle the case where the
tag is included in the BCB itself instead of as a security parameter,
which §4.8.1 has been nicely adapted to allow.

[Ballot comment]
Thanks for the new Section 5.4.  I would suggest not referring to the DTN working group as a review body, as it might not exist forever.  The guidance you publish here should still be valid even after the working group closes.

My original comments, for posterity:

I support Francesca's first DISCUSS point.

Since the shepherd writeup was written earlier this year, six revisions have been posted, the IESG has rotated (so the responsible AD in the writeup has changed), two authors have been added, two new registries were proposed (the writeup claims there are none), and a considerable amount of text has been added or changed.  The current writeup thus feels markedly stale; I suggest that in such situations, the shepherd should consider updating the writeup so that it appears to be more current when it gets to the IESG.

Appendix B could be simplified a bit:

  Amy Alford of the Johns Hopkins University
  Applied Physics Laboratory contributed useful review and analysis of
  these security contexts.

Document Shepherd Writeup for BPSec Default Security Contexts
Scott Burleigh
9 July 2021

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

A Proposed Standard is being requested.  The title page header indicates that the intended status is Standards Track, and the specification documented in the current Internet Draft is not yet mature enough to qualify as an Internet Standard.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

This document defines default integrity and confidentiality security
contexts that may be used with implementations of the Bundle Protocol
Security Protocol (BPSec).  These security contexts may be used for
both testing the interoperability of BPSec implementations and for
providing basic security operations when no other security contexts
are defined or otherwise required for a network.

The Bundle Protocol Security Protocol (BPSec) [I-D.ietf-dtn-bpsec]
specification defines bundle integrity and confidentiality
operations for networks deploying the Bundle Protocol (BP)
[I-D.ietf-dtn-bpbis]. BPSec defines BP extension blocks to carry
security information produced under the auspices of one or more
security contexts.

This document defines two security contexts (one for an integrity
service and one for a confidentiality service) for populating BPSec
Block Integrity Blocks (BIBs) and Block Confidentiality Blocks
(BCBs).

Working Group Summary:

The present document is the product of over a year of active disussion on
the DTN WG mailing list, beginning with questions raised by Area Directors
during the initial IESG review of the BPSec specification in early 2020.
In particular, it was noted that a published default security context
would be required for interoperation among BPSec implementations, both
for conformance testing and also for operational use under some circumstances.
Constraints on this interoperability security context emerged from productive
email exhanges over recent months, and at this point no aspects of the
specification are controversial.  The present document is cited as a normative
reference in the BPSec specification. 

Document Quality:

No implementations of the default BPSec security context are known to exist
yet; an implementation for the Interplanetary Overlay Network (ION) product
is under development.  Significant issues were identified by Mehmet Adalier
(Antara Teknik) during Working Group Last Call and later by Ran Atkinson,
Brian Sipos, and Christian Huitema; these issues have been addressed in
draft-ietf-dtn-bpsec-default-sc-09.  It is the sense of the Working Group
that the document has no serious problems. 

Personnel:

The Document Shepherd is Scott Burleigh.

The Responsible Area Director is Zaheduzzaman Sarker.

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

The Document Shepherd reviewed this Internet Draft on 28 January 2021 and submitted detailed comments to the author at that time.  The Document Shepherd subsequently reviewed a revised edition of the draft on6 July 2021.  The draft is now ready for publication.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No, reviews of the document have been performed both by persons with good understanding of Bundle Security Protocol and by persons with good understanding of network security.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

The document was reviewed in detail by the Security Area Directorate in March-April of 2021 and comments were addressed in revised editions of the draft.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of. For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

The Document Shepherd has no specific concerns or issues with this document.  Technical questions have been discussed at length and resolved by consensus within the WG.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

The authors have stated that they do not claim any intellectual property rights regarding this document.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

No claims of intellectual property rights regarding this document have been stated.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

It is the sense of the WG Chairs and the Document Shepherd that this document represents the consensus of the WG.  Most WG members have limited expertise in the subject matter of the document, so only a small number of WG members have been active in discussions of the default BPSec security contexts. However, the WG as a whole understands the intent of the document and, broadly, the decisions that are fundamental to it, and there is no audible dissent at the WG meetings or on the mailing list.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

No discontent pertaining to the default BPSec security contexts has been evident in the WG meetings or on the mailing list.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

The idnits tool finds no errors or flaws in the document and issues no warnings.
In reference to the Internet-Drafts Checklist:
  • No new URLs, email lists, or email aliases are required.
  • Verbatim replication of the IPR Disclosure and IPR Notice is not provided.
  • The Document Shepherd has found no other ID nits.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews.

No formal review criteria are known to be applicable.

(13) Have all references within this document been identified as either normative or informative?

Yes, all references have been identified as normative.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

The Internet Drafts for Bundle Protocol Version 7 and Bundle Protocol Security Specification are referenced.  Those documents have been approved by IESG and are now in the RFC Editor’s queue.

(15) Are there downward normative references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

There are no downward normative references in the document.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

Publication of this document will not change the status of any existing RFCs.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

Allocation of two additional entries in the BPSec Security Context Identifiers Registry is noted appropriately.  Two new IANA registries are required: Integrity Scope Flags and AAD Scope Flags.  In both cases, registration policies and detailed initial contents are provided.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

The registration policies for both new IANA registries are “Specification Required”.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc.

No sections of the BPSec default security contexts specification are written in any formal language.

[Ballot discuss]
Sections 5.2 and 5.3 declare new IANA registries with Specification Required policies.  BCP 26 (RFC 8126) says of such registries that "clear guidance to the designated expert should be provided when defining the registry", but none is provided here.  While that's obviously not a MUST, I would like to have a short discussion about why no such guidance is appropriate (or get some crafted and added).

[Ballot comment]
I support Francesca's first DISCUSS point.

Since the shepherd writeup was written earlier this year, six revisions have been posted, the IESG has rotated (so the responsible AD in the writeup has changed), two authors have been added, two new registries were proposed (the writeup claims there are none), and a considerable amount of text has been added or changed.  The current writeup thus feels markedly stale; I suggest that in such situations, the shepherd should consider updating the writeup so that it appears to be more current when it gets to the IESG.

Appendix B could be simplified a bit:

  Amy Alford of the Johns Hopkins University
  Applied Physics Laboratory contributed useful review and analysis of
  these security contexts.

[Ballot comment]
Thank you to Christian Huitema for the SECDIR review.

I support the DISCUSS positions of Martin Duke, Francesca Palombini and Benjamin Kaduk whose substantive positions have already noted what would have been my feedback.

** Section 4.5.  Per “The total number of bytes processed with a single key for AES-GCM is recommended to be less than 2^64, as described in Appendix B of [AES-GCM].”  It would also be worth nothing that in additional to the number of process bytes, that there is a limit of 2^32 of invocations with the same key per Section 8.3 of [AES-GCM].

[Ballot discuss]
Thank you for writing this document; I'm really glad that it will be
available to illuminate the particulars of BPsec usage and provide a
default option when running BPsec in relatively bland environments.
However, I think there are a few gaps between the current specification
and a strong/reliable default security option.

(D1) the construction for the HMAC input plaintext and GCM AAD seems to
be "malleable" at the security context layer.  That is, in order for the
cryptographic integrity protection mechanism to provide strong
guarantees for the application protocol's semantics, the mapping from
protocol parameters (e.g., "security target contents", "primary block")
to the actual byte string used as the IPPT/AAD inputs to HMAC/GMAC needs
to be an injective mapping (in the mathematical sense).  If injectivity
does not hold, then there is more than one possible application
semantics that could be perceived as valid upon successful validation of
the authentication tag at the recipient; this "malleability" across
different interpretations of the bytes covered by a given integrity tag
gives an opening by which an attacker can target the application
semantics.

The current construction seems
"malleable" because the scope flags are not protected in any way and
could be modified by an attacker, and the scope flags affect which
application protocol fields (and thus, semantics) are used to construct
the IPPT/AAD.  If the attacker modifies the messages to move those
encoded bytes from one location to another, the modified message could
still pass cryptographic verification but be interpreted with different
semantics than intended.  We do correctly note that the security context
identifier and the security context parameters of the security block are
not included in the input data, but the conclusion that "successful
verification implies that these parameters were unchanged from what the
security source has specified" does not seem entirely warranted without
further analysis that relies on the internal structure of the different
potential parts of the IPPT/AAD.

[side note: the IETF security community tends towards "always include as
much information in the MAC as you can without breaking operations",
which would naively be everything included with scope flags 0x7.  Always
including everything removes the malleability, since there are no gaps
to move around.  But I think I can come up with scenarios where this
flexibility would indeed be needed in BP operations, so my tentative
conclusion is that the simple "always MAC everything" approach will not
work here.]

Specifically, to the extent that we may have injectivity, we seem to be
relying on the specific encoding details of the different types of
information that could be used in constructing the IPPT and AAD.  Since
the IPPT/AAD is currently just the concatenation (in a particular order)
of any/all of a few pieces of data, we can only get injectivity if each
of those pieces of data is self-framing and *self-identifying* by its
encoded form.  (If we, for example, prefixed each self-framing part with
a type identifier for what followed, that would make the overall
encoding self-identifying for what is contained therein.)  E.g., the
primary block is going to be a CBOR array with (at least?) 8 elements,
starting with 0x0808, and is self-framing by virtue of being a CBOR
object.  But the "security target other fields" are not so clearly self
framing, as it's more of a CBOR sequence with type code, block number,
and control flags as three unsigned integers; we have to know a priori
to read three CBOR unsigned integers and treat that as a single object.
Furthermore, the "BIB other fields" (or "BCB other fields") are also
three CBOR unsigned integers, and since it's possible for (e.g.) a BIB
to be the security target of a BIB, the block type code cannot
distinguish between a security target and the BIB information.  Only the
block number could, but IIRC the block number itself is malleable to an
on-path attacker.  And this analysis only covers the currently specified
scope flags; any future additions might add new ways for injectivity to
fail.  It's much better to have a strong injective construction at the
higher layer and not rely on the internal encoding details of the
component pieces.

So, I think we need to include at least the scope flags as part of the
IPPT/AAD in order to provide injectivity.  It might be worth considering
adding additional framing and typing to make clear boundaries between
the different parts of the IPPT/AAD, but my current understanding is
that it would not be strictly necessary to do so.

(D2) There seems to be some risk associated with the current HMAC
construction, since the HMAC with a given key over a given plaintext
will be the same each time it is calculated.  In other protocol
contexts, this has led to practical attacks and HMAC forgery, by using a
side-channel to gain insight into the verifier's behavior and guessing
the correct HMAC tag for a given (attacker-selected) plaintext a byte at
a time.  With only a modest number of trials (4k on average for
HMAC-SHA-256, assuming a fully reliable side channel) this would let the
attacker extract the valid HMAC tag that the verifier produced for
comparison against the attacker's guess at the HMAC tag.  Since this is
the HMAC tag over the attacker's chosen plaintext, this lets the
attacker obtain a valid HMAC tag without knowing the HMAC key.

Now, it seems clear that in the preponderance of BP deployments there
will not be an effective side channel available!  But IMO this still
reflects a fundamental cryptographic weakness in the protocol and we
should make some effort to address it.  There are a couple potential
mitigation approaches off the top of my head, which can be combined if
desired: include a nonce as part of the HMAC input (and encourage
rejection of reused nonces), and require constant-time comparison of the
supplied and expected authentication tag (to prevent using a side
channel from reading it off byte by byte).  I suspect that there may be some
operational issues with the "unique nonce per HMAC" approach that would
make it not terribly reliable in practice, but "use a constant-time
comparison" should be fairly straightforward.

(D3) While we do provide the standard guidance against using any given
key with more than one algorithm (e.g., with HMAC-SHA-256 and
AES256-GCM), there seem to be additional considerations relevant to this
protocol that merit further discussion in the security considerations.
Specifically, we make provision for an AES-KW wrapped key to be included
along with the security payload and mandate that if present, such a key
be used.  Given that the parameter holding the wrapped key does not seem
to be bound to a given message, it seems fairly straightforward for an
in-network attacker to "slice and dice" the ciphertext and wrapped key
away from each other, and cause any wrapped key it has seen to be
attempted to be used with a given algorithm+ciphertext.  This, in turn,
would provide attacker-induced key reuse across algorithms, which is
something that we want to avoid.  While providing full protection
against key reuse with different algorithms would prove fairly
challenging and probably require significant state on the
verifier/security destination, we should at least have some discussion
of the situation, and could provide some modest mitigation techniques
such as using distinct KEKs for receiving wrapped keys that have different
intended usage.  That is, one KEK for receiving AES keys, another for
HMAC keys, etc..  Attaching context (intended algorithm, etc.) to the
KEK allows such context to be indirectly attached to the received
wrapped keys, which otherwise would come without much context for
intended usage.

[Ballot comment]
Thanks to Christian Huitema for the multiple secdir reviews, and special
thanks to the authors for adding examples/test vectors as he
recommended, as well as the other updates.

Section 3.1

  BIB-HMAC-SHA2 supports three variants of HMAC-SHA, based on the
  supported length of the SHA-2 hash value.  These variants correspond
  to "HMAC 256/256", "HMAC 384/384", and "HMAC 512/512" as defined in
  [RFC8152] Table 7: HMAC Algorithm Values.  [...]

This is unfortunate timing, I suppose, but RFC 8152 is going to be
replaced imminently by draft-ietf-cose-rfc8152bis-algs and
draft-ietf-cose-rfc8152bis-struct, which are virtually certain to be
published as RFCs before this document.

Section 3.2

      NOTE: The security context identifier and security context
      parameters of the security block are not included in the IPPT
      because these parameters, by definition, are required to verify
      or accept the security service.  Successful verification at
      security verifiers and security acceptors implies that these
      parameters were unchanged since being specified at the security
      source.

(related to D1, but distinct...)
This seems to be only mostly true ... if some other security context was
created that also used HMAC-SHA2 it seems like the same output might be
obtained or validated across security contexts ... but this would only
cause problems if there were different semantics afforded to the
different security contexts in some way.  Any attack would also be
stymied if the honest participants were rigorous in separation of keys,
with any given key being used with only one security context.

Section 3.3.3

  Integrity scope flags that are unrecognized MUST be ignored, as
  future definitions of additional flags might not be integrated
  simultaneously into security context implementations operating at all
  nodes.

It's not entirely clear how useful a mandate to ignore unrecognized
flags will be, if the flags would change the plaintext input and thus
the value of the HMAC output.  I guess maybe the intent is just that
intermediate notes processing a bundle but not acting as security
acceptor should pass through such flags unchanged?

Section 3.3.4

                    BIB-HMAC-SHA2 Security Parameters

    +----+-----------------------+--------------------+---------------+
    | Id |          Name        | CBOR Encoding Type | Default Value |
    +----+-----------------------+--------------------+---------------+
    | 1  |      SHA Variant      |        UINT        |      6      |
    | 2  |      Wrapped Key      |    Byte String    |      NONE    |
    | 4  | Integrity Scope Flags |        UINT        |      0x7      |
    +----+-----------------------+--------------------+---------------+

The examples use a parameter Id of '3' for the Integrity Scope Flags,
not the '4' shown here.  Since the parameter Ids are just CBOR integers,
the sequential assignment with '3' would seem to make the most sense.

Section 3.7.1

      Any local flags used to generate the IPPT SHOULD be placed in the
      integrity scope flags security parameter for the BIB unless these
      flags are expected to be correctly configured at security
      verifiers and acceptors in the network.

Just to confirm: do we want "SHOULD ... unless" or "MUST ... unless"?

Section 4.2

      NOTE: The security context identifier and security context
      parameters of the security block are not included as additional
      authenticated data because these parameters, by definition, are
      those needed to verify or accept the security service.
      Therefore, it is expected that changes to these values would
      result in failures at security verifiers and security acceptors.

As for the BIB, this note seems only mostly true.

Section 4.3.2

  When not provided, implementations SHOULD assume a value of 3
  (indicating use of A256GCM), unless an alternate default is

[same comment about "SHOULD ... unless" as above]

Section 4.5

  The security provided by block ciphers is reduced as more data is
  processed with the same key.  The total number of bytes processed
  with a single key for AES-GCM is recommended to be less than 2^64, as
  described in Appendix B of [AES-GCM].

The treatment in Appendix B seems to be specific to the authentication
functionality (and seems to refer to number of *blocks*, not number of
*bytes*); section 8.3 of that document has additional guidance on
overall invocations of the authenticated encryption function, that
include smaller limits that apply to the number of invocations of the
function.

Section 4.6

      The pairing of an IV and a security key MUST be unique.  An IV
      MUST NOT be used with a security key more than one time.  If an IV

I believe that the use with the *encryption* function is the risky one.
This is good, because if IV reuse with decryption was problematic, our
use of AES-KW would induce pretty strong requirements for state-keeping
on verifiers/recipients in order to meet this requirement that could be
operationally challenging!

      As discussed in Appendix B of [AES-GCM], implementations SHOULD
      limit the number of unsuccessful verification attempts for each
      key to reduce the likelihood of guessing tag values.

This type of check would also have potential issues with state-keeping
when AES-KW is used, since an attacker could cause a large number of
keys to have been used at least once.

Section 4.8.2

      The authentication tag MUST be present in the BCB security context
      parameters field if additional authenticated data are defined for
      the BCB (either in the AAD scope flags parameter or as specified
      by local policy).  This tag MUST be 128 bits in length.

I think the authentication tag always needs to be present, not "just"
when there is AAD used.

Section 7

I see that RFC 5649 (or really, RFC 3537) is also available as a
reference for an AES-KW algorithm, and that the NIST reference indicates
that the RFCs are "essentially equivalent" to what is specified in the
NIST reference.  My understanding is that we have a mild preference for
IETF references over external references when a choice is available.

Likewise, RFC 2104 is available as an HMAC reference.

Section A.1.4

Is the final "full output bundle" supposed to include the payload block
after the BIB block?  I do not see it...

NITS

Section 3.1

  The BIB-HMAC-SHA2 security context provides a keyed hash over a set
  of plain text information.  This context uses the Secure Hash
  Algorithm 2 (SHA-2) discussed in [SHS] combined with the HMAC keyed
  hash discussed in [HMAC]. 

I think s/keyed hash/keyed-hash Message Authentication Code (MAC)/.

Section 3.3.3

  Bits in this field represent additional information to be included
  when generating an integrity signature over the security target.

My preference is to avoid using the word "signature" to describe a MAC,
but I recognize that there is some precedent for using "signature" in
this manner.  (I won't mention it again for this document.)

Section 3.5

  HMAC keys used with this context MUST be symmetric and MUST have a
  key length equal to the output of the HMAC.  For this reason, HMAC
  keys will be integer divisible by 8 bytes and special padding-aware
  AES key wrap algorithms are not needed.

s/HMAC Keys will be/HMAC key lengths will be/

Section 4.2

  Keys used with this context MUST be symmetric and MUST have a key
  length equal to the key length defined in the security context
  parameters or as defined by local security policy at security
  verifiers and acceptors.  For this reason, content-encrypting keys
  will be integer divisible by 8 bytes and special padding-aware AES
  key wrap algorithms are not needed.

Similarly, s/content-encrypting keys will be/content-encrypting key
lengths will be/.

Section 4.7.1

  The plain text used during encryption MUST be calculated as the
  single, definite-length CBOR byte string representing the block-type-
  specific data field of the security target excluding the CBOR byte
  string identifying byte and optional CBOR byte string length field.

I don't think I see why the CBOR byte string length field is "optional"
in this scenario.  (Likewise for decryption.)

  |            18ED            |    18  |            ED            |
  +------------------------------+---------+--------------------------+
  | C24CDEADBEEFDEADBEEFDEADBEEF |  C24C  | DEADBEEFDEADBEEFDEADBEEF |

I'm having trouble decoding the "CBOR part"s here; in particular, I
expected to see the major type 2 and CBOR "argument" with the length of
the byte string, which '4C' seems to match up with for the second
example, but not be present for the first example.  Are '18' and 'C2'
supposed to be CBOR tags?

Section 4.8.1

      The key length used by this security context MUST be considered
      when setting the AES variant security parameter for the BCB if it
      differs from the default AES variant.  Otherwise, the AES variant

The "MUST be considered" language feels odd to me (what does
"considered" mean?); the "SHOULD be added as the [parameter] if it
differs from the default" languaged used for the SHA2 output length
feels more natural to me.

Section 4.8.2

  During encryption, five inputs are prepared for input to the AES/GCM
  cipher: the decryption key, the IV, the security target cipher text

s/encryption/decryption/

Section 6.2

      In the event that a key is compromised, any security operations
      using a security context associated with that key SHOULD also be
      considered compromised.  This means that the BIB-HMAC-SHA2
      security context SHOULD NOT provide integrity when used with a
      compromised key and BCB-AES-GCM SHOULD NOT provide confidentiality
      when used with a compromised key.

I'm a little confused by the phrasing "SHOULD NOT provide
[confidentiality/integrity]", since the reality is more along the lines
of that they will not do so, factually speaking.  Perhaps the intent is
that the "SHOUL NOT be treated as providing" the indicated properties?

Section 6.4

  The AES key wrap (AES-KW) algorithm used by the security contexts in
  this document does not use an initialization vector and does not
  require any key padding.  [...]

Very pedantically, I think that AES-KW does not use a per-invocation IV
(there is a single globally constant IV used as input to the AES cipher
operation).

Section A.1.4

I suggest using lowercase hex digits consistently.

Section A.3.1.2

What do the chevrons around "300" indicate?

Section A.3.5, A.4.5

I suggest consistently using lowercase hex digits here as well.  (It
shows up when I try to diff a manually assembled bundle against the
encoded output shown here.)

[Ballot discuss]
Thank you for the work on this document.

I'd like to discuss the following point. I also have some non blocking comments, which I hope will help improve the document.

Francesca

1. -----

FP: I agree with my colleagues that extensibility should be considered for algorithms. This document defines BIB-HMAC-SHA2 and BCB-AES-GCM, with the algorithms these security contexts provide. Adding support for one algorithm would need to define a new security context. Wouldn't it make sense to, instead, provide a way to add algorithms to the existing algorithms? For example, defining an IANA registry for each security context with the IDs of algorithms supported (taken from COSE).

2. -----

      - Bit 2 (0x0003): Security Header Flag.

FP: This should be (0x0004) and not (0x0003) (and same in a later section). Also, this is not wrong, but the bitmaps (here and everywhere else) could also be represented as 0b0100 in CBOR diagnostic notation, which to me is clearer.

3. -----

      - Bits 8-15 are unassigned.

FP: I am wondering why the limit on Bit 15, marked as unassigned: I think it would make sense to say Bits 8 and higher are unassigned. (This change would need to be reflected in the IANA sections)

4. -----

FP: this might be me missing some fundamental reading from bpsec, but I see that the blocks are defined as CBOR sequences. However, that is only mentioned in the appendix (meant to be informative):

  represented using CBOR structures.  In cases where BP blocks (to
  include BPSec security blocks) are comprised of a sequence of CBOR
  objects, these objects are represented as a CBOR sequence as defined
  in [RFC8742].

Is this defined somewhere else? If yes, could you add a pointer to the doc where it is defined? If not, this should be clarified, and specified earlier in the text, say in sections 3 and 4.

5. -----

    [1, b'Twelve121212'] / Initialization Vector /,

FP: I think the IV value is wrong here and should be h'5477656c7665313231323132'.

[Ballot comment]
6. -----

FP: I believe the reference to RFC 8152 should be replaced with references to draft-ietf-cose-rfc8152bis-algs.


7. -----

  BIB-HMAC-SHA2 defines the following security context parameters.

                    BIB-HMAC-SHA2 Security Parameters

    +----+-----------------------+--------------------+---------------+
    | Id |          Name        | CBOR Encoding Type | Default Value |


FP: Id should be defined, and a reference to the correct section of bpsec where Ids are defined should be provided.

8. -----

    +----+-----------------------+--------------------+---------------+
    | 1  |      SHA Variant      |        UINT        |      6      |

FP: the correct terminology for CBOR types is not UINT but unsigned integer.

9. -----

    | 2  |      Wrapped Key      |    Byte String    |      NONE    |

FP: Please explicitly write that NONE means that the key does not have a default value.

10. -----

    | 4  | Integrity Scope Flags |        UINT        |      0x7      |
    +----+-----------------------+--------------------+---------------+

FP: This representation seems to be conflicting with the one for SHA Variant, and although not wrong, usually 0x notation is given for byte strings, so this might be confusing. I suggest to change the default value to 7, rather than 0x7.

11. -----

FP: I think this draft could make good use of a terminology section, where terms such as security results, identifier, bundle, CRC, canonical form, set, block type, block number, etc can point to the correct document defining them.


12. -----

      on this security target, as discussed in Section 3.4).

FP: nit - one closed parenthesis too much.

13. -----

      The HMAC key MAY be wrapped using the NIST AES-KW algorithm and
      the results of the wrapping added as the wrapped key security
      parameter for the BIB.

FP: I think this MAY is misleading: written like this, it seems as if the HMAC key can also be sent unwrapped (while I understand the reason to add this MAY was because the key might be retrieved in other ways than being sent).

14. -----

  security block.  This information includes the data included in the
  confidentiality service and MAY include other information (additional
  authenticated data), as follows.

FP: nit - This sentence is hard to parse, could it be rephrased to remove the "include" duplication?

15. -----

      The authentication tag calculated by the AES/GCM cipher MUST be
      added as a security result for the security target in the BCB
      holding results for this security operation.

and later on...

      The authentication tag MUST be present in the BCB security context
      parameters field if additional authenticated data are defined for
      the BCB (either in the AAD scope flags parameter or as specified
      by local policy).  This tag MUST be 128 bits in length.

FP: I agree with Martin that the text is confusing about the presence of the tag in the security result. Adding an "unless ..." would help.

16. -----

  The plain text used during encryption MUST be calculated as the
  single, definite-length CBOR byte string representing the block-type-
  specific data field of the security target excluding the CBOR byte
  string identifying byte and optional CBOR byte string length field.

FP: I think here you mean to say that:

  The plain text used during encryption is the
  block-type-specific data field value of the security target.

Is that right? I got a bit confused by the formulation, but please correct me if this is anything else than just the value extracted from the CBOR encoding.

17. -----

      The IV selected MUST be of the appropriate length.  Because
      replaying an IV in counter mode voids the confidentiality of all
      messages encrypted with said IV, this context also requires a
      unique IV for every encryption performed with the same key.  This
      means the same key and IV combination MUST NOT be used more than
      once.

FP: This makes me uncomfortable, as I would like to see more indications on how the IV uniqueness is achieved. Also, there should be mention of the failure to provide IV uniqueness in the security considerations. However, I won't add this to my discuss because I am sure the Sec ADs will have more detailed comments.

18. -----

  This section presents a series of examples of constructing BPSec
  security blocks (using the security contexts defined in this
  document) and adding those blocks to a sample bundle.

FP: Thank you for this appendix. It would be good to point to the code used to build these examples, if that is openly available.

19. -----

                          Block                    Block  Block
                        in Bundle                  Type    Number
        +========================================+=======+========+
        |  Primary Block                        |  N/A  |    0  |
        +----------------------------------------+-------+--------+
        |  Payload Block                        |  0  |    1  |
        +----------------------------------------+-------+--------+

                    Figure 1: Example 1 Original Bundle

FP: It would be useful to explain (or point to the document explaining) this representation.


20. -----

A.1.4.  Final Bundle

FP: I think it would be useful to include the CBOR diagnostic notation for the final bundle as well (several occurrences).

21. -----

FP: I guess this is more of a comment on bpsec than on this document, but I was disappointed that no CDDL was defined for the CBOR encoding.

[Ballot comment]
Thank you for the work put into this document.

Special thanks for the doc shepherd write-up about the WG process / consensus. Please note that I did not review the CBOR-encoded examples.

Please find below some non-blocking COMMENT points (but replies would be appreciated).

I hope that this helps to improve the document,

Regards,

-éric

Is the document limited to SHA-2 and AES-GCM ? How can it be extended to other crypto algorithms ?

-- Section 3.3.1 --
Why is the CBOR encoding specified here ? The text says nothing about serialization or message format, so, I do not understand why CBOR encoding is required.

-- Sections 3.3.3 and 4.3.4 ---
Same comment as above but if there is transmission, what is the difference between the reserved and the unassigned bits ? How should they be transmitted ? How should they be processed by any receiver ?

-- Sections 3.3.4 and 4.3.5 --
Why putting the "0x" prefix in  "0x7" but not for "6" in table 2 ?

[Ballot discuss]
There are several references to the possibility that the AES-GCM API doesn't allow for separation of the tag from the cipher text. I have not heard of products with this API but will accept that they exist. But I'm confused as to the handling of this case:

(4.4.1) says the tag MUST be CBOR encoded and (4.8.1) says the tag MUST be reported in the security result; but how is this possible if the tag is not extractable from the ciphertext?

Moreover, shouldn't there be a parameter or a scope flag somewhere that tells the receiver if the tag is in the cipher text? It would be hard to discern the sender's API a priori!

[Ballot comment]
(4.5) Does "the total number of bytes processed" by AES-GCM include just plaintext, or also the associated data?

(6.5) If a security block is cryptographically bound to a bundle, it
      cannot be processed even if the security block and target both
      coexist in the fragment.  This is because fragments have different
      primary blocks than the original bundle.

This should point out that it only applies if the primary block is part of the AAD.

(A.4.4.1) It looks like the BIB data is simply a copy of the payload data, and therefore incorrect. I didn't check to see if this leads to incorrect values for the products of these inputs.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-dtn-bpsec-default-sc-07. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator has a question about one of the actions requested in the IANA Considerations section of this document.

The IANA Functions Operator understands that, upon approval of this document, there are three actions which we must complete.

First, in the BPSec Security Context Identifier registry on the Bundle Protocol registry page located at:

https://www.iana.org/assignments/bundle/

two new registrations are to be made as follows:

Value: [ TBD-at-Registration ]
Description: BIB-HMAC-SHA2
Reference: [ RFC-to-be ]

Value: [ TBD-at-Registration ]
Description: BCB-AES-GCM
Reference: [ RFC-to-be ]

As this document requests registrations in a Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request.  This review must be completed before the document's IANA state can be changed to "IANA OK."

Second, a new registry is to be created called the BPSec BIB-HMAC-SHA2 Integrity Scope Flags Registry.

IANA Question --> Where should this new registry be located? Should it be added to an existing registry page? If it needs a new page, does it also need a new category at http://www.iana.org/protocols (and if so, should the page and the category have the same name)?

The registration procedure is Specification Required as defined in RFC 8126.

There are initial registrations in the new registry as follows:

+-------------------------+--------------------------+--------------+
| Bit Position (right to | Description | Reference |
| left) | | |
+-------------------------+--------------------------+--------------+
| 0 | Include primary block |[ RFC-to-be ] |
| 1 | Include target header |[ RFC-to-be ] |
| | flag | |
| 2 | Include security header |[ RFC-to-be ] |
| | flag | |
| 3-7 | reserved |[ RFC-to-be ] |
| 8-15 | unassigned | |
+-------------------------+--------------------------+--------------+

Third, a new registry is to be created called the BPSec BCB-AES-GCM AAD Scope Flags Registry.

IANA Question --> Where should this new registry be located? Should it be added to an existing registry page? If it needs a new page, does it also need a new category at http://www.iana.org/protocols (and if so, should the page and the category have the same name)?

The registration procedure is Specification Required as defined in RFC 8126.

There are initial registrations in the new registry as follows:

+-------------------------+--------------------------+--------------+
| Bit Position (right to | Description | Reference |
| left) | | |
+-------------------------+--------------------------+--------------+
| 0 | Include primary block |[ RFC-to-be ] |
| 1 | Include target header |[ RFC-to-be ] |
| | flag | |
| 2 | Include security header |[ RFC-to-be ] |
| | flag | |
| 3-7 | reserved |[ RFC-to-be ] |
| 8-15 | unassigned | |
+-------------------------+--------------------------+--------------+

As this document is creating new registries with Specification Required as the registration procedure, please send suggestions for Experts to the Area Directors.

The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2021-06-01):

From: The IESG
To: IETF-Announce
CC: Scott.C.Burleigh@jpl.nasa.gov, Zaheduzzaman.Sarker@ericsson.com, draft-ietf-dtn-bpsec-default-sc@ietf.org, dtn-chairs@ietf.org, dtn@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (BPSec Default Security Contexts) to Proposed Standard


The IESG has received a request from the Delay/Disruption Tolerant Networking
WG (dtn) to consider the following document: - 'BPSec Default Security
Contexts'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2021-06-01. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document defines default integrity and confidentiality security
  contexts that can be used with the Bundle Protocol Security Protocol
  (BPSec) implementations.  These security contexts are intended to be
  used for both testing the interoperability of BPSec implementations
  and for providing basic security operations when no other security
  contexts are defined or otherwise required for a network.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-dtn-bpsec-default-sc/



No IPR declarations have been submitted directly on this I-D.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 23 February 2021

(1) What type of RFC is being requested (BCP, Proposed Standard,
    Internet Standard, Informational, Experimental, or Historic)? Why is this
    the proper type of RFC? Is this type of RFC indicated in the title page
    header?

A Proposed Standard is being requested.  The title page header indicates that
the intended status is Standards Track, and the specification documented in
the current Internet Draft is not yet mature enough to qualify as an Internet
Standard.

(2) The IESG approval announcement includes a Document Announcement Write-Up.
Please provide such a Document Announcement Write-Up. Recent examples can be
found in the "Action" announcements for approved documents. The approval
announcement contains the following sections:


Technical Summary

This document defines default integrity and confidentiality security
contexts that may be used with implementations of the Bundle Protocol
Security Protocol (BPSec).  These security contexts may be used for
both testing the interoperability of BPSec implementations and for
providing basic security operations when no other security contexts
are defined or otherwise required for a network.

The Bundle Protocol Security Protocol (BPSec) [I-D.ietf-dtn-bpsec]
specification defines bundle integrity and confidentiality
operations for networks deploying the Bundle Protocol (BP)
[I-D.ietf-dtn-bpbis]. BPSec defines BP extension blocks to carry
security information produced under the auspices of one or more
security contexts.

This document defines two security contexts (one for an integrity
service and one for a confidentiality service) for populating BPSec
Block Integrity Blocks (BIBs) and Block Confidentiality Blocks
(BCBs).


Working Group Summary

The present document is the product of one year of active disussion on
the DTN WG mailing list, beginning with questions raised by Area Directors
during the initial IESG review of the BPSec specification in early 2020.
In particular, it was noted that a published default security context
would be required for interoperation among BPSec implementations, both
for conformance testing and also for operational use under some circumstances.
Constraints on this interoperability security context emerged from productive
email exhanges over recent months, and at this point no aspects of the
specification are controversial.  The present document is cited as a normative
reference in the BPSec specification. 


Document Quality

No implementations of the default BPSec security context are known to exist
yet.  Significant issues were identified by Mehmet Adalier (Antara Teknik)
during Working Group Last Call; these issues were addressed in
draft-ietf-dtn-bpsec-default-sc-01.  It is the sense of the Working Group
that the document has no serious problems. 


Personnel

The Document Shepherd is Scott Burleigh.
The Responsible Area Director is Magnus Westerlund.


(3) Briefly describe the review of this document that was performed by the
Document Shepherd. If this version of the document is not ready for publication,
please explain why the document is being forwarded to the IESG.

The Document Shepherd reviewed this Internet Draft on 28 January 2021 and
submitted detailed comments to the author at that time.  The draft is now ready
for publication.


(4) Does the document Shepherd have any concerns about the depth or breadth of
the reviews that have been performed?

No, reviews of the document have been performed both by persons with good
understanding of Bundle Security Protocol and by persons with good understanding
of network security.


(5) Do portions of the document need review from a particular or from broader
perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or
internationalization? If so, describe the review that took place.

The document would benefit from additional review from the Security area.


(6) Describe any specific concerns or issues that the Document Shepherd has
with this document that the Responsible Area Director and/or the IESG should be
aware of. For example, perhaps he or she is uncomfortable with certain parts of
the document, or has concerns whether there really is a need for it. In any
event, if the WG has discussed those issues and has indicated that it still
wishes to advance the document, detail those concerns here.

The Document Shepherd has no specific concerns or issues with this document. 
Technical questions have been discussed at length and resolved by consensus
within the WG.


(7) Has each author confirmed that any and all appropriate IPR disclosures
required for full conformance with the provisions of BCP 78 and BCP 79 have
already been filed. If not, explain why?

The author has stated that he does not claim any intellectual property rights
regarding this document.


(8) Has an IPR disclosure been filed that references this document? If so,
summarize any WG discussion and conclusion regarding the IPR disclosures.

No claims of intellectual property rights regarding this document have been
stated.


(9) How solid is the WG consensus behind this document? Does it represent the
strong concurrence of a few individuals, with others being silent, or does the
WG as a whole understand and agree with it?

It is the sense of the WG Chairs and the Document Shepherd that this document
represents the consensus of the WG.  Most WG members have limited expertise in
the subject matter of the document, so only a small number of WG members have
been active in discussions of the default BPSec security contexts. However,
the WG as a whole understands the intent of the document and, broadly, the
decisions that are fundamental to it, and there is no audible dissent at the
WG meetings or on the mailing list.


(10) Has anyone threatened an appeal or otherwise indicated extreme discontent?
If so, please summarise the areas of conflict in separate email messages to the
Responsible Area Director. (It should be in a separate email because this
questionnaire is publicly available.)

No discontent pertaining to the default BPSec security contexts has been evident
in the WG meetings or on the mailing list.


(11) Identify any ID nits the Document Shepherd has found in this document.
(See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist).
Boilerplate checks are not enough; this check needs to be thorough.

The idnits tool finds no errors or flaws in the document and issues no warnings.
In reference to the Internet-Drafts Checklist:
• No new URLs, email lists, or email aliases are required.
• The Document Shepherd has found no other ID nits.


(12) Describe how the document meets any required formal review criteria, such
as the MIB Doctor, media type, and URI type reviews.

No formal review criteria are known to be applicable.


(13) Have all references within this document been identified as either
normative or informative?

Yes, all references have been identified as normative.


(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative references
exist, what is the plan for their completion?

The Internet Drafts for Bundle Protocol Version 7 and Bundle Protocol Security
Specification are referenced.  Those documents have been approved by IESG and
are now in the RFC Editor’s queue.


(15) Are there downward normative references (see RFC 3967)? If so, list these
downward references to support the Area Director in the Last Call procedure.

There are no downward normative references in the document.


(16) Will publication of this document change the status of any existing RFCs?
Are those RFCs listed on the title page header, listed in the abstract, and
discussed in the introduction? If the RFCs are not listed in the Abstract and
Introduction, explain why, and point to the part of the document where the
relationship of this document to the other RFCs is discussed. If this
information is not in the document, explain why the WG considers it unnecessary.

Publication of this document will not change the status of any existing RFCs.


(17) Describe the Document Shepherd's review of the IANA considerations section,
especially with regard to its consistency with the body of the document. Confirm
that all protocol extensions that the document makes are associated with the
appropriate reservations in IANA registries. Confirm that any referenced IANA
registries have been clearly identified. Confirm that newly created IANA
registries include a detailed specification of the initial contents for the
registry, that allocations procedures for future registrations are defined, and
a reasonable name for the new registry has been suggested (see RFC 8126).

No new IANA registries are required.  Allocation of two additional entries in
the BPSec Security Context Identifiers Registry is noted appropriately.


(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find useful in
selecting the IANA Experts for these new registries.

No new IANA registries are required.


(19) Describe reviews and automated checks performed by the Document Shepherd
to validate sections of the document written in a formal language, such as XML
code, BNF rules, MIB definitions, etc.

No sections of the BPSec default security contexts specification are written
in any formal language.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 23 February 2021

(1) What type of RFC is being requested (BCP, Proposed Standard,
    Internet Standard, Informational, Experimental, or Historic)? Why is this
    the proper type of RFC? Is this type of RFC indicated in the title page
    header?

A Proposed Standard is being requested.  The title page header indicates that
the intended status is Standards Track, and the specification documented in
the current Internet Draft is not yet mature enough to qualify as an Internet
Standard.

(2) The IESG approval announcement includes a Document Announcement Write-Up.
Please provide such a Document Announcement Write-Up. Recent examples can be
found in the "Action" announcements for approved documents. The approval
announcement contains the following sections:


Technical Summary

This document defines default integrity and confidentiality security
contexts that may be used with implementations of the Bundle Protocol
Security Protocol (BPSec).  These security contexts may be used for
both testing the interoperability of BPSec implementations and for
providing basic security operations when no other security contexts
are defined or otherwise required for a network.

The Bundle Protocol Security Protocol (BPSec) [I-D.ietf-dtn-bpsec]
specification defines bundle integrity and confidentiality
operations for networks deploying the Bundle Protocol (BP)
[I-D.ietf-dtn-bpbis]. BPSec defines BP extension blocks to carry
security information produced under the auspices of one or more
security contexts.

This document defines two security contexts (one for an integrity
service and one for a confidentiality service) for populating BPSec
Block Integrity Blocks (BIBs) and Block Confidentiality Blocks
(BCBs).


Working Group Summary

The present document is the product of one year of active disussion on
the DTN WG mailing list, beginning with questions raised by Area Directors
during the initial IESG review of the BPSec specification in early 2020.
In particular, it was noted that a published default security context
would be required for interoperation among BPSec implementations, both
for conformance testing and also for operational use under some circumstances.
Constraints on this interoperability security context emerged from productive
email exhanges over recent months, and at this point no aspects of the
specification are controversial.  The present document is cited as a normative
reference in the BPSec specification. 


Document Quality

No implementations of the default BPSec security context are known to exist
yet.  Significant issues were identified by Mehmet Adalier (Antara Teknik)
during Working Group Last Call; these issues were addressed in
draft-ietf-dtn-bpsec-default-sc-01.  It is the sense of the Working Group
that the document has no serious problems. 


Personnel

The Document Shepherd is Scott Burleigh.
The Responsible Area Director is Magnus Westerlund.


(3) Briefly describe the review of this document that was performed by the
Document Shepherd. If this version of the document is not ready for publication,
please explain why the document is being forwarded to the IESG.

The Document Shepherd reviewed this Internet Draft on 28 January 2021 and
submitted detailed comments to the author at that time.  The draft is now ready
for publication.


(4) Does the document Shepherd have any concerns about the depth or breadth of
the reviews that have been performed?

No, reviews of the document have been performed both by persons with good
understanding of Bundle Security Protocol and by persons with good understanding
of network security.


(5) Do portions of the document need review from a particular or from broader
perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or
internationalization? If so, describe the review that took place.

The document would benefit from additional review from the Security area.


(6) Describe any specific concerns or issues that the Document Shepherd has
with this document that the Responsible Area Director and/or the IESG should be
aware of. For example, perhaps he or she is uncomfortable with certain parts of
the document, or has concerns whether there really is a need for it. In any
event, if the WG has discussed those issues and has indicated that it still
wishes to advance the document, detail those concerns here.

The Document Shepherd has no specific concerns or issues with this document. 
Technical questions have been discussed at length and resolved by consensus
within the WG.


(7) Has each author confirmed that any and all appropriate IPR disclosures
required for full conformance with the provisions of BCP 78 and BCP 79 have
already been filed. If not, explain why?

The author has stated that he does not claim any intellectual property rights
regarding this document.


(8) Has an IPR disclosure been filed that references this document? If so,
summarize any WG discussion and conclusion regarding the IPR disclosures.

No claims of intellectual property rights regarding this document have been
stated.


(9) How solid is the WG consensus behind this document? Does it represent the
strong concurrence of a few individuals, with others being silent, or does the
WG as a whole understand and agree with it?

It is the sense of the WG Chairs and the Document Shepherd that this document
represents the consensus of the WG.  Most WG members have limited expertise in
the subject matter of the document, so only a small number of WG members have
been active in discussions of the default BPSec security contexts. However,
the WG as a whole understands the intent of the document and, broadly, the
decisions that are fundamental to it, and there is no audible dissent at the
WG meetings or on the mailing list.


(10) Has anyone threatened an appeal or otherwise indicated extreme discontent?
If so, please summarise the areas of conflict in separate email messages to the
Responsible Area Director. (It should be in a separate email because this
questionnaire is publicly available.)

No discontent pertaining to the default BPSec security contexts has been evident
in the WG meetings or on the mailing list.


(11) Identify any ID nits the Document Shepherd has found in this document.
(See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist).
Boilerplate checks are not enough; this check needs to be thorough.

The idnits tool finds no errors or flaws in the document and issues no warnings.
In reference to the Internet-Drafts Checklist:
• No new URLs, email lists, or email aliases are required.
• The Document Shepherd has found no other ID nits.


(12) Describe how the document meets any required formal review criteria, such
as the MIB Doctor, media type, and URI type reviews.

No formal review criteria are known to be applicable.


(13) Have all references within this document been identified as either
normative or informative?

Yes, all references have been identified as normative.


(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative references
exist, what is the plan for their completion?

The Internet Drafts for Bundle Protocol Version 7 and Bundle Protocol Security
Specification are referenced.  Those documents have been approved by IESG and
are now in the RFC Editor’s queue.


(15) Are there downward normative references (see RFC 3967)? If so, list these
downward references to support the Area Director in the Last Call procedure.

There are no downward normative references in the document.


(16) Will publication of this document change the status of any existing RFCs?
Are those RFCs listed on the title page header, listed in the abstract, and
discussed in the introduction? If the RFCs are not listed in the Abstract and
Introduction, explain why, and point to the part of the document where the
relationship of this document to the other RFCs is discussed. If this
information is not in the document, explain why the WG considers it unnecessary.

Publication of this document will not change the status of any existing RFCs.


(17) Describe the Document Shepherd's review of the IANA considerations section,
especially with regard to its consistency with the body of the document. Confirm
that all protocol extensions that the document makes are associated with the
appropriate reservations in IANA registries. Confirm that any referenced IANA
registries have been clearly identified. Confirm that newly created IANA
registries include a detailed specification of the initial contents for the
registry, that allocations procedures for future registrations are defined, and
a reasonable name for the new registry has been suggested (see RFC 8126).

No new IANA registries are required.  Allocation of two additional entries in
the BPSec Security Context Identifiers Registry is noted appropriately.


(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find useful in
selecting the IANA Experts for these new registries.

No new IANA registries are required.


(19) Describe reviews and automated checks performed by the Document Shepherd
to validate sections of the document written in a formal language, such as XML
code, BNF rules, MIB definitions, etc.

No sections of the BPSec default security contexts specification are written
in any formal language.