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

[Peter Lovell <[e-mail]>]

Hi Angela,

you're correct in that item 2 doesn't apply to PC3.

However it might be too strong to say that it doesn't apply to any, as-yet-undesigned, PC ciphersuite. Right now, the only EIDs defined are for sec-src and sec-dest but I can imagine ciphersuites that might have additional ones.

I think that the description for PC3 should be quite specific, but that the general description for PI and PC ciphersuites should be permissive.

Regards.....Peter

On Tue, Aug 13, 2013, [e-mail] <[e-mail]> wrote:

>Hi Peter,
>
>I don't think that item 2 applies to PCB. In ESB, there is a one-to-one
>replacement of extension blocks with ESB blocks. In PCB, there's a "first"
>PCB that contains the ciphersuite ID, parameters and the security src/dest
>(if present):
>
>   Put another way: when confidentiality will generate multiple blocks,
>   it MUST create a "first" PCB with the required ciphersuite ID,
>   parameters, etc., as specified above.  Typically, this PCB will
>   appear early in the bundle.  This "first" PCB contains the parameters
>   that apply to the payload and also to the other correlated PCBs.  The
>   correlated PCBs follow the "first" PCB and MUST NOT repeat the
>   ciphersuite-parameters, security-source, or security-destination
>   fields from the first PCB.
>
>Then this correlated PCB that encapsulates a PIB or PCB will copy the
>eid-list from the encapsulated block. I think the eid-list from the PIB or
>PCB will only contain the security src/dest of that block, so the new
>encapsulating PCB will also have at most 2 eid-refs.
>
>
>Thanks,
>Angela
>
>
>
>
>> Hi Angela,
>>
>> Item 1 is fine
>>
>> For item 2, the exception applies to both ESB and PCB. A PCB that
>> encapsulates a block that already has an EID-list, such as PIB or PCB, may
>> have a long list, just as ESB may. Your comments on items 3 and 4 also
>> need revisiting in this light - I think that their treatment will be the
>> same.
>>
>> I can draft some language for item 3 if you like. I would probably
>> describe it as copying the EID-list to the new block and then prepending
>> sec-src and sec-dest if necessary.
>>
>> Regards.....Peter
>>
>>
>> On Mon, Aug 6, 2012, [e-mail] <[e-mail]> wrote:
>>
>>>All,
>>>
>>>I'm trying to summarize the issues with RFC6257 for an errata list. How
>>>does this sound:
>>>
>>>1. In Section 2.1, in the description of the EID-references, it should
>>>mention that the EID-refs are preceded by a count field.
>>>
>>>2. Also in Section 2.1, it states that there can be at most 2 eid refs in
>>>an Abstract Security Block. An exception should be added for ESB, which
>>>can have an arbitrary number of eid refs based on the number in the
>>>original extension block and how many times it has been encapsulated.
>>>
>>>3. In Section 2.5, in the discussion of ESB, there needs to be some
>>>language describing how the eid-ref list in the encapsulated block is
>>>appended to the (optional) security src/dest of the encapsulating ESB. As
>>>a result, the eid-ref list in the ESB may be of arbitrary length. Also in
>>>Section 2.5, the statement that eid list entries should be handled
>>>analogously to PCB should be removed (along with the reference to Section
>>>2.4).
>>>
>>>4. In Section 4.4, in the description of ESB-RSA-AES128-EXT, the
>>> statement
>>>that eid list entries should be handled analogously to PCB should be
>>>removed (along with the reference to Section 2.4).
>>>
>>>
>>>Thanks,
>>>Angela
>>>
>>
>>
>