Re: [dtn-security] Issue implementing security source/destination with ESB blocks
Stephen Farrell <stephen.farrell@cs.tcd.ie> Tue, 07 August 2012 17:36 UTC
Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: dtn-security@ietfa.amsl.com
Delivered-To: dtn-security@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 294FD21F86F0 for <dtn-security@ietfa.amsl.com>; Tue, 7 Aug 2012 10:36:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k9i-9oJYqbik for <dtn-security@ietfa.amsl.com>; Tue, 7 Aug 2012 10:36:49 -0700 (PDT)
Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 5508621F86EE for <dtn-security@irtf.org>; Tue, 7 Aug 2012 10:36:49 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 6E243153657; Tue, 7 Aug 2012 18:36:48 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1344361007; bh=mwccSZ7x3ySCgd PKt72KwIMU83PGG5MpfsfeLT41IQ4=; b=gvoKV6Hi/McUXQSbAtFPD5IOc2DpGy 0/hm27iqD6ywboFST3hMeB5HsMddbrKHbhKK7C30pFg1eCNeRINcTdoAXRJ111LT +9QF0fOBP6Gjkp+CzENAFrCp4ATxLbqIleSEUKBaBgLN70mwFIDhNqOfxI/LI4Ja qEB20VDscURHkjdxEEKRfFrde9BPeA87GSHSuZHs8p8JtEJHSAKvD+sQaUdVG9/v u9SBnO+DWaIPZ/85/U7sb/2HiXvjGoKjZVxOPJm0wrMcW5MJ3pNw5oto3nVI7GBS 5qvijrxQ15or8p2dVopBzuR1lB9HdzbLW/eK6W59fz0tx3zqcraeNlfA==
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id SvecGFQ5vCJv; Tue, 7 Aug 2012 18:36:47 +0100 (IST)
Received: from [IPv6:2001:770:10:203:49b3:3973:5610:abc4] (unknown [IPv6:2001:770:10:203:49b3:3973:5610:abc4]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id C5ED1171509; Tue, 7 Aug 2012 18:36:43 +0100 (IST)
Message-ID: <5021522B.4000309@cs.tcd.ie>
Date: Tue, 07 Aug 2012 18:36:43 +0100
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0
MIME-Version: 1.0
To: "Birrane, Edward J." <Edward.Birrane@jhuapl.edu>
References: <20120802214016.1861780438@smtp.mail.me.com> <501B3B2F.5090508@folly.org.uk> <329D879C76FDD04AAAE84BB1D89B397006842FE3A0@aplesfreedom.dom1.jhuapl.edu> <20120803221701.223057816@smtp.mail.me.com> <e5f316d31c243f6f6758ffc0a81303ca.squirrel@webmail.math.umd.edu> <20120806162008.1123881582@smtp.mail.me.com> <a7078fb0d6bad00c68fe43ca5272a52b.squirrel@webmail.math.umd.edu> <20120807161303.1666733293@smtp.mail.me.com> <502141C6.8030804@cs.tcd.ie> <2E6CABBD-4D93-4829-B6ED-3720313439C0@mac.com> <329D879C76FDD04AAAE84BB1D89B39700689BEEF2B@aplesfreedom.dom1.jhuapl.edu>
In-Reply-To: <329D879C76FDD04AAAE84BB1D89B39700689BEEF2B@aplesfreedom.dom1.jhuapl.edu>
X-Enigmail-Version: 1.4.3
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: "ahennes1@math.umd.edu" <ahennes1@math.umd.edu>, "dtn-security@irtf.org" <dtn-security@irtf.org>
Subject: Re: [dtn-security] Issue implementing security source/destination with ESB blocks
X-BeenThere: dtn-security@irtf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Security." <dtn-security.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/dtn-security>, <mailto:dtn-security-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/dtn-security>
List-Post: <mailto:dtn-security@irtf.org>
List-Help: <mailto:dtn-security-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/dtn-security>, <mailto:dtn-security-request@irtf.org?subject=subscribe>
X-List-Received-Date: Tue, 07 Aug 2012 17:36:51 -0000
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:plovell@mac.com] >> Sent: Tuesday, August 07, 2012 12:29 PM >> To: Stephen Farrell >> Cc: ahennes1@math.umd.edu; aloomis@sarn.org; Corbett, Cherita L.; >> Birrane, Edward J.; Elwyn Davies; dtn-security@irtf.org >> 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 <stephen.farrell@cs.tcd.ie> >> 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, ahennes1@math.umd.edu >> <ahennes1@math.umd.edu> 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, ahennes1@math.umd.edu >> <ahennes1@math.umd.edu> 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 >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >>>> >>>> > > >
- [dtn-security] Issue implementing security source… ahennes1
- Re: [dtn-security] Issue implementing security so… Stephen Farrell
- Re: [dtn-security] Issue implementing security so… ahennes1
- Re: [dtn-security] Issue implementing security so… Birrane, Edward J.
- Re: [dtn-security] Issue implementing security so… Birrane, Edward J.
- Re: [dtn-security] Issue implementing security so… ahennes1
- Re: [dtn-security] Issue implementing security so… Peter Lovell
- Re: [dtn-security] Issue implementing security so… Birrane, Edward J.
- Re: [dtn-security] Issue implementing security so… Elwyn Davies
- Re: [dtn-security] Issue implementing security so… Birrane, Edward J.
- [dtn-security] Re(2): Issue implementing security… Peter Lovell
- Re: [dtn-security] Issue implementing security so… ahennes1
- [dtn-security] Re(2): Issue implementing security… Peter Lovell
- Re: [dtn-security] Re(2): Issue implementing secu… ahennes1
- Re: [dtn-security] Issue implementing security so… Peter Lovell
- [dtn-security] Re(4): Issue implementing security… Peter Lovell
- Re: [dtn-security] Issue implementing security so… Stephen Farrell
- Re: [dtn-security] Issue implementing security so… Peter Lovell
- Re: [dtn-security] Issue implementing security so… Birrane, Edward J.
- Re: [dtn-security] Issue implementing security so… Stephen Farrell
- Re: [dtn-security] Issue implementing security so… Birrane, Edward J.
- Re: [dtn-security] Issue implementing security so… ahennes1
- Re: [dtn-security] Issue implementing security so… Stephen Farrell