Re: [dtn-security] Issue implementing security source/destination with ESB blocks

[[e-mail]]

We've hashed out some of the wording, and below is what we'd like to
propose for the BSP errata list. Any comments are welcome.

Thanks,
Angela




Section 3.4.1,pg.32 says:

   The first algorithm that can be used permits no changes at all to the
   bundle between the security-source and the security-destination.  It
   is mainly intended for use in BAB ciphersuites.  This algorithm
   conceptually catenates all blocks in the order presented, but omits
   all security-result data fields in blocks of this ciphersuite type.
   That is, when a BAB ciphersuite specifies this algorithm, we omit all
   BAB security-results for all BAB ciphersuites.  When a PIB
   ciphersuite specifies this algorithm, we omit all PIB security-
   results for all PIB ciphersuites.  All security-result length fields
   are included, even though their corresponding security-result data
   fields are omitted.

It should say:

   The first algorithm that can be used permits no changes at all to the
   bundle between the security-source and the security-destination, with
   the exception of one of the Block Processing Control Flags, as
   described  below.  It is mainly intended for use in BAB ciphersuites.
   This algorithm conceptually catenates all blocks in the order presented,
   but omits all security-result data fields in blocks of this ciphersuite
   type.  That is, when a BAB ciphersuite specifies this algorithm, we omit
   all BAB security-results for all BAB ciphersuites.  When a PIB
   ciphersuite specifies this algorithm, we omit all PIB security-
   results for all PIB ciphersuites.  All security-result length fields
   are included, even though their corresponding security-result data
   fields are omitted.

   Notes:

   o  In the Block Processing Control Flags field, in every block other
      than the Primary Block, the flag at bit 5, "Block was forwarded
      without being processed" is canonicalized as zero.  The Block
Processing
      Control Flags field, which is an SDNV, is unpacked into a fixed-width
      field, and some bits are masked out. The unpacked field is ANDed with
      mask 0xFFFF FFFF FFFF FFDF to set to zero the "Block was forwarded
      without being processed" bit for the purposes of canonicalization.

Notes: If this flag is not zeroed out, when a bundle passes through a
non-security aware node, this flag will be set. This will then change the
message digest, and a BAB block will fail to verify.



Section 3.4.2,pg.35 says:

   For non-primary blocks being included in the canonicalization, the
   block processing control flags value used for canonicalization is the
   unpacked SDNV value with reserved and mutable bits masked to zero.
   The unpacked value is ANDed with mask 0x0000 0000 0000 0077 to zero
   reserved bits and the "last block" flag.  The "last block" flag is
   ignored because BABs and other security blocks MAY be added for some
   parts of the journey but not others, so the setting of this bit might
   change from hop to hop.

It should say:

   For non-primary blocks being included in the canonicalization, the
   block processing control flags value used for canonicalization is the
   unpacked SDNV value with reserved and mutable bits are masked to zero.
   The unpacked value is ANDed with mask 0x0000 0000 0000 0057 to zero
   reserved bits, the "last block" flag and the "Block was forwarded
   without being processed" bit.  The "last block" flag is ignored because
   BABs and other security blocks MAY be added for some parts of the
   journey but not others, so the setting of this bit might change from hop
   to hop. The "Block was forwarded without being processed" flag is
   ignored because the bundle may pass through a non security-aware node,
   and this flag would be set.



Section 2.1,pg.10 says:

   o  EID-references - composite field defined in [DTNBP] containing
      references to one or two endpoint identifiers (EIDs).  Presence of
      the EID-reference field is indicated by the setting of the "Block
      contains an EID-reference field" (EID_REF) bit of the block
      processing control flags.  If one or more references are present,
      flags in the ciphersuite ID field, described below, specify which.

      If no EID fields are present, then the composite field itself MUST
      be omitted entirely and the EID_REF bit MUST be unset.  A count
      field of zero is not permitted.

   o  The possible EIDs are:

      *  (OPTIONAL) Security-source - specifies the security-source for
         the block.  If this is omitted, then the source of the bundle
         is assumed to be the security-source unless otherwise
         indicated.

      *  (OPTIONAL) Security-destination - specifies the security-
         destination for the block.  If this is omitted, then the
         destination of the bundle is assumed to be the security-
         destination unless otherwise indicated.

      If two EIDs are present, security-source is first and security-
      destination comes second.

It should say:

   o  EID-references - composite field defined in [DTNBP] containing one
      or more references to endpoint identifiers (EIDs) (optional) [DTNBP].
      Presence of the EID-reference field is indicated by the setting
      of the "Block contains an EID-reference field" (EID_REF) bit of
      the block processing control flags.  If the security-source and
      security-destination are present, flags in the ciphersuite ID
      field, described below, specify which. Additional EID references MAY
      also be present.

      If no EID fields are present, then the composite field itself MUST
      be omitted entirely and the EID_REF bit MUST be unset.  A count
      field of zero is not permitted.

   o  Among the possible EIDs are:

      *  (OPTIONAL) Security-source - specifies the security-source for
         the block.  If this is omitted, then the source of the bundle
         is assumed to be the security-source unless otherwise
         indicated.

      *  (OPTIONAL) Security-destination - specifies the security-
         destination for the block.  If this is omitted, then the
         destination of the bundle is assumed to be the security-
         destination unless otherwise indicated.

      If present, the security-source and security-destination are the
      first EID references, with the security-source first, followed by
      the security-destination.



Section 2.5,pg.21 says:

   The process is reversed at the security-destination with the
   recovered plaintext block replacing the ESB that had encapsulated it.
   Processing of EID-list entries, if any, is described in Section 2.4,
   and this MUST be followed in order to correctly recover EIDs.

It should say:

   The EID reference to the security-source (if present) is the first
   entry in the EID list, followed by the EID reference to the security-
   destination (if present). The EID reference list from the block being
   protected is then copied to the ESB, and the EID reference count is
   updated appropriately.

   The process is reversed at the security-destination with the
   recovered plaintext block replacing the ESB that had encapsulated it.
   The security-source and security-destination (if present) are removed
   from the EID list, and any remaining entries are copied to the
   recovered plaintext block.



Section 4.4,pg.50 says:

   Subsequent ESBs MUST contain a correlator value to link them to the
   first ESB.  Security-source and security-destination are implied from
   the first ESB; however, see the discussion in Section 2.4 concerning
   EID-list entries.  Subsequent ESBs MUST contain security-parameters
   and security-result fields as follows:

It should say:

   Subsequent ESBs MUST contain a correlator value to link them to the
   first ESB.  Security-source and security-destination are implied from
   the first ESB; however, see the discussion in Section 2.5 concerning
   EID-list entries.  Subsequent ESBs MUST contain security-parameters
   and security-result fields as follows:



Section 2.5,pg.21 says:

   The ESB is placed in the bundle in the same position as the block
   being protected.  That is, the entire original block is processed
   (encrypted, etc.) and encapsulated in a "replacing" ESB-type block,
   and this appears in the bundle at the same sequential position as the
   original block.  The processed data is placed in the security-result
   field.

It should say:

   The ESB is placed in the bundle in the same position as the block
   being protected.  That is, the entire original block is processed
   (encrypted, etc.) and encapsulated in a "replacing" ESB-type block,
   and this appears in the bundle at the same sequential position as the
   original block.  The processed data is placed in the security-result
   field.

   Any existing EID-list in the to-be-encapsulated original block
   remains exactly as-is, and is copied to the EID-list for the
   replacing block.  The encapsulation process MUST NOT replace or
   remove the existing EID-list entries.  This is critically important
   for correct updating of entries at the security-destination. The
   EID-list copied into the replacing block MAY be preceded by EID
   references for the security-source and security-destination.