From ahennes1@math.umd.edu Thu Aug 2 08:52:49 2012 Return-Path: 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 1518121F869A for ; Thu, 2 Aug 2012 08:52:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] 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 TBCLfkntRkAJ for ; Thu, 2 Aug 2012 08:52:48 -0700 (PDT) Received: from mailfilter.ece.umd.edu (mailfilter.ece.umd.edu [129.2.90.4]) by ietfa.amsl.com (Postfix) with ESMTP id 4732F21F868A for ; Thu, 2 Aug 2012 08:52:48 -0700 (PDT) X-ASG-Debug-ID: 1343922765-04739d104d313280001-NoPDhg Received: from svr4.math.umd.edu ([129.2.56.14]) by mailfilter.ece.umd.edu with ESMTP id DFPXRoxsMYSdVTx7; Thu, 02 Aug 2012 11:52:45 -0400 (EDT) X-Barracuda-Envelope-From: ahennes1@math.umd.edu X-Barracuda-Apparent-Source-IP: 129.2.56.14 Received: by svr4.math.umd.edu (Postfix, from userid 48) id 4D9B26FC83; Thu, 2 Aug 2012 11:52:45 -0400 (EDT) Received: from 65.127.220.136 by webmail.math.umd.edu with HTTP; Thu, 2 Aug 2012 11:52:45 -0400 Message-ID: <38cc307b4972055558f2e38b0293db0c.squirrel@webmail.math.umd.edu> Date: Thu, 2 Aug 2012 11:52:45 -0400 From: ahennes1@math.umd.edu X-ASG-Orig-Subj: Issue implementing security source/destination with ESB blocks To: dtn-security@irtf.org, stephen.farrell@cs.tcd.ie, dtnbsp@gmail.com User-Agent: SquirrelMail/1.4.20 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Barracuda-Connect: UNKNOWN[129.2.56.14] X-Barracuda-Start-Time: 1343922765 X-Barracuda-URL: http://mailfilter.ece.umd.edu:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at ece.umd.edu X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=7.0 KILL_LEVEL=1000.0 tests=NO_REAL_NAME X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.104479 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 NO_REAL_NAME From: does not include a real name Subject: [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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 15:52:49 -0000 We've run into a problem while implementing the security source and destination in the ESB blocks. When ESB encapsulates a block, the BSP RFC states that the eid ref list of the encapsulated block should be used as the eid ref list of the encapsulating block, as in PCB. However, the eid ref list of the encapsulating block also needs to store the security source and destination. We aren't sure if the eid ref list of the encapsulated block should be appended to the eid ref list of the encapsulating block. The RFC states that an Abstract Security Block should have at most 2 eid references, and this would contradict that statement. We get around this problem with PCB because the first PCB block's eid ref list stores the security source and destination, and an extra PCB block is added for any encapsulated blocks (and this extra PCB block contains the eid ref list of the encapsulated block). With ESB, there is a one-to-one correspondence between the 'replacing' ESB block and the block to be encapsulated, so we do not have an extra block as in PCB. thanks, Angela Angela Hennessy Laboratory for Telecommunication Sciences (LTS) From stephen.farrell@cs.tcd.ie Thu Aug 2 09:15:41 2012 Return-Path: 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 DB3D821E8041 for ; Thu, 2 Aug 2012 09:15:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.569 X-Spam-Level: X-Spam-Status: No, score=-102.569 tagged_above=-999 required=5 tests=[AWL=0.030, 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 s9+Wl4J1iIyD for ; Thu, 2 Aug 2012 09:15:40 -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 7A4FE21F84AF for ; Thu, 2 Aug 2012 09:15:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id D7795171477; Thu, 2 Aug 2012 17:15:39 +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=1343924139; bh=nZcuAEQPg+/Rbg CZT7C+VJyhERS4z3I/z/o9NMS5GNo=; b=CvMm5vAYtKi1aIVzyMRw78segQCnlb bJZpFU5jHqz831G6eLFrfGgy0wYOAARId9tZWovawJlAsrvKMrihNNExrJRLhN2Q yNdaxnNRDcJIu3uqJjjdXsYWZUEkdsiIk4hgQzX2L9E8LF13+cT1/UNNnBlj1YIx vlIyBXYbZSW0QE0DlSnXTowG0wiRpwOZs1Cn9cGmYMKGVG9VMeWU+uaCZsznZ1+i yjCNcziR3msTZEDJekCL00S2YV9ANqnn8P92He72TkTgwu+utrFyd1y3bkiD6adF KR7paNnvm6f2K5DQMoio9I9rj25l9zd0AREZwBIRLh3lb6gYuTEsXiUw== 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 NkqPV+fjMp2c; Thu, 2 Aug 2012 17:15:39 +0100 (IST) Received: from [IPv6:2001:df8:0:96:8853:ef9b:1b62:6a9b] (unknown [IPv6:2001:df8:0:96:8853:ef9b:1b62:6a9b]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 199BA17147A; Thu, 2 Aug 2012 17:15:34 +0100 (IST) Message-ID: <501AA7A4.4040608@cs.tcd.ie> Date: Thu, 02 Aug 2012 17:15:32 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: ahennes1@math.umd.edu References: <38cc307b4972055558f2e38b0293db0c.squirrel@webmail.math.umd.edu> In-Reply-To: <38cc307b4972055558f2e38b0293db0c.squirrel@webmail.math.umd.edu> X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: dtnbsp@gmail.com, 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 16:15:42 -0000 Hi Angela, On 08/02/2012 04:52 PM, ahennes1@math.umd.edu wrote: > We've run into a problem while implementing the security source and > destination in the ESB blocks. When ESB encapsulates a block, the BSP RFC > states that the eid ref list of the encapsulated block should be used as > the eid ref list of the encapsulating block, as in PCB. However, the eid > ref list of the encapsulating block also needs to store the security > source and destination. We aren't sure if the eid ref list of the > encapsulated block should be appended to the eid ref list of the > encapsulating block. The RFC states that an Abstract Security Block > should have at most 2 eid references, and this would contradict that > statement. > > We get around this problem with PCB because the first PCB block's eid ref > list stores the security source and destination, and an extra PCB block is > added for any encapsulated blocks (and this extra PCB block contains the > eid ref list of the encapsulated block). With ESB, there is a one-to-one > correspondence between the 'replacing' ESB block and the block to be > encapsulated, so we do not have an extra block as in PCB. Did you have a solution in mind? Since I'm at the IETF meeting I won't have time this week to look into it, sorry. If you bug me next week, I will:-) S. > > > > thanks, > Angela > > > Angela Hennessy > Laboratory for Telecommunication Sciences (LTS) > > From ahennes1@math.umd.edu Thu Aug 2 09:38:52 2012 Return-Path: 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 92C9511E8107 for ; Thu, 2 Aug 2012 09:38:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.299 X-Spam-Level: X-Spam-Status: No, score=-5.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 HdxcQjNIXcYG for ; Thu, 2 Aug 2012 09:38:52 -0700 (PDT) Received: from mailfilter.ece.umd.edu (mailfilter.ece.umd.edu [129.2.90.4]) by ietfa.amsl.com (Postfix) with ESMTP id CB45E11E80FA for ; Thu, 2 Aug 2012 09:38:51 -0700 (PDT) X-ASG-Debug-ID: 1343925529-04739d104c316df0001-NoPDhg Received: from svr4.math.umd.edu ([129.2.56.14]) by mailfilter.ece.umd.edu with ESMTP id wEmfpqciOE1h11dj; Thu, 02 Aug 2012 12:38:49 -0400 (EDT) X-Barracuda-Envelope-From: ahennes1@math.umd.edu X-Barracuda-Apparent-Source-IP: 129.2.56.14 Received: by svr4.math.umd.edu (Postfix, from userid 48) id 9414A6FC83; Thu, 2 Aug 2012 12:38:49 -0400 (EDT) Received: from 65.127.220.136 by webmail.math.umd.edu with HTTP; Thu, 2 Aug 2012 12:38:49 -0400 Message-ID: <614d049ab50809bfdb47ebf4934ae42a.squirrel@webmail.math.umd.edu> In-Reply-To: <501AA7A4.4040608@cs.tcd.ie> References: <38cc307b4972055558f2e38b0293db0c.squirrel@webmail.math.umd.edu> <501AA7A4.4040608@cs.tcd.ie> Date: Thu, 2 Aug 2012 12:38:49 -0400 From: ahennes1@math.umd.edu X-ASG-Orig-Subj: Re: Issue implementing security source/destination with ESB blocks To: "Stephen Farrell" User-Agent: SquirrelMail/1.4.20 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Barracuda-Connect: UNKNOWN[129.2.56.14] X-Barracuda-Start-Time: 1343925529 X-Barracuda-URL: http://mailfilter.ece.umd.edu:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at ece.umd.edu X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=7.0 KILL_LEVEL=1000.0 tests=BSF_SC0_MISMATCH_TO, NO_REAL_NAME X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.104483 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 NO_REAL_NAME From: does not include a real name 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header Cc: dtnbsp@gmail.com, 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 16:38:52 -0000 Hi Stephen, We were thinking the best solution might be to append the eid ref list of the encapsulated block to the eid ref list of the ESB block (which would contain the security src and dest). This would mean there might be 4 eid references in this list, but this seems better than the alternative solution, which would be to add an extra ESB block (as is done in PCB). If there are other proposed solutions to this, we'd definitely be interested in hearing them. Thanks, Angela > > Hi Angela, > > On 08/02/2012 04:52 PM, ahennes1@math.umd.edu wrote: >> We've run into a problem while implementing the security source and >> destination in the ESB blocks. When ESB encapsulates a block, the BSP >> RFC >> states that the eid ref list of the encapsulated block should be used as >> the eid ref list of the encapsulating block, as in PCB. However, the >> eid >> ref list of the encapsulating block also needs to store the security >> source and destination. We aren't sure if the eid ref list of the >> encapsulated block should be appended to the eid ref list of the >> encapsulating block. The RFC states that an Abstract Security Block >> should have at most 2 eid references, and this would contradict that >> statement. >> >> We get around this problem with PCB because the first PCB block's eid >> ref >> list stores the security source and destination, and an extra PCB block >> is >> added for any encapsulated blocks (and this extra PCB block contains the >> eid ref list of the encapsulated block). With ESB, there is a >> one-to-one >> correspondence between the 'replacing' ESB block and the block to be >> encapsulated, so we do not have an extra block as in PCB. > > Did you have a solution in mind? Since I'm at the IETF meeting I won't > have time this week to look into it, sorry. If you bug me next week, > I will:-) > > S. > > >> >> >> >> thanks, >> Angela >> >> >> Angela Hennessy >> Laboratory for Telecommunication Sciences (LTS) >> >> > From edward.birrane@jhuapl.edu Thu Aug 2 09:54:48 2012 Return-Path: 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 3193D11E8158 for ; Thu, 2 Aug 2012 09:54:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 Hj-GPaDA6qkH for ; Thu, 2 Aug 2012 09:54:47 -0700 (PDT) Received: from jhuapl.edu (piper.jhuapl.edu [128.244.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 3F8B211E8153 for ; Thu, 2 Aug 2012 09:54:46 -0700 (PDT) Received: from ([128.244.198.90]) by piper.jhuapl.edu with ESMTP with TLS id 5Y8HCH1.141679301; Thu, 02 Aug 2012 12:54:41 -0400 Received: from aplesfreedom.dom1.jhuapl.edu ([128.244.198.204]) by aplexcas1.dom1.jhuapl.edu ([128.244.198.90]) with mapi; Thu, 2 Aug 2012 12:54:41 -0400 From: "Birrane, Edward J." To: "ahennes1@math.umd.edu" , Stephen Farrell Date: Thu, 2 Aug 2012 12:54:40 -0400 Thread-Topic: [dtn-security] Issue implementing security source/destination with ESB blocks Thread-Index: Ac1wzVEX6m2V1cLITPmo3Rv4L9RTzQAADPJg Message-ID: <329D879C76FDD04AAAE84BB1D89B397006842FE0B6@aplesfreedom.dom1.jhuapl.edu> References: <38cc307b4972055558f2e38b0293db0c.squirrel@webmail.math.umd.edu> <501AA7A4.4040608@cs.tcd.ie> <614d049ab50809bfdb47ebf4934ae42a.squirrel@webmail.math.umd.edu> In-Reply-To: <614d049ab50809bfdb47ebf4934ae42a.squirrel@webmail.math.umd.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dtnbsp@gmail.com" , "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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 16:54:48 -0000 Angela, Nice catch. Just spent a few minutes refreshing myself on 5050 and 6257 = and agree that this is a rather problematic contradiction in the RFC. =20 I understand the need to not change the EID list, as stitching together t= he updated EID list with the originally encapsulated EID list is tricky eno= ugh at the security destination without changing the order of things.=20 There are times when the security destination is omitted for some reason = (i.e., it is the same as the bundle destination), or the security source is= omitted (i.e. an anonymous bundle using a default group key, or the securi= ty source is the same as the bundle source). So, guaranteeing that the 1st= two items of the ESB EID list will be the secsrc and srcdst may not be des= irable for all users. I would recommend changing the language of 6257 to place security and des= tination EIDs, when present, in the security parameters (Section 2.6) and a= void any surgery/dependency on the EID list itself. -Ed --- Ed Birrane Senior Professional Staff, Space Department Johns Hopkins Applied Physics Laboratory (W) 443-778-7423 / (F) 443-228-3839 =20 > -----Original Message----- > From: dtn-security-bounces@irtf.org [mailto:dtn-security-bounces@irtf.org= ] > On Behalf Of ahennes1@math.umd.edu > Sent: Thursday, August 02, 2012 12:39 PM > To: Stephen Farrell > Cc: dtnbsp@gmail.com; dtn-security@irtf.org > Subject: Re: [dtn-security] Issue implementing security source/destinatio= n > with ESB blocks >=20 > Hi Stephen, >=20 > We were thinking the best solution might be to append the eid ref list of= the > encapsulated block to the eid ref list of the ESB block (which would cont= ain > the security src and dest). This would mean there might be 4 eid referenc= es > in this list, but this seems better than the alternative solution, which = would > be to add an extra ESB block (as is done in PCB). >=20 > If there are other proposed solutions to this, we'd definitely be interes= ted in > hearing them. >=20 >=20 > Thanks, > Angela >=20 > > > > Hi Angela, > > > > On 08/02/2012 04:52 PM, ahennes1@math.umd.edu wrote: > >> We've run into a problem while implementing the security source and > >> destination in the ESB blocks. When ESB encapsulates a block, the > >> BSP RFC states that the eid ref list of the encapsulated block should > >> be used as the eid ref list of the encapsulating block, as in PCB. > >> However, the eid ref list of the encapsulating block also needs to > >> store the security source and destination. We aren't sure if the eid > >> ref list of the encapsulated block should be appended to the eid ref > >> list of the encapsulating block. The RFC states that an Abstract > >> Security Block should have at most 2 eid references, and this would > >> contradict that statement. > >> > >> We get around this problem with PCB because the first PCB block's eid > >> ref list stores the security source and destination, and an extra PCB > >> block is added for any encapsulated blocks (and this extra PCB block > >> contains the eid ref list of the encapsulated block). With ESB, > >> there is a one-to-one correspondence between the 'replacing' ESB > >> block and the block to be encapsulated, so we do not have an extra > >> block as in PCB. > > > > Did you have a solution in mind? Since I'm at the IETF meeting I won't > > have time this week to look into it, sorry. If you bug me next week, I > > will:-) > > > > S. > > > > > >> > >> > >> > >> thanks, > >> Angela > >> > >> > >> Angela Hennessy > >> Laboratory for Telecommunication Sciences (LTS) > >> > >> > > >=20 > _______________________________________________ > dtn-security mailing list > dtn-security@irtf.org > https://www.irtf.org/mailman/listinfo/dtn-security From edward.birrane@jhuapl.edu Thu Aug 2 10:13:09 2012 Return-Path: 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 1AD0C11E8123 for ; Thu, 2 Aug 2012 10:13:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 0FTe0fWDqNEp for ; Thu, 2 Aug 2012 10:13:08 -0700 (PDT) Received: from jhuapl.edu (piper.jhuapl.edu [128.244.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 0469D11E8091 for ; Thu, 2 Aug 2012 10:13:07 -0700 (PDT) Received: from ([128.244.198.91]) by piper.jhuapl.edu with ESMTP with TLS id 5Y8HCH1.141680843; Thu, 02 Aug 2012 13:12:58 -0400 Received: from aplesfreedom.dom1.jhuapl.edu ([128.244.198.204]) by aplexcas2.dom1.jhuapl.edu ([128.244.198.91]) with mapi; Thu, 2 Aug 2012 13:12:58 -0400 From: "Birrane, Edward J." To: "Birrane, Edward J." , "ahennes1@math.umd.edu" , Stephen Farrell Date: Thu, 2 Aug 2012 13:12:57 -0400 Thread-Topic: [dtn-security] Issue implementing security source/destination with ESB blocks Thread-Index: Ac1wzVEX6m2V1cLITPmo3Rv4L9RTzQAADPJgAADZU/A= Message-ID: <329D879C76FDD04AAAE84BB1D89B397006842FE0CA@aplesfreedom.dom1.jhuapl.edu> References: <38cc307b4972055558f2e38b0293db0c.squirrel@webmail.math.umd.edu> <501AA7A4.4040608@cs.tcd.ie> <614d049ab50809bfdb47ebf4934ae42a.squirrel@webmail.math.umd.edu> <329D879C76FDD04AAAE84BB1D89B397006842FE0B6@aplesfreedom.dom1.jhuapl.edu> In-Reply-To: <329D879C76FDD04AAAE84BB1D89B397006842FE0B6@aplesfreedom.dom1.jhuapl.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dtnbsp@gmail.com" , "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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 17:13:09 -0000 Drat, let me retract that recommendation, since it would result in secsrc a= nd secdst perhaps not in the EID list and, therefore, make downstream dicti= onary pruning problematic. Given that we must potentially represent secsrc and/or secdst to the EID li= st, I think we would need some mechanism to ensure that: 1. The secsrc and secdst are only added when they are known/supplied. (they= are both optional) 2. You can have one but not the other 3. The ESB security parameters let you know whether the EIDs need to be cop= ied back to the originating encapsulated EID list or not. I think adding some flags in the security parameters can cover these cases.= Is there a better way to handle this? -Ed --- Ed Birrane Senior Professional Staff, Space Department Johns Hopkins Applied Physics Laboratory (W) 443-778-7423 / (F) 443-228-3839 =20 > -----Original Message----- > From: dtn-security-bounces@irtf.org [mailto:dtn-security-bounces@irtf.org= ] > On Behalf Of Birrane, Edward J. > Sent: Thursday, August 02, 2012 12:55 PM > To: ahennes1@math.umd.edu; Stephen Farrell > Cc: dtnbsp@gmail.com; dtn-security@irtf.org > Subject: Re: [dtn-security] Issue implementing security source/destinatio= n > with ESB blocks >=20 > Angela, >=20 > Nice catch. Just spent a few minutes refreshing myself on 5050 and 625= 7 > and agree that this is a rather problematic contradiction in the RFC. >=20 > I understand the need to not change the EID list, as stitching together= the > updated EID list with the originally encapsulated EID list is tricky enou= gh at > the security destination without changing the order of things. >=20 > There are times when the security destination is omitted for some reaso= n > (i.e., it is the same as the bundle destination), or the security source = is > omitted (i.e. an anonymous bundle using a default group key, or the secur= ity > source is the same as the bundle source). So, guaranteeing that the 1st = two > items of the ESB EID list will be the secsrc and srcdst may not be desira= ble for > all users. >=20 > I would recommend changing the language of 6257 to place security and > destination EIDs, when present, in the security parameters (Section 2.6) = and > avoid any surgery/dependency on the EID list itself. >=20 > -Ed >=20 > --- > Ed Birrane > Senior Professional Staff, Space Department Johns Hopkins Applied Physics > Laboratory > (W) 443-778-7423 / (F) 443-228-3839 >=20 >=20 > > -----Original Message----- > > From: dtn-security-bounces@irtf.org > > [mailto:dtn-security-bounces@irtf.org] > > On Behalf Of ahennes1@math.umd.edu > > Sent: Thursday, August 02, 2012 12:39 PM > > To: Stephen Farrell > > Cc: dtnbsp@gmail.com; dtn-security@irtf.org > > Subject: Re: [dtn-security] Issue implementing security > > source/destination with ESB blocks > > > > Hi Stephen, > > > > We were thinking the best solution might be to append the eid ref list > > of the encapsulated block to the eid ref list of the ESB block (which > > would contain the security src and dest). This would mean there might > > be 4 eid references in this list, but this seems better than the > > alternative solution, which would be to add an extra ESB block (as is d= one in > PCB). > > > > If there are other proposed solutions to this, we'd definitely be > > interested in hearing them. > > > > > > Thanks, > > Angela > > > > > > > > Hi Angela, > > > > > > On 08/02/2012 04:52 PM, ahennes1@math.umd.edu wrote: > > >> We've run into a problem while implementing the security source and > > >> destination in the ESB blocks. When ESB encapsulates a block, the > > >> BSP RFC states that the eid ref list of the encapsulated block > > >> should be used as the eid ref list of the encapsulating block, as in= PCB. > > >> However, the eid ref list of the encapsulating block also needs to > > >> store the security source and destination. We aren't sure if the > > >> eid ref list of the encapsulated block should be appended to the > > >> eid ref list of the encapsulating block. The RFC states that an > > >> Abstract Security Block should have at most 2 eid references, and > > >> this would contradict that statement. > > >> > > >> We get around this problem with PCB because the first PCB block's > > >> eid ref list stores the security source and destination, and an > > >> extra PCB block is added for any encapsulated blocks (and this > > >> extra PCB block contains the eid ref list of the encapsulated > > >> block). With ESB, there is a one-to-one correspondence between the > > >> 'replacing' ESB block and the block to be encapsulated, so we do > > >> not have an extra block as in PCB. > > > > > > Did you have a solution in mind? Since I'm at the IETF meeting I > > > won't have time this week to look into it, sorry. If you bug me next > > > week, I > > > will:-) > > > > > > S. > > > > > > > > >> > > >> > > >> > > >> thanks, > > >> Angela > > >> > > >> > > >> Angela Hennessy > > >> Laboratory for Telecommunication Sciences (LTS) > > >> > > >> > > > > > > > _______________________________________________ > > dtn-security mailing list > > dtn-security@irtf.org > > https://www.irtf.org/mailman/listinfo/dtn-security > _______________________________________________ > dtn-security mailing list > dtn-security@irtf.org > https://www.irtf.org/mailman/listinfo/dtn-security From ahennes1@math.umd.edu Thu Aug 2 11:31:04 2012 Return-Path: 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 4FA0711E8229 for ; Thu, 2 Aug 2012 11:31:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 jMVRU7THvpLs for ; Thu, 2 Aug 2012 11:31:03 -0700 (PDT) Received: from mailfilter.ece.umd.edu (mailfilter.ece.umd.edu [129.2.90.4]) by ietfa.amsl.com (Postfix) with ESMTP id 43B9B11E8209 for ; Thu, 2 Aug 2012 11:31:03 -0700 (PDT) X-ASG-Debug-ID: 1343932260-04739d104c31f570001-NoPDhg Received: from svr4.math.umd.edu ([129.2.56.14]) by mailfilter.ece.umd.edu with ESMTP id Q3G6pEoCXVfYgfzL; Thu, 02 Aug 2012 14:31:00 -0400 (EDT) X-Barracuda-Envelope-From: ahennes1@math.umd.edu X-Barracuda-Apparent-Source-IP: 129.2.56.14 Received: by svr4.math.umd.edu (Postfix, from userid 48) id 9415E6FC83; Thu, 2 Aug 2012 14:31:00 -0400 (EDT) Received: from 65.127.220.136 by webmail.math.umd.edu with HTTP; Thu, 2 Aug 2012 14:31:00 -0400 Message-ID: In-Reply-To: <329D879C76FDD04AAAE84BB1D89B397006842FE0CA@aplesfreedom.dom1.jhuapl.edu> References: <38cc307b4972055558f2e38b0293db0c.squirrel@webmail.math.umd.edu> <501AA7A4.4040608@cs.tcd.ie> <614d049ab50809bfdb47ebf4934ae42a.squirrel@webmail.math.umd.edu> <329D879C76FDD04AAAE84BB1D89B397006842FE0B6@aplesfreedom.dom1.jhuapl.edu> <329D879C76FDD04AAAE84BB1D89B397006842FE0CA@aplesfreedom.dom1.jhuapl.edu> Date: Thu, 2 Aug 2012 14:31:00 -0400 From: ahennes1@math.umd.edu X-ASG-Orig-Subj: RE: [dtn-security] Issue implementing security source/destination with ESB blocks To: "Birrane, Edward J." User-Agent: SquirrelMail/1.4.20 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Barracuda-Connect: UNKNOWN[129.2.56.14] X-Barracuda-Start-Time: 1343932260 X-Barracuda-URL: http://mailfilter.ece.umd.edu:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at ece.umd.edu X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=7.0 KILL_LEVEL=1000.0 tests=BSF_SC0_MISMATCH_TO, NO_REAL_NAME X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.104489 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 NO_REAL_NAME From: does not include a real name 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header Cc: "dtnbsp@gmail.com" , "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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 18:31:04 -0000 Hi Ed, Thanks for the quick reply! I think you're right that we'll need some extra flags to cover these cases. I can't think of any other way to handle this, but we're definitely open to other ideas. Thanks, Angela > Drat, let me retract that recommendation, since it would result in secsrc > and secdst perhaps not in the EID list and, therefore, make downstream > dictionary pruning problematic. > > Given that we must potentially represent secsrc and/or secdst to the EID > list, I think we would need some mechanism to ensure that: > > 1. The secsrc and secdst are only added when they are known/supplied. > (they are both optional) > 2. You can have one but not the other > 3. The ESB security parameters let you know whether the EIDs need to be > copied back to the originating encapsulated EID list or not. > > I think adding some flags in the security parameters can cover these > cases. Is there a better way to handle this? > > -Ed > > --- > Ed Birrane > Senior Professional Staff, Space Department > Johns Hopkins Applied Physics Laboratory > (W) 443-778-7423 / (F) 443-228-3839 > > >> -----Original Message----- >> From: dtn-security-bounces@irtf.org >> [mailto:dtn-security-bounces@irtf.org] >> On Behalf Of Birrane, Edward J. >> Sent: Thursday, August 02, 2012 12:55 PM >> To: ahennes1@math.umd.edu; Stephen Farrell >> Cc: dtnbsp@gmail.com; dtn-security@irtf.org >> Subject: Re: [dtn-security] Issue implementing security >> source/destination >> with ESB blocks >> >> Angela, >> >> Nice catch. Just spent a few minutes refreshing myself on 5050 and >> 6257 >> and agree that this is a rather problematic contradiction in the RFC. >> >> I understand the need to not change the EID list, as stitching >> together the >> updated EID list with the originally encapsulated EID list is tricky >> enough at >> the security destination without changing the order of things. >> >> There are times when the security destination is omitted for some >> reason >> (i.e., it is the same as the bundle destination), or the security source >> is >> omitted (i.e. an anonymous bundle using a default group key, or the >> security >> source is the same as the bundle source). So, guaranteeing that the 1st >> two >> items of the ESB EID list will be the secsrc and srcdst may not be >> desirable for >> all users. >> >> I would recommend changing the language of 6257 to place security and >> destination EIDs, when present, in the security parameters (Section 2.6) >> and >> avoid any surgery/dependency on the EID list itself. >> >> -Ed >> >> --- >> Ed Birrane >> Senior Professional Staff, Space Department Johns Hopkins Applied >> Physics >> Laboratory >> (W) 443-778-7423 / (F) 443-228-3839 >> >> >> > -----Original Message----- >> > From: dtn-security-bounces@irtf.org >> > [mailto:dtn-security-bounces@irtf.org] >> > On Behalf Of ahennes1@math.umd.edu >> > Sent: Thursday, August 02, 2012 12:39 PM >> > To: Stephen Farrell >> > Cc: dtnbsp@gmail.com; dtn-security@irtf.org >> > Subject: Re: [dtn-security] Issue implementing security >> > source/destination with ESB blocks >> > >> > Hi Stephen, >> > >> > We were thinking the best solution might be to append the eid ref list >> > of the encapsulated block to the eid ref list of the ESB block (which >> > would contain the security src and dest). This would mean there might >> > be 4 eid references in this list, but this seems better than the >> > alternative solution, which would be to add an extra ESB block (as is >> done in >> PCB). >> > >> > If there are other proposed solutions to this, we'd definitely be >> > interested in hearing them. >> > >> > >> > Thanks, >> > Angela >> > >> > > >> > > Hi Angela, >> > > >> > > On 08/02/2012 04:52 PM, ahennes1@math.umd.edu wrote: >> > >> We've run into a problem while implementing the security source and >> > >> destination in the ESB blocks. When ESB encapsulates a block, the >> > >> BSP RFC states that the eid ref list of the encapsulated block >> > >> should be used as the eid ref list of the encapsulating block, as >> in PCB. >> > >> However, the eid ref list of the encapsulating block also needs to >> > >> store the security source and destination. We aren't sure if the >> > >> eid ref list of the encapsulated block should be appended to the >> > >> eid ref list of the encapsulating block. The RFC states that an >> > >> Abstract Security Block should have at most 2 eid references, and >> > >> this would contradict that statement. >> > >> >> > >> We get around this problem with PCB because the first PCB block's >> > >> eid ref list stores the security source and destination, and an >> > >> extra PCB block is added for any encapsulated blocks (and this >> > >> extra PCB block contains the eid ref list of the encapsulated >> > >> block). With ESB, there is a one-to-one correspondence between the >> > >> 'replacing' ESB block and the block to be encapsulated, so we do >> > >> not have an extra block as in PCB. >> > > >> > > Did you have a solution in mind? Since I'm at the IETF meeting I >> > > won't have time this week to look into it, sorry. If you bug me next >> > > week, I >> > > will:-) >> > > >> > > S. >> > > >> > > >> > >> >> > >> >> > >> >> > >> thanks, >> > >> Angela >> > >> >> > >> >> > >> Angela Hennessy >> > >> Laboratory for Telecommunication Sciences (LTS) >> > >> >> > >> >> > > >> > >> > _______________________________________________ >> > dtn-security mailing list >> > dtn-security@irtf.org >> > https://www.irtf.org/mailman/listinfo/dtn-security >> _______________________________________________ >> dtn-security mailing list >> dtn-security@irtf.org >> https://www.irtf.org/mailman/listinfo/dtn-security > From plovell@mac.com Thu Aug 2 14:40:26 2012 Return-Path: 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 B519A21F8976 for ; Thu, 2 Aug 2012 14:40:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_63=0.6, RCVD_IN_DNSWL_LOW=-1] 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 5WQZrAWXV2nz for ; Thu, 2 Aug 2012 14:40:25 -0700 (PDT) Received: from st11p00mm-asmtpout004.mac.com (st11p00mm-asmtpout004.mac.com [17.172.81.3]) by ietfa.amsl.com (Postfix) with ESMTP id B072A21F856D for ; Thu, 2 Aug 2012 14:40:25 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from [192.168.1.98] (pool-96-255-127-40.washdc.fios.verizon.net [96.255.127.40]) by st11p00mm-asmtp004.mac.com (Oracle Communications Messaging Server 7u4-23.01(7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTPSA id <0M8500LHODJ5M340@st11p00mm-asmtp004.mac.com> for dtn-security@irtf.org; Thu, 02 Aug 2012 21:40:19 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.7.7855,1.0.260,0.0.0000 definitions=2012-08-02_08:2012-08-02, 2012-08-02, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1203120001 definitions=main-1208020258 From: Peter Lovell To: ahennes1@math.umd.edu, dtn-security@irtf.org, Stephen Farrell Date: Thu, 02 Aug 2012 17:40:16 -0400 Message-id: <20120802214016.1861780438@smtp.mail.me.com> X-Mailer: CTM PowerMail version 6.1.1b2 build 4649 English (intel) 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 21:40:26 -0000 re-send for list members as my origib=nal one bounced :( I guess I need to revise my addresses On Thu, Aug 2, 2012, ahennes1@math.umd.edu wrote: >We've run into a problem while implementing the security source and >destination in the ESB blocks. When ESB encapsulates a block, the BSP RFC >states that the eid ref list of the encapsulated block should be used as >the eid ref list of the encapsulating block, as in PCB. However, the eid >ref list of the encapsulating block also needs to store the security >source and destination. We aren't sure if the eid ref list of the >encapsulated block should be appended to the eid ref list of the >encapsulating block. The RFC states that an Abstract Security Block >should have at most 2 eid references, and this would contradict that >statement. > >We get around this problem with PCB because the first PCB block's eid ref >list stores the security source and destination, and an extra PCB block is >added for any encapsulated blocks (and this extra PCB block contains the >eid ref list of the encapsulated block). With ESB, there is a one-to-one >correspondence between the 'replacing' ESB block and the block to be >encapsulated, so we do not have an extra block as in PCB. > > > >thanks, >Angela > > >Angela Hennessy >Laboratory for Telecommunication Sciences (LTS) Hi Angela, you're right - this is an issue that is not addressed in the spec. Some of the ESB language was taken from that for PCB, which it closely resembles, but this is an edge case not foreseen. There can be only two EIDs in the list because there are only two flags to indicate their presence. The list is not length-counted for total size so one can't skip over it. However, an EID list is specific to security blocks and doesn't occur in other block types. ESBs and other security blocks are in separate spaces, i.e. an ESB must never encapsulate PIBs or PCBs, and vice-versa. So the issue you describe can only occur in the super-encapsulation of ESBs. For now, I'm not sure how best to deal with it, but my initial thought is to use the previous EID list as the starting EID list, and then push security-source and security-dest on the front, if needed and as appropriate. The problem is how to indicate that there are other EIDs because, if we do not, the processing of the block will fail. This will require some change to the header and that will be a slow and deliberate process. In the meantime, let me suggest that you encapsulate the block and reconstitute it at the security-dest without special EID processing. THat means that any EID-munging between source and dest will be ineffective but I suspect that it isn't common anyway [please correct me if that's wrong]. The alternative is to avoid super-encryption of ESBs. Regards.....Peter From edward.birrane@jhuapl.edu Thu Aug 2 16:10:46 2012 Return-Path: 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 415F211E81C8 for ; Thu, 2 Aug 2012 16:10:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_63=0.6, RCVD_IN_DNSWL_MED=-4] 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 h17ZjKLfMuiK for ; Thu, 2 Aug 2012 16:10:45 -0700 (PDT) Received: from jhuapl.edu (pilot.jhuapl.edu [128.244.251.36]) by ietfa.amsl.com (Postfix) with ESMTP id 218BC11E81C6 for ; Thu, 2 Aug 2012 16:10:44 -0700 (PDT) Received: from ([128.244.198.91]) by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.149720996; Thu, 02 Aug 2012 19:10:38 -0400 Received: from aplesfreedom.dom1.jhuapl.edu ([128.244.198.204]) by aplexcas2.dom1.jhuapl.edu ([128.244.198.91]) with mapi; Thu, 2 Aug 2012 19:10:38 -0400 From: "Birrane, Edward J." To: Peter Lovell , "ahennes1@math.umd.edu" , "dtn-security@irtf.org" , Stephen Farrell Date: Thu, 2 Aug 2012 19:10:37 -0400 Thread-Topic: [dtn-security] Issue implementing security source/destination with ESB blocks Thread-Index: Ac1w93L+Imtuv+xqQfGQwP1/pjKCoAAA7cFA Message-ID: <329D879C76FDD04AAAE84BB1D89B397006842FE1C2@aplesfreedom.dom1.jhuapl.edu> References: <20120802214016.1861780438@smtp.mail.me.com> In-Reply-To: <20120802214016.1861780438@smtp.mail.me.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 23:10:46 -0000 Peter, > However, an EID list is specific to security blocks and doesn't occur i= n other block types. Non-security extension blocks may have EID references and RFC6257 has lang= uage that associates non-security-block EID references to security-block EI= D references. So, if I have a non-security extension block with 10 EID references in it= , what happens when I try to encapsulate it in an ESB?=20 If the ESB EID Reference list does *not* represent those 10 EIDs, they co= uld be deleted from the dictionary (see RFC5050 Section 4.7 "Dictionary Rev= ision"). That would cause some pain when we unpack the extension block at = the security destination. -Ed --- Ed Birrane Senior Professional Staff, Space Department Johns Hopkins Applied Physics Laboratory (W) 443-778-7423 / (F) 443-228-3839 =20 > -----Original Message----- > From: dtn-security-bounces@irtf.org [mailto:dtn-security-bounces@irtf.org= ] > On Behalf Of Peter Lovell > Sent: Thursday, August 02, 2012 5:40 PM > To: ahennes1@math.umd.edu; dtn-security@irtf.org; Stephen Farrell > Subject: Re: [dtn-security] Issue implementing security source/destinatio= n > with ESB blocks >=20 > re-send for list members as my origib=3Dnal one bounced :( I guess I need= to > revise my addresses >=20 > On Thu, Aug 2, 2012, ahennes1@math.umd.edu > wrote: >=20 > >We've run into a problem while implementing the security source and > >destination in the ESB blocks. When ESB encapsulates a block, the BSP > >RFC states that the eid ref list of the encapsulated block should be > >used as the eid ref list of the encapsulating block, as in PCB. > >However, the eid ref list of the encapsulating block also needs to > >store the security source and destination. We aren't sure if the eid > >ref list of the encapsulated block should be appended to the eid ref > >list of the encapsulating block. The RFC states that an Abstract > >Security Block should have at most 2 eid references, and this would > >contradict that statement. > > > >We get around this problem with PCB because the first PCB block's eid > >ref list stores the security source and destination, and an extra PCB > >block is added for any encapsulated blocks (and this extra PCB block > >contains the eid ref list of the encapsulated block). With ESB, there > >is a one-to-one correspondence between the 'replacing' ESB block and > >the block to be encapsulated, so we do not have an extra block as in PCB= . > > > > > > > >thanks, > >Angela > > > > > >Angela Hennessy > >Laboratory for Telecommunication Sciences (LTS) >=20 >=20 > Hi Angela, >=20 > you're right - this is an issue that is not addressed in the spec. Some o= f the > ESB language was taken from that for PCB, which it closely resembles, but > this is an edge case not foreseen. >=20 > There can be only two EIDs in the list because there are only two flags t= o > indicate their presence. The list is not length-counted for total size so= one > can't skip over it. >=20 > However, an EID list is specific to security blocks and doesn't occur in = other > block types. >=20 > ESBs and other security blocks are in separate spaces, i.e. an ESB must n= ever > encapsulate PIBs or PCBs, and vice-versa. >=20 > So the issue you describe can only occur in the super-encapsulation of ES= Bs. > For now, I'm not sure how best to deal with it, but my initial thought is= to use > the previous EID list as the starting EID list, and then push security-so= urce and > security-dest on the front, if needed and as appropriate. The problem is = how > to indicate that there are other EIDs because, if we do not, the processi= ng of > the block will fail. This will require some change to the header and that= will be > a slow and deliberate process. >=20 > In the meantime, let me suggest that you encapsulate the block and > reconstitute it at the security-dest without special EID processing. THat > means that any EID-munging between source and dest will be ineffective bu= t > I suspect that it isn't common anyway [please correct me if that's wrong]= . >=20 > The alternative is to avoid super-encryption of ESBs. >=20 > Regards.....Peter >=20 >=20 >=20 > _______________________________________________ > dtn-security mailing list > dtn-security@irtf.org > https://www.irtf.org/mailman/listinfo/dtn-security From elwynd@folly.org.uk Thu Aug 2 19:45:19 2012 Return-Path: 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 DF43C11E80A4 for ; Thu, 2 Aug 2012 19:45:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_63=0.6] 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 93+m-z6UDfh6 for ; Thu, 2 Aug 2012 19:45:19 -0700 (PDT) Received: from b.painless.aa.net.uk (b.painless.aa.net.uk [IPv6:2001:8b0:0:30::51bb:1e34]) by ietfa.amsl.com (Postfix) with ESMTP id 15D0711E8072 for ; Thu, 2 Aug 2012 19:45:19 -0700 (PDT) Received: from [210.11.95.209] (helo=[192.168.173.65]) by b.painless.aa.net.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1Sx7t2-00051z-66; Fri, 03 Aug 2012 03:45:12 +0100 Message-ID: <501B3B2F.5090508@folly.org.uk> Date: Fri, 03 Aug 2012 12:45:03 +1000 From: Elwyn Davies User-Agent: Mozilla/5.0 (X11; Linux i686; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Peter Lovell References: <20120802214016.1861780438@smtp.mail.me.com> In-Reply-To: <20120802214016.1861780438@smtp.mail.me.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dtn-security@irtf.org, ahennes1@math.umd.edu 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 Reply-To: elwynd@folly.org.uk List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Security." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 02:45:20 -0000 Hi. Comment in line below... On 03/08/12 07:40, Peter Lovell wrote: > re-send for list members as my origib=nal one bounced :( > I guess I need to revise my addresses > > On Thu, Aug 2, 2012, ahennes1@math.umd.edu wrote: > >> We've run into a problem while implementing the security source and >> destination in the ESB blocks. When ESB encapsulates a block, the BSP RFC >> states that the eid ref list of the encapsulated block should be used as >> the eid ref list of the encapsulating block, as in PCB. However, the eid >> ref list of the encapsulating block also needs to store the security >> source and destination. We aren't sure if the eid ref list of the >> encapsulated block should be appended to the eid ref list of the >> encapsulating block. The RFC states that an Abstract Security Block >> should have at most 2 eid references, and this would contradict that >> statement. >> >> We get around this problem with PCB because the first PCB block's eid ref >> list stores the security source and destination, and an extra PCB block is >> added for any encapsulated blocks (and this extra PCB block contains the >> eid ref list of the encapsulated block). With ESB, there is a one-to-one >> correspondence between the 'replacing' ESB block and the block to be >> encapsulated, so we do not have an extra block as in PCB. >> >> >> >> thanks, >> Angela >> >> >> Angela Hennessy >> Laboratory for Telecommunication Sciences (LTS) > > Hi Angela, > > you're right - this is an issue that is not addressed in the spec. Some of the ESB language was taken from that for PCB, which it closely resembles, but this is an edge case not foreseen. > > There can be only two EIDs in the list because there are only two flags to indicate their presence. The list is not length-counted for total size so one can't skip over it. > > However, an EID list is specific to security blocks and doesn't occur in other block types. > > ESBs and other security blocks are in separate spaces, i.e. an ESB must never encapsulate PIBs or PCBs, and vice-versa. > > So the issue you describe can only occur in the super-encapsulation of ESBs. For now, I'm not sure how best to deal with it, but my initial thought is to use the previous EID list as the starting EID list, and then push security-source and security-dest on the front, if needed and as appropriate. The problem is how to indicate that there are other EIDs because, if we do not, the processing of the block will fail. This will require some change to the header and that will be a slow and deliberate process. But not that difficult since the flag fields are SDNVs - so adding extra flags will not break the ASB definition. Regards, Elwyn > > In the meantime, let me suggest that you encapsulate the block and reconstitute it at the security-dest without special EID processing. THat means that any EID-munging between source and dest will be ineffective but I suspect that it isn't common anyway [please correct me if that's wrong]. > > The alternative is to avoid super-encryption of ESBs. > > Regards.....Peter > > > > _______________________________________________ > dtn-security mailing list > dtn-security@irtf.org > https://www.irtf.org/mailman/listinfo/dtn-security From edward.birrane@jhuapl.edu Fri Aug 3 13:13:30 2012 Return-Path: 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 0136221F8DEE for ; Fri, 3 Aug 2012 13:13:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.199 X-Spam-Level: X-Spam-Status: No, score=-6.199 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_63=0.6, RCVD_IN_DNSWL_MED=-4] 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 1CRcG3ooZBD3 for ; Fri, 3 Aug 2012 13:13:29 -0700 (PDT) Received: from jhuapl.edu (piper.jhuapl.edu [128.244.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id F27E821F8DEC for ; Fri, 3 Aug 2012 13:13:28 -0700 (PDT) Received: from ([128.244.198.91]) by piper.jhuapl.edu with ESMTP with TLS id 5Y8HCH1.141767261; Fri, 03 Aug 2012 16:07:07 -0400 Received: from aplesfreedom.dom1.jhuapl.edu ([128.244.198.204]) by aplexcas2.dom1.jhuapl.edu ([128.244.198.91]) with mapi; Fri, 3 Aug 2012 16:07:07 -0400 From: "Birrane, Edward J." To: "elwynd@folly.org.uk" , Peter Lovell Date: Fri, 3 Aug 2012 16:07:07 -0400 Thread-Topic: [dtn-security] Issue implementing security source/destination with ESB blocks Thread-Index: Ac1xIgrOv62pyZX5Q86gUzjckYf6EwAkRvAw Message-ID: <329D879C76FDD04AAAE84BB1D89B397006842FE3A0@aplesfreedom.dom1.jhuapl.edu> References: <20120802214016.1861780438@smtp.mail.me.com> <501B3B2F.5090508@folly.org.uk> In-Reply-To: <501B3B2F.5090508@folly.org.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dtn-security@irtf.org" , "ahennes1@math.umd.edu" 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 20:13:30 -0000 Angela and I had some off-line e-mails to synchronize on our understanding = of the issue. I believe the following capture the needed behavior for ESBs= : 1. The EID reference list of an ESB *must* be the union of all EID referen= ces of all blocks encapsulated by the ESB. 2. Because the EID reference list has variable size, we must place a count= in front. (a-la RFC5050 canonical spec) 3. We may add a secsrc and secdst to the encapsulating EID reference list = IFF they are available and not already represented in the EID list 4. The EID ref count (added in #2 above) can therefore be increased by a m= ax. value of 2 on each encapsulation. 5. At a security destination, any EIDs added from #3 above to the encapsul= ating EID list must be removed and any changes made in-situ to the encapsul= ating EID list must be propagated back to the encapsulated EID list. 6. Ciphersuite parameters in the ESB give some level of disposition as to = the what/how of the security source and security destination in the encapsu= lating EID list. The mechanism for this is TBD. Are there any disagreements with any of the above? -Ed --- Ed Birrane Senior Professional Staff, Space Department Johns Hopkins Applied Physics Laboratory (W) 443-778-7423 / (F) 443-228-3839 =20 > -----Original Message----- > From: dtn-security-bounces@irtf.org [mailto:dtn-security-bounces@irtf.org= ] > On Behalf Of Elwyn Davies > Sent: Thursday, August 02, 2012 10:45 PM > To: Peter Lovell > Cc: dtn-security@irtf.org; ahennes1@math.umd.edu > Subject: Re: [dtn-security] Issue implementing security source/destinatio= n > with ESB blocks >=20 > Hi. >=20 > Comment in line below... >=20 > On 03/08/12 07:40, Peter Lovell wrote: > > re-send for list members as my origib=3Dnal one bounced :( I guess I > > need to revise my addresses > > > > On Thu, Aug 2, 2012, > ahennes1@math.umd.edu wrote: > > > >> We've run into a problem while implementing the security source and > >> destination in the ESB blocks. When ESB encapsulates a block, the > >> BSP RFC states that the eid ref list of the encapsulated block should > >> be used as the eid ref list of the encapsulating block, as in PCB. > >> However, the eid ref list of the encapsulating block also needs to > >> store the security source and destination. We aren't sure if the eid > >> ref list of the encapsulated block should be appended to the eid ref > >> list of the encapsulating block. The RFC states that an Abstract > >> Security Block should have at most 2 eid references, and this would > >> contradict that statement. > >> > >> We get around this problem with PCB because the first PCB block's eid > >> ref list stores the security source and destination, and an extra PCB > >> block is added for any encapsulated blocks (and this extra PCB block > >> contains the eid ref list of the encapsulated block). With ESB, > >> there is a one-to-one correspondence between the 'replacing' ESB > >> block and the block to be encapsulated, so we do not have an extra blo= ck > as in PCB. > >> > >> > >> > >> thanks, > >> Angela > >> > >> > >> Angela Hennessy > >> Laboratory for Telecommunication Sciences (LTS) > > > > Hi Angela, > > > > you're right - this is an issue that is not addressed in the spec. Some= of the > ESB language was taken from that for PCB, which it closely resembles, but > this is an edge case not foreseen. > > > > There can be only two EIDs in the list because there are only two flags= to > indicate their presence. The list is not length-counted for total size so= one > can't skip over it. > > > > However, an EID list is specific to security blocks and doesn't occur i= n other > block types. > > > > ESBs and other security blocks are in separate spaces, i.e. an ESB must > never encapsulate PIBs or PCBs, and vice-versa. > > > > So the issue you describe can only occur in the super-encapsulation of > ESBs. For now, I'm not sure how best to deal with it, but my initial thou= ght is > to use the previous EID list as the starting EID list, and then push secu= rity- > source and security-dest on the front, if needed and as appropriate. The > problem is how to indicate that there are other EIDs because, if we do no= t, > the processing of the block will fail. This will require some change to t= he > header and that will be a slow and deliberate process. > But not that difficult since the flag fields are SDNVs - so adding extra = flags will > not break the ASB definition. >=20 > Regards, > Elwyn > > > > In the meantime, let me suggest that you encapsulate the block and > reconstitute it at the security-dest without special EID processing. THat > means that any EID-munging between source and dest will be ineffective bu= t > I suspect that it isn't common anyway [please correct me if that's wrong]= . > > > > The alternative is to avoid super-encryption of ESBs. > > > > Regards.....Peter > > > > > > > > _______________________________________________ > > dtn-security mailing list > > dtn-security@irtf.org > > https://www.irtf.org/mailman/listinfo/dtn-security >=20 > _______________________________________________ > dtn-security mailing list > dtn-security@irtf.org > https://www.irtf.org/mailman/listinfo/dtn-security From plovell@mac.com Fri Aug 3 15:17:07 2012 Return-Path: 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 8329721E8034 for ; Fri, 3 Aug 2012 15:17:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_63=0.6, RCVD_IN_DNSWL_LOW=-1] 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 TR+muBNnG8kV for ; Fri, 3 Aug 2012 15:17:06 -0700 (PDT) Received: from st11p00mm-asmtpout002.mac.com (st11p00mm-asmtpout002.mac.com [17.172.81.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F87821F8DE3 for ; Fri, 3 Aug 2012 15:17:05 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from [192.168.1.98] (pool-96-255-127-40.washdc.fios.verizon.net [96.255.127.40]) by st11p00mm-asmtp002.mac.com (Oracle Communications Messaging Exchange Server 7u4-22.01 64bit (built Apr 21 2011)) with ESMTPSA id <0M8700J2V9WD6320@st11p00mm-asmtp002.mac.com> for dtn-security@irtf.org; Fri, 03 Aug 2012 22:17:05 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.7.7855,1.0.260,0.0.0000 definitions=2012-08-03_04:2012-08-03, 2012-08-03, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1203120001 definitions=main-1208030265 From: Peter Lovell To: "Birrane, Edward J." , Elwyn Davies Date: Fri, 03 Aug 2012 18:17:01 -0400 Message-id: <20120803221701.223057816@smtp.mail.me.com> In-reply-to: <329D879C76FDD04AAAE84BB1D89B397006842FE3A0@aplesfreedom.dom1.jhuapl.edu> References: <20120802214016.1861780438@smtp.mail.me.com> <501B3B2F.5090508@folly.org.uk> <329D879C76FDD04AAAE84BB1D89B397006842FE3A0@aplesfreedom.dom1.jhuapl.edu> X-Mailer: CTM PowerMail version 6.1.1b2 build 4649 English (intel) Cc: dtn-security@irtf.org, ahennes1@math.umd.edu Subject: [dtn-security] Re(2): 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 22:17:07 -0000 Hi all, Ed is is quite correct that non-security blocks can have an EID list. I'd been looking too closely at RFC6257 and not at 5050. And as I was checking today I noticed an omission in 6257. Do we have an errata list for it? If not, we need one. The omission is in Section 2.1 describing EID-references. It does not mention that the EID-refs are preceded by a count field, although it does rather cryptically say that "a count field of zero is not permitted". Lao, in the discussion that follows, it says that there can be two EIDs at most, which is incorrect. These errors probably came about because the EID-reference-list things were developed mostly with the BSP discussion rather than the design of the Bundle Protocol, and when we changed it for inclusion in BP, I didn't edit BSP hard enough. Now, back to the main issue at hand. Ciphersuite PC3 does use the notion of carrying forward an existing EID-list, and adding one or two new EID-refs to the front of the list. I'm rusty on this code - not have dealt with it for several years - but it seems to me that the sec-src and sec-dest EIDs would be added at the end of the list rather than the front, and that obviously needs correcting. The code in "validate" seems to decrypt and reconstitute the encapsulated block correctly. As you mention, an encapsulated block wouldn't have either of these which is why it never showed up before. The general scheme is ... 1. create an empty working block 2. copy necessary things from the existing block into the new one, especially the EID list 3. if there's a security-dest, push it on the front of the list 4. if there's a security-src, push it on the front of the list 5. get keys etc and encrypt the entire original block, encapsulating it in the security-result field of the new block 6. replace the existing block with the working copy (care needed here with locals as things such as block-type may have changed) At the receiving end, the process is a reverse of the sending one, in general ... 7. create an empty working block 8. process the incoming block info, extract keys and decrypt the block 9. assemble the new block from the pieces in the decrypted block 10. in particular, you have to get the EID list of the incoming block and step over EIDs for security-src and/or security-dest, if present. Then you copy the rest of the list (count plus EID-refs) from the incoming block onto the EID-list in the working block. Conceptually, this is popping them off the front of the list and copying the remainder. 11. copy the rest of the block, and update locals as necessary for block-type change etc The PC3 code does most of this so it should serve as a reasonable guide, with the correction I mentioned. Regards.....Peter On Fri, Aug 3, 2012, Birrane, Edward J. wrote: >Angela and I had some off-line e-mails to synchronize on our >understanding of the issue. I believe the following capture the needed >behavior for ESBs: > > 1. The EID reference list of an ESB *must* be the union of all EID >references of all blocks encapsulated by the ESB. > > 2. Because the EID reference list has variable size, we must place a >count in front. (a-la RFC5050 canonical spec) > > 3. We may add a secsrc and secdst to the encapsulating EID reference >list IFF they are available and not already represented in the EID list > > 4. The EID ref count (added in #2 above) can therefore be increased by >a max. value of 2 on each encapsulation. > > 5. At a security destination, any EIDs added from #3 above to the >encapsulating EID list must be removed and any changes made in-situ to >the encapsulating EID list must be propagated back to the encapsulated >EID list. > > 6. Ciphersuite parameters in the ESB give some level of disposition as >to the what/how of the security source and security destination in the >encapsulating EID list. The mechanism for this is TBD. > >Are there any disagreements with any of the above? > >-Ed > >--- >Ed Birrane >Senior Professional Staff, Space Department >Johns Hopkins Applied Physics Laboratory >(W) 443-778-7423 / (F) 443-228-3839 > > >> -----Original Message----- >> From: dtn-security-bounces@irtf.org [mailto:dtn-security-bounces@irtf.org] >> On Behalf Of Elwyn Davies >> Sent: Thursday, August 02, 2012 10:45 PM >> To: Peter Lovell >> Cc: dtn-security@irtf.org; ahennes1@math.umd.edu >> Subject: Re: [dtn-security] Issue implementing security source/destination >> with ESB blocks >> >> Hi. >> >> Comment in line below... >> >> On 03/08/12 07:40, Peter Lovell wrote: >> > re-send for list members as my origib=nal one bounced :( I guess I >> > need to revise my addresses >> > >> > On Thu, Aug 2, 2012, >> ahennes1@math.umd.edu wrote: >> > >> >> We've run into a problem while implementing the security source and >> >> destination in the ESB blocks. When ESB encapsulates a block, the >> >> BSP RFC states that the eid ref list of the encapsulated block should >> >> be used as the eid ref list of the encapsulating block, as in PCB. >> >> However, the eid ref list of the encapsulating block also needs to >> >> store the security source and destination. We aren't sure if the eid >> >> ref list of the encapsulated block should be appended to the eid ref >> >> list of the encapsulating block. The RFC states that an Abstract >> >> Security Block should have at most 2 eid references, and this would >> >> contradict that statement. >> >> >> >> We get around this problem with PCB because the first PCB block's eid >> >> ref list stores the security source and destination, and an extra PCB >> >> block is added for any encapsulated blocks (and this extra PCB block >> >> contains the eid ref list of the encapsulated block). With ESB, >> >> there is a one-to-one correspondence between the 'replacing' ESB >> >> block and the block to be encapsulated, so we do not have an extra block >> as in PCB. >> >> >> >> >> >> >> >> thanks, >> >> Angela >> >> >> >> >> >> Angela Hennessy >> >> Laboratory for Telecommunication Sciences (LTS) >> > >> > Hi Angela, >> > >> > you're right - this is an issue that is not addressed in the spec. >Some of the >> ESB language was taken from that for PCB, which it closely resembles, but >> this is an edge case not foreseen. >> > >> > There can be only two EIDs in the list because there are only two flags to >> indicate their presence. The list is not length-counted for total size >so one >> can't skip over it. >> > >> > However, an EID list is specific to security blocks and doesn't >occur in other >> block types. >> > >> > ESBs and other security blocks are in separate spaces, i.e. an ESB must >> never encapsulate PIBs or PCBs, and vice-versa. >> > >> > So the issue you describe can only occur in the super-encapsulation of >> ESBs. For now, I'm not sure how best to deal with it, but my initial >thought is >> to use the previous EID list as the starting EID list, and then push >security- >> source and security-dest on the front, if needed and as appropriate. The >> problem is how to indicate that there are other EIDs because, if we do not, >> the processing of the block will fail. This will require some change to the >> header and that will be a slow and deliberate process. >> But not that difficult since the flag fields are SDNVs - so adding >extra flags will >> not break the ASB definition. >> >> Regards, >> Elwyn >> > >> > In the meantime, let me suggest that you encapsulate the block and >> reconstitute it at the security-dest without special EID processing. THat >> means that any EID-munging between source and dest will be ineffective but >> I suspect that it isn't common anyway [please correct me if that's wrong]. >> > >> > The alternative is to avoid super-encryption of ESBs. >> > >> > Regards.....Peter >> > >> > >> > >> > _______________________________________________ >> > dtn-security mailing list >> > dtn-security@irtf.org >> > https://www.irtf.org/mailman/listinfo/dtn-security >> >> _______________________________________________ >> dtn-security mailing list >> dtn-security@irtf.org >> https://www.irtf.org/mailman/listinfo/dtn-security From ahennes1@math.umd.edu Mon Aug 6 08:51:20 2012 Return-Path: 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 91D0721F85B8 for ; Mon, 6 Aug 2012 08:51:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] 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 VBI7cZ6oA-dt for ; Mon, 6 Aug 2012 08:51:20 -0700 (PDT) Received: from mailfilter.ece.umd.edu (mailfilter.ece.umd.edu [129.2.90.4]) by ietfa.amsl.com (Postfix) with ESMTP id 123BB21F85C4 for ; Mon, 6 Aug 2012 08:51:19 -0700 (PDT) X-ASG-Debug-ID: 1344268277-04739d104d3eb800001-NoPDhg Received: from svr4.math.umd.edu (svr4.math.umd.edu [129.2.56.14]) by mailfilter.ece.umd.edu with ESMTP id uQKp41Tgvqp1ZMoz; Mon, 06 Aug 2012 11:51:17 -0400 (EDT) X-Barracuda-Envelope-From: ahennes1@math.umd.edu X-Barracuda-Apparent-Source-IP: 129.2.56.14 Received: by svr4.math.umd.edu (Postfix, from userid 48) id 086EE6FC83; Mon, 6 Aug 2012 11:51:17 -0400 (EDT) Received: from 63.239.65.11 by webmail.math.umd.edu with HTTP; Mon, 6 Aug 2012 11:51:17 -0400 Message-ID: In-Reply-To: <20120803221701.223057816@smtp.mail.me.com> References: <20120802214016.1861780438@smtp.mail.me.com> <501B3B2F.5090508@folly.org.uk> <329D879C76FDD04AAAE84BB1D89B397006842FE3A0@aplesfreedom.dom1.jhuapl.edu> <20120803221701.223057816@smtp.mail.me.com> Date: Mon, 6 Aug 2012 11:51:17 -0400 From: ahennes1@math.umd.edu X-ASG-Orig-Subj: Re: [dtn-security] Issue implementing security source/destination with ESB blocks To: "Peter Lovell" , aloomis@sarn.org, cherita.corbett@jhuapl.edu, stephen.farrell@cs.tcd.ie User-Agent: SquirrelMail/1.4.20 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Barracuda-Connect: svr4.math.umd.edu[129.2.56.14] X-Barracuda-Start-Time: 1344268277 X-Barracuda-URL: http://mailfilter.ece.umd.edu:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at ece.umd.edu X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=7.0 KILL_LEVEL=1000.0 tests=NO_REAL_NAME X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.104863 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 NO_REAL_NAME From: does not include a real name Cc: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2012 15:51:20 -0000 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 From plovell@mac.com Mon Aug 6 09:20:13 2012 Return-Path: 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 7016E21F8615 for ; Mon, 6 Aug 2012 09:20:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 1qlknkPPNsY4 for ; Mon, 6 Aug 2012 09:20:12 -0700 (PDT) Received: from st11p00mm-asmtpout002.mac.com (st11p00mm-asmtp002.mac.com [17.172.81.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E96921F860B for ; Mon, 6 Aug 2012 09:20:12 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from [192.168.76.196] (static-96-244-17-67.bltmmd.fios.verizon.net [96.244.17.67]) by st11p00mm-asmtp002.mac.com (Oracle Communications Messaging Exchange Server 7u4-22.01 64bit (built Apr 21 2011)) with ESMTPSA id <0M8C00ESWDDKRP40@st11p00mm-asmtp002.mac.com> for dtn-security@irtf.org; Mon, 06 Aug 2012 16:20:11 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.7.7855,1.0.260,0.0.0000 definitions=2012-08-06_04:2012-08-06, 2012-08-06, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1203120001 definitions=main-1208060161 From: Peter Lovell To: ahennes1@math.umd.edu, aloomis@sarn.org, cherita.corbett@jhuapl.edu, Stephen Farrell Date: Mon, 06 Aug 2012 12:20:08 -0400 Message-id: <20120806162008.1123881582@smtp.mail.me.com> In-reply-to: References: <20120802214016.1861780438@smtp.mail.me.com> <501B3B2F.5090508@folly.org.uk> <329D879C76FDD04AAAE84BB1D89B397006842FE3A0@aplesfreedom.dom1.jhuapl.edu> <20120803221701.223057816@smtp.mail.me.com> X-Mailer: CTM PowerMail version 6.1.1 build 4649 English (intel) Cc: dtn-security@irtf.org Subject: [dtn-security] Re(2): 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2012 16:20:13 -0000 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 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 > From ahennes1@math.umd.edu Mon Aug 6 13:12:44 2012 Return-Path: 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 1ECE721E8048 for ; Mon, 6 Aug 2012 13:12:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.166 X-Spam-Level: X-Spam-Status: No, score=-6.166 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 21gqFa3CxEDO for ; Mon, 6 Aug 2012 13:12:43 -0700 (PDT) Received: from mailfilter.ece.umd.edu (mailfilter.ece.umd.edu [129.2.90.4]) by ietfa.amsl.com (Postfix) with ESMTP id 2B95C11E808A for ; Mon, 6 Aug 2012 13:12:43 -0700 (PDT) X-ASG-Debug-ID: 1344283961-04739d104c3ff300001-NoPDhg Received: from svr4.math.umd.edu ([129.2.56.14]) by mailfilter.ece.umd.edu with ESMTP id PxUR2DCMZwEWTiuX; Mon, 06 Aug 2012 16:12:41 -0400 (EDT) X-Barracuda-Envelope-From: ahennes1@math.umd.edu X-Barracuda-Apparent-Source-IP: 129.2.56.14 Received: by svr4.math.umd.edu (Postfix, from userid 48) id 557816FC83; Mon, 6 Aug 2012 16:12:41 -0400 (EDT) Received: from 65.127.220.136 by webmail.math.umd.edu with HTTP; Mon, 6 Aug 2012 16:12:41 -0400 Message-ID: In-Reply-To: <20120806162008.1123881582@smtp.mail.me.com> References: <20120802214016.1861780438@smtp.mail.me.com> <501B3B2F.5090508@folly.org.uk> <329D879C76FDD04AAAE84BB1D89B397006842FE3A0@aplesfreedom.dom1.jhuapl.edu> <20120803221701.223057816@smtp.mail.me.com> <20120806162008.1123881582@smtp.mail.me.com> Date: Mon, 6 Aug 2012 16:12:41 -0400 From: ahennes1@math.umd.edu X-ASG-Orig-Subj: Re: Re(2): [dtn-security] Issue implementing security source/destination with ESB blocks To: "Peter Lovell" User-Agent: SquirrelMail/1.4.20 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Barracuda-Connect: UNKNOWN[129.2.56.14] X-Barracuda-Start-Time: 1344283961 X-Barracuda-URL: http://mailfilter.ece.umd.edu:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at ece.umd.edu X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=7.0 KILL_LEVEL=1000.0 tests=BSF_SC0_MISMATCH_TO, NO_REAL_NAME X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.104881 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 NO_REAL_NAME From: does not include a real name 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header Cc: dtn-security@irtf.org Subject: Re: [dtn-security] Re(2): 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2012 20:12:44 -0000 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 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 >> > > From dtnbsp@gmail.com Thu Aug 2 14:36:53 2012 Return-Path: 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 8FB3121F8A1A for ; Thu, 2 Aug 2012 14:36:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] 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 TtWoubioNx3L for ; Thu, 2 Aug 2012 14:36:53 -0700 (PDT) Received: from mail-qc0-f182.google.com (mail-qc0-f182.google.com [209.85.216.182]) by ietfa.amsl.com (Postfix) with ESMTP id F0ED521F8A19 for ; Thu, 2 Aug 2012 14:36:52 -0700 (PDT) Received: by qcsg15 with SMTP id g15so4098qcs.13 for ; Thu, 02 Aug 2012 14:36:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:date:message-id:in-reply-to:references:x-mailer :mime-version:content-type:content-transfer-encoding; bh=m37qIU82MoOvg2DxEpbkk49wpoAJ7C0+p4h0cgMBYno=; b=UQHsUf6lNit53XT/lb6DJK7K5GWEro4ogAxM5SvzeUkEj+dj0UBXJW9H1GMUfpPY7M 6aoPVwN+ejDr73hyqZY8+s6pv+QJbgl5olyeMRJHTR1fyXZlT7l/QHPzGg/qbhhfc3VC BhbULNHKpkuwlPmjThJJu/ikLoROZKL/jAMB4V+oh+ybLYAqqCU2qCnuRMK3qAFevAn6 rKTOFAIOrL5yBOqeRx2z86m6qIGdwmMrp7Dw3IBF+kDuWd58HosXcaTqXAiVDGhms0LI QnDB6BfcivfUbGgSGlgReJlpeyBaGKbkpIXhUCRGL1HQzRyVoij+cn87zzBW0lwdK8kd tfFA== Received: by 10.229.137.148 with SMTP id w20mr11779390qct.155.1343943412354; Thu, 02 Aug 2012 14:36:52 -0700 (PDT) Received: from [192.168.1.98] (pool-96-255-127-40.washdc.fios.verizon.net. [96.255.127.40]) by mx.google.com with ESMTPS id dr6sm5855924qab.16.2012.08.02.14.36.49 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 02 Aug 2012 14:36:51 -0700 (PDT) From: "Peter Lovell" To: , , "Stephen Farrell" Date: Thu, 2 Aug 2012 17:36:48 -0400 Message-Id: <20120802213648.1651877815@smtp.gmail.com> In-Reply-To: <38cc307b4972055558f2e38b0293db0c.squirrel@webmail.math.umd.edu> References: <38cc307b4972055558f2e38b0293db0c.squirrel@webmail.math.umd.edu> X-Mailer: CTM PowerMail version 6.1.1b2 build 4649 English (intel) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Mon, 06 Aug 2012 16:48:45 -0700 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 21:36:53 -0000 On Thu, Aug 2, 2012, ahennes1@math.umd.edu wrote: >We've run into a problem while implementing the security source and >destination in the ESB blocks. When ESB encapsulates a block, the BSP RFC >states that the eid ref list of the encapsulated block should be used as >the eid ref list of the encapsulating block, as in PCB. However, the eid >ref list of the encapsulating block also needs to store the security >source and destination. We aren't sure if the eid ref list of the >encapsulated block should be appended to the eid ref list of the >encapsulating block. The RFC states that an Abstract Security Block >should have at most 2 eid references, and this would contradict that >statement. > >We get around this problem with PCB because the first PCB block's eid ref >list stores the security source and destination, and an extra PCB block is >added for any encapsulated blocks (and this extra PCB block contains the >eid ref list of the encapsulated block). With ESB, there is a one-to-one >correspondence between the 'replacing' ESB block and the block to be >encapsulated, so we do not have an extra block as in PCB. > > > >thanks, >Angela > > >Angela Hennessy >Laboratory for Telecommunication Sciences (LTS) Hi Angela, you're right - this is an issue that is not addressed in the spec. Some of = the ESB language was taken from that for PCB, which it closely resembles, = but this is an edge case not foreseen. There can be only two EIDs in the list because there are only two flags to = indicate their presence. The list is not length-counted for total size so = one can't skip over it. However, an EID list is specific to security blocks and doesn't occur in = other block types. ESBs and other security blocks are in separate spaces, i.e. an ESB must = never encapsulate PIBs or PCBs, and vice-versa. So the issue you describe can only occur in the super-encapsulation of = ESBs. For now, I'm not sure how best to deal with it, but my initial thought is = to use the previous EID list as the starting EID list, and then push = security-source and security-dest on the front, if needed and as appropriate. The = problem is how to indicate that there are other EIDs because, if we do not, the = processing of the block will fail. This will require some change to the = header and that will be a slow and deliberate process. In the meantime, let me suggest that you encapsulate the block and = reconstitute it at the security-dest without special EID processing. THat means that = any EID-munging between source and dest will be ineffective but I suspect = that it isn't common anyway [please correct me if that's wrong]. The alternative is to avoid super-encryption of ESBs. Regards.....Peter From plovell@mac.com Tue Aug 7 09:13:08 2012 Return-Path: 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 3739821F8734 for ; Tue, 7 Aug 2012 09:13:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 uZO7gtrV4Eha for ; Tue, 7 Aug 2012 09:13:07 -0700 (PDT) Received: from st11p00mm-asmtpout003.mac.com (st11p00mm-asmtpout003.mac.com [17.172.81.2]) by ietfa.amsl.com (Postfix) with ESMTP id 30A6921F8652 for ; Tue, 7 Aug 2012 09:13:06 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from [192.168.76.196] (static-96-244-17-67.bltmmd.fios.verizon.net [96.244.17.67]) by st11p00mm-asmtp003.mac.com (Oracle Communications Messaging Server 7u4-23.01(7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTPSA id <0M8E00ERW7PROK40@st11p00mm-asmtp003.mac.com> for dtn-security@irtf.org; Tue, 07 Aug 2012 16:13:06 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.7.7855,1.0.260,0.0.0000 definitions=2012-08-07_04:2012-08-07, 2012-08-07, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=1 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1203120001 definitions=main-1208070153 From: Peter Lovell To: ahennes1@math.umd.edu Date: Tue, 07 Aug 2012 12:13:03 -0400 Message-id: <20120807161303.1666733293@smtp.mail.me.com> In-reply-to: References: <20120802214016.1861780438@smtp.mail.me.com> <501B3B2F.5090508@folly.org.uk> <329D879C76FDD04AAAE84BB1D89B397006842FE3A0@aplesfreedom.dom1.jhuapl.edu> <20120803221701.223057816@smtp.mail.me.com> <20120806162008.1123881582@smtp.mail.me.com> X-Mailer: CTM PowerMail version 6.1.3 build 4650 English (intel) Cc: dtn-security@irtf.org Subject: [dtn-security] Re(4): 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2012 16:13:08 -0000 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 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 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 >>> >> >> > From stephen.farrell@cs.tcd.ie Tue Aug 7 09:26:55 2012 Return-Path: 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 B766A11E8087 for ; Tue, 7 Aug 2012 09:26:55 -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 KQV+eErJ2WyQ for ; Tue, 7 Aug 2012 09:26:54 -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 19B5311E8072 for ; Tue, 7 Aug 2012 09:26:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 7C75B17150A; Tue, 7 Aug 2012 17:26:53 +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=1344356813; bh=btVhjLe5mL7p0y yGY1vgNet7nex+2t24sJ0FX/z43d8=; b=lvFBuhK/NbVvXjTc/nWQTrzC/GGOZf QvsG40nSu9cNWvk4/AiP8Befoh+HKc8hcsVv4wP/fTLnxFSa80hpKRw96HjtLYaF ETW0CLgslL++24GJHKd59y5ojW9uk7AQPo7alsgakDooFT0YFBBZg4BApdWsYAps 5MUQ93ZOnQ3vk/p38TlzaNgLrPiIheKy0Zff0JBdhH+Qn2UrzXpmYLXz3wWo5lTz JQrEbGEIqjBo5Ew9jzV1bMf03ySldXOAXKN/qCMZ3eJYXefyIg1CdlUNZiywomhZ Qvx7Zrh9bYVJUF+osr7elEJ17fGXEH2TRqRMHqiWqZCTQnCkhrY4mLRQ== 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 U5NJKpCMAbsI; Tue, 7 Aug 2012 17:26:53 +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 CF255171509; Tue, 7 Aug 2012 17:26:46 +0100 (IST) Message-ID: <502141C6.8030804@cs.tcd.ie> Date: Tue, 07 Aug 2012 17:26:46 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: Peter Lovell References: <20120802214016.1861780438@smtp.mail.me.com> <501B3B2F.5090508@folly.org.uk> <329D879C76FDD04AAAE84BB1D89B397006842FE3A0@aplesfreedom.dom1.jhuapl.edu> <20120803221701.223057816@smtp.mail.me.com> <20120806162008.1123881582@smtp.mail.me.com> <20120807161303.1666733293@smtp.mail.me.com> In-Reply-To: <20120807161303.1666733293@smtp.mail.me.com> X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: ahennes1@math.umd.edu, 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2012 16:26:55 -0000 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 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 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 >>>> >>> >>> >> > > > > From plovell@mac.com Tue Aug 7 09:28:44 2012 Return-Path: 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 5E0B311E809A for ; Tue, 7 Aug 2012 09:28:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[AWL=1.500, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 1CMjyqTXMgJm for ; Tue, 7 Aug 2012 09:28:43 -0700 (PDT) Received: from nk11p99mm-asmtpout007.mac.com (nk11p99mm-asmtpout007.mac.com [17.158.233.228]) by ietfa.amsl.com (Postfix) with ESMTP id 460A711E8087 for ; Tue, 7 Aug 2012 09:28:43 -0700 (PDT) MIME-version: 1.0 Content-type: text/plain; charset=windows-1252 Received: from [192.168.76.196] (static-96-244-17-67.bltmmd.fios.verizon.net [96.244.17.67]) by nk11p03mm-asmtp997.mac.com (Oracle Communications Messaging Server 7u4-24.01(7.0.4.24.0) 64bit (built Jan 3 2012)) with ESMTPSA id <0M8E00JCT8FSHWA0@nk11p03mm-asmtp997.mac.com> for dtn-security@irtf.org; Tue, 07 Aug 2012 16:28:42 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.7.7855,1.0.260,0.0.0000 definitions=2012-08-07_04:2012-08-07, 2012-08-07, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1203120001 definitions=main-1208070157 From: Peter Lovell In-reply-to: <502141C6.8030804@cs.tcd.ie> Date: Tue, 07 Aug 2012 12:28:39 -0400 Content-transfer-encoding: quoted-printable Message-id: <2E6CABBD-4D93-4829-B6ED-3720313439C0@mac.com> References: <20120802214016.1861780438@smtp.mail.me.com> <501B3B2F.5090508@folly.org.uk> <329D879C76FDD04AAAE84BB1D89B397006842FE3A0@aplesfreedom.dom1.jhuapl.edu> <20120803221701.223057816@smtp.mail.me.com> <20120806162008.1123881582@smtp.mail.me.com> <20120807161303.1666733293@smtp.mail.me.com> <502141C6.8030804@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.1485) Cc: ahennes1@math.umd.edu, 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2012 16:28:44 -0000 Sounds like a plan =85 Cheers=85..Peter On Aug 7, 2012, at 12:26 PM, Stephen Farrell = wrote: >=20 > Hi, >=20 > Sorry I've not been reading this since I was running around > madly IETFing last week;-) >=20 > 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. >=20 > Once approved, it'll show up on the tools page for the RFC. > The RG chairs can approve errata like this. >=20 > Cheers, > S. >=20 > On 08/07/2012 05:13 PM, Peter Lovell wrote: >> Hi Angela, >>=20 >> you're correct in that item 2 doesn't apply to PC3. >>=20 >> 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. >>=20 >> I think that the description for PC3 should be quite specific, but = that the general description for PI and PC ciphersuites should be = permissive. >>=20 >> Regards.....Peter >>=20 >> On Tue, Aug 13, 2013, ahennes1@math.umd.edu = wrote: >>=20 >>> Hi Peter, >>>=20 >>> 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): >>>=20 >>> 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. >>>=20 >>> 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. >>>=20 >>>=20 >>> Thanks, >>> Angela >>>=20 >>>=20 >>>=20 >>>=20 >>>> Hi Angela, >>>>=20 >>>> Item 1 is fine >>>>=20 >>>> 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. >>>>=20 >>>> 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. >>>>=20 >>>> Regards.....Peter >>>>=20 >>>>=20 >>>> On Mon, Aug 6, 2012, ahennes1@math.umd.edu = wrote: >>>>=20 >>>>> All, >>>>>=20 >>>>> I'm trying to summarize the issues with RFC6257 for an errata = list. How >>>>> does this sound: >>>>>=20 >>>>> 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. >>>>>=20 >>>>> 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. >>>>>=20 >>>>> 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). >>>>>=20 >>>>> 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). >>>>>=20 >>>>>=20 >>>>> Thanks, >>>>> Angela >>>>>=20 >>>>=20 >>>>=20 >>>=20 >>=20 >>=20 >>=20 >>=20 From edward.birrane@jhuapl.edu Tue Aug 7 09:56:25 2012 Return-Path: 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 E115F21F86C5 for ; Tue, 7 Aug 2012 09:56:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 5bx0STSDb+Sk for ; Tue, 7 Aug 2012 09:56:25 -0700 (PDT) Received: from jhuapl.edu (piper.jhuapl.edu [128.244.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 8E4EF21F8674 for ; Tue, 7 Aug 2012 09:56:24 -0700 (PDT) Received: from ([128.244.198.91]) by piper.jhuapl.edu with ESMTP with TLS id 5Y8HCH1.141990507; Tue, 07 Aug 2012 12:56:16 -0400 Received: from aplesfreedom.dom1.jhuapl.edu ([128.244.198.204]) by aplexcas2.dom1.jhuapl.edu ([128.244.198.91]) with mapi; Tue, 7 Aug 2012 12:56:16 -0400 From: "Birrane, Edward J." To: Peter Lovell , Stephen Farrell Date: Tue, 7 Aug 2012 12:56:15 -0400 Thread-Topic: [dtn-security] Issue implementing security source/destination with ESB blocks Thread-Index: Ac10vPTGRnA81PbySxWPw6J6l2dy3gAABFsA Message-ID: <329D879C76FDD04AAAE84BB1D89B39700689BEEF2B@aplesfreedom.dom1.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> <20120806162008.1123881582@smtp.mail.me.com> <20120807161303.1666733293@smtp.mail.me.com> <502141C6.8030804@cs.tcd.ie> <2E6CABBD-4D93-4829-B6ED-3720313439C0@mac.com> In-Reply-To: <2E6CABBD-4D93-4829-B6ED-3720313439C0@mac.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dtn-security@irtf.org" , "ahennes1@math.umd.edu" 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2012 16:56:26 -0000 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 t= he 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 des= tination in the encapsulating block by prepending them. I would recommend flags and EID-list indices in the ciphersuite parameter= s 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 =20 > -----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/destinatio= n > with ESB blocks >=20 > Sounds like a plan ... >=20 > Cheers.....Peter >=20 > On Aug 7, 2012, at 12:26 PM, Stephen Farrell > wrote: >=20 > > > > 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 on= es. > >> > >> I think that the description for PC3 should be quite specific, but tha= t the > general description for PI and PC ciphersuites should be permissive. > >> > >> Regards.....Peter > >> > >> On Tue, Aug 13, 2013, 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 > 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 ha= s > 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 > >>>>> > >>>> > >>>> > >>> > >> > >> > >> > >> From stephen.farrell@cs.tcd.ie Tue Aug 7 10:36:51 2012 Return-Path: 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 ; 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 ; 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 ; 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 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." References: <20120802214016.1861780438@smtp.mail.me.com> <501B3B2F.5090508@folly.org.uk> <329D879C76FDD04AAAE84BB1D89B397006842FE3A0@aplesfreedom.dom1.jhuapl.edu> <20120803221701.223057816@smtp.mail.me.com> <20120806162008.1123881582@smtp.mail.me.com> <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" , "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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 >> 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 >> 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 >> 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 >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >>>> >>>> > > > From edward.birrane@jhuapl.edu Tue Aug 7 12:03:53 2012 Return-Path: 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 05D4D21F87C7 for ; Tue, 7 Aug 2012 12:03:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.479 X-Spam-Level: X-Spam-Status: No, score=-6.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 1+85krbxu-AP for ; Tue, 7 Aug 2012 12:03:52 -0700 (PDT) Received: from jhuapl.edu (pilot.jhuapl.edu [128.244.251.36]) by ietfa.amsl.com (Postfix) with ESMTP id CDA0521F855E for ; Tue, 7 Aug 2012 12:03:51 -0700 (PDT) Received: from ([128.244.198.90]) by pilot.jhuapl.edu with ESMTP with TLS id 63GHCH1.150052287; Tue, 07 Aug 2012 15:03:42 -0400 Received: from aplesfreedom.dom1.jhuapl.edu ([128.244.198.204]) by aplexcas1.dom1.jhuapl.edu ([128.244.198.90]) with mapi; Tue, 7 Aug 2012 15:03:41 -0400 From: "Birrane, Edward J." To: Stephen Farrell Date: Tue, 7 Aug 2012 15:03:40 -0400 Thread-Topic: [dtn-security] Issue implementing security source/destination with ESB blocks Thread-Index: Ac10wz2OrK6A+WNYQ2eU9VO4nIPMrwAC+J3A Message-ID: <329D879C76FDD04AAAE84BB1D89B39700689BEEFD9@aplesfreedom.dom1.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> <20120806162008.1123881582@smtp.mail.me.com> <20120807161303.1666733293@smtp.mail.me.com> <502141C6.8030804@cs.tcd.ie> <2E6CABBD-4D93-4829-B6ED-3720313439C0@mac.com> <329D879C76FDD04AAAE84BB1D89B39700689BEEF2B@aplesfreedom.dom1.jhuapl.edu> <5021522B.4000309@cs.tcd.ie> In-Reply-To: <5021522B.4000309@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ahennes1@math.umd.edu" , "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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2012 19:03:53 -0000 Sorry, didn't mean to be fussy. But since it is a niche case that I am inte= rested 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 =20 > -----Original Message----- > From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] > Sent: Tuesday, August 07, 2012 1:37 PM > To: Birrane, Edward J. > Cc: Peter Lovell; ahennes1@math.umd.edu; aloomis@sarn.org; Corbett, > Cherita L.; Elwyn Davies; dtn-security@irtf.org > Subject: Re: [dtn-security] Issue implementing security source/destinatio= n > with ESB blocks >=20 >=20 > 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:-) >=20 > Anyway, if Pete/Angela can craft text we can thrash it as needed. >=20 > S >=20 > 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* contai= ns the > security source, security destination, or both (but not at the front of t= he EID- > list) then I recommend we not repeat the security source and/or destinati= on > in the encapsulating block by prepending them. > > > > I would recommend flags and EID-list indices in the ciphersuite param= eters > 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 > >> > >> 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 > >> 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 e= id- > 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 > >> 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 > >>>>>>> > >>>>>> > >>>>>> > >>>>> > >>>> > >>>> > >>>> > >>>> > > > > > >