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

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

Sorry, didn't mean to be fussy. But since it is a niche case that I am interested in, I wanted to toss it out there early.

-Ed


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

> -----Original Message-----
> From: Stephen Farrell [mailto:[e-mail]]
> Sent: Tuesday, August 07, 2012 1:37 PM
> To: Birrane, Edward J.
> Cc: Peter Lovell; [e-mail]; [e-mail]; Corbett,
> Cherita L.; Elwyn Davies; [e-mail]
> Subject: Re: [dtn-security] Issue implementing security source/destination
> with ESB blocks
> 
> 
> Just in case it wasn't clear: I'd like if we had consensus on the text of the
> erratum on this list before we post it to the RFC editor site. If we have a huge
> row about that first, then so be it, but I'd hope that won't be needed:-)
> 
> Anyway, if Pete/Angela can craft text we can thrash it as needed.
> 
> S
> 
> On 08/07/2012 05:56 PM, Birrane, Edward J. wrote:
> > 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
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >
> >
> >