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

["Birrane, Edward J." <[e-mail]>]

All,

  If, when writing the errata list, a proposed solution for surgery on the EID list is proposed, I would ask that you consider the following.

  If the existing EID list from the encapsulated block *already* contains the security source, security destination, or both (but not at the front of the EID-list) then I recommend we not repeat the security source and/or destination in the encapsulating block by prepending them.

  I would recommend flags and EID-list indices in the ciphersuite parameters rather than repetition or EID-list re-ordering.

-Ed


---
Ed Birrane
Senior Professional Staff, Space Department
Johns Hopkins Applied Physics Laboratory
(W) 443-778-7423 / (F) 443-228-3839
 

> -----Original Message-----
> From: Peter Lovell [mailto:[e-mail]]
> Sent: Tuesday, August 07, 2012 12:29 PM
> To: Stephen Farrell
> Cc: [e-mail]; [e-mail]; Corbett, Cherita L.;
> Birrane, Edward J.; Elwyn Davies; [e-mail]
> Subject: Re: [dtn-security] Issue implementing security source/destination
> with ESB blocks
> 
> 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
> >>>>>
> >>>>
> >>>>
> >>>
> >>
> >>
> >>
> >>