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

[Stephen Farrell <[e-mail]>]

Hi,

Sorry I've not been reading this since I was running around
madly IETFing last week;-)

I'd say best is if maybe Pete and Angela could draft an
erratum and post that here. We can stick into the system
once folks have had a few days to consider it. Probably also
worth a mention on dtn-interest at that point too since
that list has more people on it than this.

Once approved, it'll show up on the tools page for the RFC.
The RG chairs can approve errata like this.

Cheers,
S.

On 08/07/2012 05:13 PM, Peter Lovell wrote:
> 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
>>>>
>>>
>>>
>>
> 
> 
> 
>