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

[Peter Lovell <[e-mail]>]

Sounds like a plan …

Cheers…..Peter

On Aug 7, 2012, at 12:26 PM, Stephen Farrell <[e-mail]> wrote:

> 
> 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
>>>>> 
>>>> 
>>>> 
>>> 
>> 
>> 
>> 
>>