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

[Stephen Farrell <[e-mail]>]

As a process-point, that's a *big* erratum. If this were
an IETF standards track document, we'd probably encourage
it to be done as I-D that updated the BSP RFC. I don't
believe the IRTF have any agreed policy for when things
should be done as an erratum or as a separate I-D, so
I'll ask about that. Meanwhile, if folks could comment
on the proposal that'd be good, so's when we know what
works process-wise, we'll be ready to go ahead.

S.

On 09/03/2012 02:05 PM, [e-mail] wrote:
> 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.
> 
> 
> _______________________________________________
> dtn-security mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/dtn-security
> 
>