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

[Peter Lovell <[e-mail]>]

Hi all,

Ed is is quite correct that non-security blocks can have an EID list. I'd been looking too closely at RFC6257 and not at 5050. And as I was checking today I noticed an omission in 6257. Do we have an errata list for it? If not, we need one.

The omission is in Section 2.1 describing EID-references. It does not mention that the EID-refs are preceded by a count field, although it does rather cryptically say that "a count field of zero is not permitted". Lao, in the discussion that follows, it says that there can be two EIDs at most, which is incorrect. These errors probably came about because the EID-reference-list things were developed mostly with the BSP discussion rather than the design of the Bundle Protocol, and when we changed it for inclusion in BP, I didn't edit BSP hard enough.

Now, back to the main issue at hand. Ciphersuite PC3 does use the notion of carrying forward an existing EID-list, and adding one or two new EID-refs to the front of the list. I'm rusty on this code - not have dealt with it for several years - but it seems to me that the sec-src and sec-dest EIDs would be added  at the end of the list rather than the front, and that obviously needs correcting. The code in "validate" seems to decrypt and reconstitute the encapsulated block correctly. As you mention, an encapsulated block wouldn't have either of these which is why it never showed up before.

The general scheme is  ...
1. create an empty working block
2. copy necessary things from the existing block into the new one,
   especially the EID list
3. if there's a security-dest, push it on the front of the list
4. if there's a security-src, push it on the front of the list
5. get keys etc and encrypt the entire original block, encapsulating it
   in the security-result field of the new block
6. replace the existing block with the working copy (care needed here with
   locals as things such as block-type may have changed)

At the receiving end, the process is a reverse of the sending one,
in general ...
7. create an empty working block
8. process the incoming block info, extract keys and decrypt the block
9. assemble the new block from the pieces in the decrypted block
10. in particular, you have to get the EID list of the incoming block
    and step over EIDs for security-src and/or security-dest, if present.
    Then you copy the rest of the list (count plus EID-refs) from the
    incoming block onto the EID-list in the working block. Conceptually,
    this is popping them off the front of the list and copying the remainder.
11. copy the rest of the block, and update locals as necessary for block-type
    change etc

The PC3 code does most of this so it should serve as a reasonable guide, with the correction I mentioned.

Regards.....Peter


On Fri, Aug 3, 2012, Birrane, Edward J. <[e-mail]> wrote:

>Angela and I had some off-line e-mails to synchronize on our
>understanding of the issue.  I believe the following capture the needed
>behavior for ESBs:
>
> 1. The EID reference list of an ESB *must* be the union of all EID
>references of all blocks encapsulated by the ESB.
>
> 2. Because the EID reference list has variable size, we must place a
>count in front. (a-la RFC5050 canonical spec)
>
> 3. We may add a secsrc and secdst to the encapsulating EID reference
>list IFF they are available and not already represented in the EID  list
>
> 4. The EID ref count (added in #2 above) can therefore be increased by
>a max. value of 2 on each encapsulation.
>
> 5. At a security destination, any EIDs added from #3 above to the
>encapsulating EID list must be removed and any changes made in-situ to
>the encapsulating EID list must be propagated back to the encapsulated
>EID list.
>
> 6. Ciphersuite parameters in the ESB give some level of disposition as
>to the what/how of the security source and security destination in the
>encapsulating EID list. The mechanism for this is TBD.
>
>Are there any disagreements with any of the above?
>
>-Ed
>
>---
>Ed Birrane
>Senior Professional Staff, Space Department
>Johns Hopkins Applied Physics Laboratory
>(W) 443-778-7423 / (F) 443-228-3839
>
>
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]]
>> On Behalf Of Elwyn Davies
>> Sent: Thursday, August 02, 2012 10:45 PM
>> To: Peter Lovell
>> Cc: [e-mail]; [e-mail]
>> Subject: Re: [dtn-security] Issue implementing security source/destination
>> with ESB blocks
>>
>> Hi.
>>
>> Comment in line below...
>>
>> On 03/08/12 07:40, Peter Lovell wrote:
>> > re-send for list members as my origib=nal one bounced :( I guess I
>> > need to revise my addresses
>> >
>> > On Thu, Aug 2, 2012,
>> [e-mail]<[e-mail]>  wrote:
>> >
>> >> We've run into a problem while implementing the security source and
>> >> destination in the ESB blocks.  When ESB encapsulates a block, the
>> >> BSP RFC states that the eid ref list of the encapsulated block should
>> >> be used as the eid ref list of the encapsulating block, as in PCB.
>> >> However, the eid ref list of the encapsulating block also needs to
>> >> store the security source and destination. We aren't sure if the eid
>> >> ref list of the encapsulated block should be appended to the eid ref
>> >> list of the encapsulating block.  The RFC states that an Abstract
>> >> Security Block should have at most 2 eid references, and this would
>> >> contradict that statement.
>> >>
>> >> We get around this problem with PCB because the first PCB block's eid
>> >> ref list stores the security source and destination, and an extra PCB
>> >> block is added for any encapsulated blocks (and this extra PCB block
>> >> contains the eid ref list of the encapsulated block).  With ESB,
>> >> there is a one-to-one correspondence between the 'replacing' ESB
>> >> block and the block to be encapsulated, so we do not have an extra block
>> as in PCB.
>> >>
>> >>
>> >>
>> >> thanks,
>> >> Angela
>> >>
>> >>
>> >> Angela Hennessy
>> >> Laboratory for Telecommunication Sciences (LTS)
>> >
>> > Hi Angela,
>> >
>> > you're right - this is an issue that is not addressed in the spec.
>Some of the
>> ESB language was taken from that for PCB, which it closely resembles, but
>> this is an edge case not foreseen.
>> >
>> > There can be only two EIDs in the list because there are only two flags to
>> indicate their presence. The list is not length-counted for total size
>so one
>> can't skip over it.
>> >
>> > However, an EID list is specific to security blocks and doesn't
>occur in other
>> block types.
>> >
>> > ESBs and other security blocks are in separate spaces, i.e. an ESB must
>> never encapsulate PIBs or PCBs, and vice-versa.
>> >
>> > So the issue you describe can only occur in the super-encapsulation of
>> ESBs. For now, I'm not sure how best to deal with it, but my initial
>thought is
>> to use the previous EID list as the starting EID list, and then push
>security-
>> source and security-dest on the front, if needed and as appropriate. The
>> problem is how to indicate that there are other EIDs because, if we do not,
>> the processing of the block will fail. This will require some change to the
>> header and that will be a slow and deliberate process.
>> But not that difficult since the flag fields are SDNVs - so adding
>extra flags will
>> not break the ASB definition.
>>
>> Regards,
>> Elwyn
>> >
>> > In the meantime, let me suggest that you encapsulate the block and
>> reconstitute it at the security-dest without special EID processing. THat
>> means that any EID-munging between source and dest will be ineffective but
>> I suspect that it isn't common anyway [please correct me if that's wrong].
>> >
>> > The alternative is to avoid super-encryption of ESBs.
>> >
>> > Regards.....Peter
>> >
>> >
>> >
>> > _______________________________________________
>> > dtn-security mailing list
>> > [e-mail]
>> > https://www.irtf.org/mailman/listinfo/dtn-security
>>
>> _______________________________________________
>> dtn-security mailing list
>> [e-mail]
>> https://www.irtf.org/mailman/listinfo/dtn-security