Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id l1NFWFY12628 for ; Fri, 23 Feb 2007 07:32:16 -0800 Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id l1NFW6hA006532; Fri, 23 Feb 2007 09:32:06 -0600 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.12.11/8.13.1) with ESMTP id l1NFVviS007951; Fri, 23 Feb 2007 09:32:06 -0600 Received: from [157.185.80.152] ([157.185.80.152]) by nemo.columbia.ads.sparta.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 23 Feb 2007 10:31:56 -0500 From: "Peter Lovell" To: "Stephen Farrell" Cc: , "Peter Lovell" Subject: Re: [dtn-security] Detail of PSB change... Date: Fri, 23 Feb 2007 10:31:54 -0500 Message-Id: <20070223153154.1030764384@nemo.columbia.sparta.com> In-Reply-To: <45DEF3D9.50701@cs.tcd.ie> References: <45DEF3D9.50701@cs.tcd.ie> X-Mailer: CTM PowerMail version 5.5.3 build 4480 English (PPC) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Feb 2007 15:31:57.0043 (UTC) FILETIME=[C0BC6430:01C7575F] Sender: dtn-security-admin@mailman.dtnrg.org Errors-To: dtn-security-admin@mailman.dtnrg.org X-BeenThere: dtn-security@mailman.dtnrg.org X-Mailman-Version: 2.0.13 Precedence: bulk Reply-To: dtn-security@mailman.dtnrg.org List-Unsubscribe: , List-Id: DTN Security Discussion List-Post: List-Help: List-Subscribe: , List-Archive: > >In a mail to dtn-interest I said: > > > PS: I'm not saying the current BSP spec has got this correct, it > > probably needs fixing in a few ways. But I do think we can do that > > in the BSP spec and not re-open the BP spec. E.g. perhaps we need > > to add a optional "signature number" to the current PSB ciphersuite, > > with the meaning that this is the n-th signature added or something. > >I just had a maybe-better/maybe-worse idea: > >We could add a "signature layer" value s.t. signatures with layer >N cover all PSBs with layer < N. I think that's cute and maybe >useful, but we'll have to think through the semantics. > >S. Hi Stephen, my thinking had been in that general direction. I hadn't included it in my message as I wanted that to be mainly a description of the problem, and not so much a speculation on possible solutions. Rather than a "signature layer", I might call it a "layer identifier" and apply it to all security blocks. For concreteness, let's think of it as a one-byte field, although there is a scenario where we might need it larger. [note 1] Layers would be conceptually wrapped around the payload block. If you add a new layer, its number is one greater than the largest number you have already. You add the block (conceptually) at the front, just after the primary. [note 2] You can only remove or modify the outermost layer (can be recursive, though). The downside is that the numbers are only on security blocks, so we can only deal with them, plus primary and payload itself, of course. We must ignore all other extension blocks [note 3]. This is the current situation with BSP but we had been hoping to extend coverage to metadata - I'm not sure if we can do that now. Regards.....Peter Note 1: we might need this in the case of adding blocks to fragment- bundles, so we can differentiate between them when it comes time to reassemble the bundle Note 2: If you use a correlated block you add that at the back as the last block. If you have several correlated blocks, they must all conceptually follow the payload. This is a change for Confidentiality suite #3, by the way, but workable. We can order the multiple correlated blocks using the scheme we discussed a couple of days ago. Note 3: for payload security and confidentiality ciphersuites. We can solve the problem for bundle authentication ciphersuites, so all blocks can be included in that digest process. Received: from imx2.tcd.ie (wpad.iss.tcd.ie [134.226.1.156]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id l1NE0nY12051 for ; Fri, 23 Feb 2007 06:00:49 -0800 Received: from Vams.imx2 (imx2.tcd.ie [134.226.1.156]) by imx2.tcd.ie (Postfix) with SMTP id 357D768003 for ; Fri, 23 Feb 2007 14:00:43 +0000 (GMT) Received: from imx2.tcd.ie ([134.226.1.156]) by imx2.tcd.ie ([134.226.1.156]) with SMTP (gateway) id A074BA3240F; Fri, 23 Feb 2007 14:00:43 +0000 Received: from [134.226.174.16] (csc144016.wlan.tcd.ie [134.226.174.16]) by imx2.tcd.ie (Postfix) with ESMTP id 2091768003 for ; Fri, 23 Feb 2007 14:00:43 +0000 (GMT) Message-ID: <45DEF3D9.50701@cs.tcd.ie> Date: Fri, 23 Feb 2007 14:02:01 +0000 From: Stephen Farrell User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: dtn-security@mailman.dtnrg.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiVirus-Status: MessageID = A174BA3240F X-AntiVirus-Status: Host: imx2.tcd.ie X-AntiVirus-Status: Action Taken: X-AntiVirus-Status: NONE X-AntiVirus-Status: Checked by TCD Vexira. (version=1.57.6 VDF=9.62.8) Subject: [dtn-security] Detail of PSB change... Sender: dtn-security-admin@mailman.dtnrg.org Errors-To: dtn-security-admin@mailman.dtnrg.org X-BeenThere: dtn-security@mailman.dtnrg.org X-Mailman-Version: 2.0.13 Precedence: bulk Reply-To: dtn-security@mailman.dtnrg.org List-Unsubscribe: , List-Id: DTN Security Discussion List-Post: List-Help: List-Subscribe: , List-Archive: In a mail to dtn-interest I said: > PS: I'm not saying the current BSP spec has got this correct, it > probably needs fixing in a few ways. But I do think we can do that > in the BSP spec and not re-open the BP spec. E.g. perhaps we need > to add a optional "signature number" to the current PSB ciphersuite, > with the meaning that this is the n-th signature added or something. I just had a maybe-better/maybe-worse idea: We could add a "signature layer" value s.t. signatures with layer N cover all PSBs with layer < N. I think that's cute and maybe useful, but we'll have to think through the semantics. S. Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id l16EfeY29241 for ; Tue, 6 Feb 2007 06:41:40 -0800 Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id l16Efdeo009941; Tue, 6 Feb 2007 08:41:39 -0600 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.12.11/8.13.1) with ESMTP id l16EfcFK026376; Tue, 6 Feb 2007 08:41:39 -0600 Received: from [192.168.4.103] ([157.185.80.253]) by nemo.columbia.ads.sparta.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 Feb 2007 09:41:37 -0500 From: "Peter Lovell" To: , Susan Cc: "Howard Weiss" Subject: Re(2): [dtn-security] BSP questions Date: Tue, 6 Feb 2007 09:41:36 -0500 Message-Id: <20070206144136.143416340@127.0.0.1> In-Reply-To: <8E507634779E22488719233DB3DF9FF0014B1749@IMCSRV4.MITRE.ORG> References: <20070206133129.1301477151@127.0.0.1> <8E507634779E22488719233DB3DF9FF0014B1749@IMCSRV4.MITRE.ORG> X-Mailer: CTM PowerMail version 5.5.3 build 4480 English (PPC) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Feb 2007 14:41:37.0671 (UTC) FILETIME=[E8070970:01C749FC] Sender: dtn-security-admin@mailman.dtnrg.org Errors-To: dtn-security-admin@mailman.dtnrg.org X-BeenThere: dtn-security@mailman.dtnrg.org X-Mailman-Version: 2.0.13 Precedence: bulk Reply-To: dtn-security@mailman.dtnrg.org List-Unsubscribe: , List-Id: DTN Security Discussion List-Post: List-Help: List-Subscribe: , List-Archive: Hi Susan, this is as I expected, and how I have been doing the implementation. I thought I'd check, though, as strictly end-to-end would make a few things easier. Worth a try :) Cheers.....Peter p.s. yes - clarifying text in the spec would be good >I believe that the term "end-to-end" here was intended to mean from >security source to security destination, where the security source is >not necessarily the source of the bundle, and the security destination >is not necessarily the destination of the bundle. This >"end-to-endishness" is described in more detail in the Security >Overview document. An end-to-end ciphersuite is distinguished from a >"hop-by-hop" ciphersuite by the fact that the hop-by-hop ciphersuite is >only intended to be used between adjacent nodes and never across >multiple nodes. > >To avoid others having the same question as you, it seems we should add >some clarifying text to explain this, because the BSP is normative >whereas the Security Overview is not. > >-susan >***************************************************************** >Susan Symington >The MITRE Corporation >susan@mitre.org >703-983-7209 (voice) >703-983-7142 (fax) >****************************************************************** > > >>-----Original Message----- >>From: dtn-security-admin@mailman.dtnrg.org >>[mailto:dtn-security-admin@mailman.dtnrg.org] On Behalf Of Peter >Lovell >>Sent: Tuesday, February 06, 2007 8:31 AM >>To: dtn-security@mailman.dtnrg.org >>Cc: Howard Weiss >>Subject: [dtn-security] BSP questions >> >>a question arising from doing the implementation ... >> >>Bundle security spec 2.3 description for PS includes the statement >>"The ciphersuite ID MUST be documented as an end-to-end >authentication- >>ciphersuite or as an end-to-end error-detection-ciphersuite." >> >>Is it the intent that PS is only ever end-to-end? It can never be >added >>at intermediate points such as a bastion gateway. Gateway-to-gateway >>would be done using encapsulation (tunneling), so the gateway would be >>the source for the encapsulated bundle. If this is the intent then >>several other issues no longer exist. >> >>Thanks.....Peter >> Received: from smtp-bedford.mitre.org (smtpproxy1.mitre.org [192.160.51.76]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id l16EXDY29172 for ; Tue, 6 Feb 2007 06:33:13 -0800 Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.12.11.20060308/8.12.11) with SMTP id l16EXD3P007564 for ; Tue, 6 Feb 2007 09:33:13 -0500 Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (Postfix) with ESMTP id 1D258BF00 for ; Tue, 6 Feb 2007 09:33:13 -0500 (EST) Received: from IMCFE1.MITRE.ORG (imcfe1.mitre.org [129.83.29.3]) by smtp-bedford.mitre.org (8.12.11.20060308/8.12.11) with ESMTP id l16EXA96007511; Tue, 6 Feb 2007 09:33:10 -0500 Received: from IMCSRV4.MITRE.ORG ([129.83.20.161]) by IMCFE1.MITRE.ORG with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 Feb 2007 09:33:10 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: [dtn-security] BSP questions Date: Tue, 6 Feb 2007 09:33:09 -0500 Message-ID: <8E507634779E22488719233DB3DF9FF0014B1749@IMCSRV4.MITRE.ORG> In-Reply-To: <20070206133129.1301477151@127.0.0.1> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dtn-security] BSP questions thread-index: AcdJ81KBiy8/9+mPRo2uIw6LwaM7BAAB100Q References: <20070206133129.1301477151@127.0.0.1> From: "Symington, Susan F." To: Cc: "Howard Weiss" X-OriginalArrivalTime: 06 Feb 2007 14:33:10.0555 (UTC) FILETIME=[B9C346B0:01C749FB] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by webbie.berkeley.intel-research.net id l16EXDY29172 Sender: dtn-security-admin@mailman.dtnrg.org Errors-To: dtn-security-admin@mailman.dtnrg.org X-BeenThere: dtn-security@mailman.dtnrg.org X-Mailman-Version: 2.0.13 Precedence: bulk Reply-To: dtn-security@mailman.dtnrg.org List-Unsubscribe: , List-Id: DTN Security Discussion List-Post: List-Help: List-Subscribe: , List-Archive: I believe that the term "end-to-end" here was intended to mean from security source to security destination, where the security source is not necessarily the source of the bundle, and the security destination is not necessarily the destination of the bundle. This "end-to-endishness" is described in more detail in the Security Overview document. An end-to-end ciphersuite is distinguished from a "hop-by-hop" ciphersuite by the fact that the hop-by-hop ciphersuite is only intended to be used between adjacent nodes and never across multiple nodes. To avoid others having the same question as you, it seems we should add some clarifying text to explain this, because the BSP is normative whereas the Security Overview is not. -susan ***************************************************************** Susan Symington The MITRE Corporation susan@mitre.org 703-983-7209 (voice) 703-983-7142 (fax) ****************************************************************** >-----Original Message----- >From: dtn-security-admin@mailman.dtnrg.org >[mailto:dtn-security-admin@mailman.dtnrg.org] On Behalf Of Peter Lovell >Sent: Tuesday, February 06, 2007 8:31 AM >To: dtn-security@mailman.dtnrg.org >Cc: Howard Weiss >Subject: [dtn-security] BSP questions > >a question arising from doing the implementation ... > >Bundle security spec 2.3 description for PS includes the statement >"The ciphersuite ID MUST be documented as an end-to-end authentication- >ciphersuite or as an end-to-end error-detection-ciphersuite." > >Is it the intent that PS is only ever end-to-end? It can never be added >at intermediate points such as a bastion gateway. Gateway-to-gateway >would be done using encapsulation (tunneling), so the gateway would be >the source for the encapsulated bundle. If this is the intent then >several other issues no longer exist. > >Thanks.....Peter > >_______________________________________________ >dtn-security mailing list >dtn-security@mailman.dtnrg.org >http://mailman.dtnrg.org/mailman/listinfo/dtn-security > Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id l16DwbY28902 for ; Tue, 6 Feb 2007 05:58:37 -0800 Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id l16DwaqA007148 for ; Tue, 6 Feb 2007 07:58:36 -0600 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.12.11/8.13.1) with ESMTP id l16Dwa1h022614 for ; Tue, 6 Feb 2007 07:58:36 -0600 Received: from [192.168.4.103] ([157.185.80.253]) by nemo.columbia.ads.sparta.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 Feb 2007 08:58:35 -0500 From: "Peter Lovell" To: Cc: "Howard Weiss" Date: Tue, 6 Feb 2007 08:58:34 -0500 Message-Id: <20070206135834.1834794457@127.0.0.1> X-Mailer: CTM PowerMail version 5.5.3 build 4480 English (PPC) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Feb 2007 13:58:35.0673 (UTC) FILETIME=[E5096890:01C749F6] Subject: [dtn-security] more BSP questions Sender: dtn-security-admin@mailman.dtnrg.org Errors-To: dtn-security-admin@mailman.dtnrg.org X-BeenThere: dtn-security@mailman.dtnrg.org X-Mailman-Version: 2.0.13 Precedence: bulk Reply-To: dtn-security@mailman.dtnrg.org List-Unsubscribe: , List-Id: DTN Security Discussion List-Post: List-Help: List-Subscribe: , List-Archive: Hi all, are there any suggestions on what we should use for the key-derivation- function (KDF) mentioned near the end of section 4.3 of security spec? Paragraph 4 of the section says that there may be an optional key identifier in the security parameters. If there is, does the security result still contain the encrypted key? Or should this paragraph say that we have one or the other, but not both? Finally, I don't see any specification of key size for AES. I assume that we therefore should infer that from the key provided. Is this the intent? Thanks.....Peter Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id l16DVXY28653 for ; Tue, 6 Feb 2007 05:31:33 -0800 Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id l16DVWeZ005876 for ; Tue, 6 Feb 2007 07:31:32 -0600 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.12.11/8.13.1) with ESMTP id l16DVWUS020613 for ; Tue, 6 Feb 2007 07:31:32 -0600 Received: from [192.168.4.109] ([157.185.80.253]) by nemo.columbia.ads.sparta.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 Feb 2007 08:31:31 -0500 From: "Peter Lovell" To: Cc: "Howard Weiss" Date: Tue, 6 Feb 2007 08:31:29 -0500 Message-Id: <20070206133129.1301477151@127.0.0.1> X-Mailer: CTM PowerMail version 5.5 build 4456 English (intel) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Feb 2007 13:31:31.0850 (UTC) FILETIME=[1D29AEA0:01C749F3] Subject: [dtn-security] BSP questions Sender: dtn-security-admin@mailman.dtnrg.org Errors-To: dtn-security-admin@mailman.dtnrg.org X-BeenThere: dtn-security@mailman.dtnrg.org X-Mailman-Version: 2.0.13 Precedence: bulk Reply-To: dtn-security@mailman.dtnrg.org List-Unsubscribe: , List-Id: DTN Security Discussion List-Post: List-Help: List-Subscribe: , List-Archive: a question arising from doing the implementation ... Bundle security spec 2.3 description for PS includes the statement "The ciphersuite ID MUST be documented as an end-to-end authentication- ciphersuite or as an end-to-end error-detection-ciphersuite." Is it the intent that PS is only ever end-to-end? It can never be added at intermediate points such as a bastion gateway. Gateway-to-gateway would be done using encapsulation (tunneling), so the gateway would be the source for the encapsulated bundle. If this is the intent then several other issues no longer exist. Thanks.....Peter