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 kAIHb9Y28287 for ; Sat, 18 Nov 2006 09:37:09 -0800 Received: from Vams.imx2 (imx2.tcd.ie [134.226.1.156]) by imx2.tcd.ie (Postfix) with SMTP id 9D3A7682F6; Sat, 18 Nov 2006 17:37:03 +0000 (GMT) Received: from imx2.tcd.ie ([134.226.1.156]) by imx2.tcd.ie ([134.226.1.156]) with SMTP (gateway) id A0483B9068F; Sat, 18 Nov 2006 17:37:03 +0000 Received: from [127.0.0.1] (csvpn.cs.tcd.ie [134.226.52.36]) by imx2.tcd.ie (Postfix) with ESMTP id 3D41A682F6; Sat, 18 Nov 2006 17:37:03 +0000 (GMT) Message-ID: <455F44F5.8050808@cs.tcd.ie> Date: Sat, 18 Nov 2006 17:37:57 +0000 From: Stephen Farrell User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Peter Lovell Cc: Susan , Howard Weiss , dtn-security@mailman.dtnrg.org References: <455DABC2.6050200@cs.tcd.ie> <8E507634779E22488719233DB3DF9FF0012296F0@IMCSRV4.MITRE.ORG> <20061118042320.974753071@127.0.0.1> In-Reply-To: <20061118042320.974753071@127.0.0.1> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiVirus-Status: MessageID = A1483B9068F 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.56.3 VDF=8.1402) Subject: [dtn-security] Re: Bundle Security Protocol: one more item 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: Pete, Those are really broader that the security spec. You should raise these issues on dtn-interest/dtn-dev and see what consensus emerges there. (And quickly would be good since we want to finish the BP spec asap.) S. Peter Lovell wrote: > Hi Susan, > >> Now that I think about it, there may be more to consider with regard to >> how this bit works in relation to the security blocks. It is all bound >> up in the issue of how security works if some nodes don't support it. >> >> Suppose for example there are nodes 1, 2, and 3 and only nodes 1 and 3 >> implement the Bundle Security Protocol. This means that if node 1 >> inserts a BAB and forwards the bundle to node 2, and node 2 doesn't >> understand the BAB and isn't configured to delete the BAB or delete the >> bundle, then node 2 will forward the bundle to node 3 with this "block >> was forwarde without being processed" bit set in the BAB. When node 3 >> receives the bundle and tries to authenticate the security result in >> the BAB, it won't authenticate (because of this bit change). This may >> be okay for the BAB, but it would work the same for the PSH and I'm not >> sure that's okay. >> >> If node 1 is a PSH-source, node 2 doesn't understand the PSH and node 3 >> is a PSH-dest, then if node 2 forwards the bundle with this bit set in >> the PSH, then I think we either have to specify that this bit must be >> reset by a node before the node validates the security result in the >> PSH or that this bit must be masked out so that it is omitted from the >> mutable canonicalization form of the bundle. (same for CH I think.) >> >> Assuming this is true, does anyone have a preference for whether we >> should mandate that nodes processing the PSH reset this bit before >> calculating the security result or whether we should just leave this >> bit out of the mutable canoncial form? >> >> Any other thoughts? > > in fact, yes :) Two of them. > > ----- > > First is that we need to better define what "processing" is. I mentioned > this the other day in a somewhat different context (intermediate > validation) but it certainly is a big issue here. > > Do the various block-processors define what processing is, and what is > meant by "success" and "failure", or are these topics for the bundle spec? > > And when the bit can be turned on here and off there and on again in yet > a third place, what real meaning does it have?? > > With regard to processing, what does it mean, for example, for a PS > block if the current node is not the security destination? Does that > change if the current node does in fact have sufficient information to > verify the payload? If it does and the verification fails, does the > current node still forward the bad bundle? > > Another example is to think of what it means to receive a bundle but not > have the extension necessary to interpret it, and then to receive a > bundle with a security block and have that block fail the validation > check. The latter is clearly a "failure" but what about the former? It's > not a success but is it a failure? If we mark it as "could not be > processed" then might other nodes interpret that to mean it really failed. > > I'm sure we can't specify "processing" in particular detail but we > should define how it is specified, and the various limits. > > ----- > > My second issue is less closely related to your original question. The > bundle spec at present refers to extensions but doesn't define them, > which is OK. But there are problems which arise because, as you > describe, a bundle may be processed differently at various nodes. Your > 1-2-3 example in the second paragraph above is a good example. > > I believe that the base bundle specification should contain a certain > minimum requirement with regard to extension blocks in order that > predictable processing can happen. For example, the bundle specification > describes extension blocks but does not specify that block types 2, 3 > and 4 are used by and reserved for the security protocol. So an > implementation could define its own set of 2,3 and 4 and still be > conformant with the bundle protocol. What a mess that would be. > > We need the base specification to require that extensions are > implemented in accord with the appropriate specification. The extensions > are optional and you can omit them and be in conformance, but you can't > be in conformance if your implementation + extensions violates the > various specifications. So, you don't have to do them, but you can't do > them differently. > > Especially in the case of security, we might provide a small description > in the base spec which defines 2, 3 and 4 and specifies what a non- > security implementation should do if it encounters blocks of those > types. I suggest that this specify that 2 [BA] be discarded and 3 and 4 > [PS and C] be forwarded unchanged for someone else to deal with. This > might override the "discard" flag setting, or might not. That's an open > question, and should be decided and specified [there are good arguments > for and against]. > > ----- > > > Regards.....Peter > > 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 kAIGnFY27967 for ; Sat, 18 Nov 2006 08:49:15 -0800 Received: from Vams.imx2 (imx2.tcd.ie [134.226.1.156]) by imx2.tcd.ie (Postfix) with SMTP id 99277680D4; Sat, 18 Nov 2006 16:49:08 +0000 (GMT) Received: from imx2.tcd.ie ([134.226.1.156]) by imx2.tcd.ie ([134.226.1.156]) with SMTP (gateway) id A039808DE1C; Sat, 18 Nov 2006 16:49:08 +0000 Received: from [127.0.0.1] (csvpn.cs.tcd.ie [134.226.52.36]) by imx2.tcd.ie (Postfix) with ESMTP id 12A07680D4; Sat, 18 Nov 2006 16:49:08 +0000 (GMT) Message-ID: <455F39B9.9080106@cs.tcd.ie> Date: Sat, 18 Nov 2006 16:50:01 +0000 From: Stephen Farrell User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: "Symington, Susan F." Cc: Howard Weiss , Peter Lovell , dtn-security@mailman.dtnrg.org References: <8E507634779E22488719233DB3DF9FF001228E04@IMCSRV4.MITRE.ORG> In-Reply-To: <8E507634779E22488719233DB3DF9FF001228E04@IMCSRV4.MITRE.ORG> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiVirus-Status: MessageID = A139808DE1C 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.56.3 VDF=8.1401) Subject: [dtn-security] Re: Bundle Security Protocol items for discussion 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: Susan, A bit late but I want to come back to a bit of this. Symington, Susan F. wrote: > Stephen and Howie, > > The following are Items we need to discuss wrt the bundle security > protocol that were brought up by BBN: > > 1. If a bundle includes a previous hop insertion block (defined in its > own internet draft) with an EID-only or EID-with-Timestamp-formatted > information record, then this means that the bundle already includes the > EID of its previous hop (in its dictionary), with pointers to this > previous hop EID (in its previous-hop insertion block). In this case, it > would be redundant to include the EID of the previous hop in the > security-source field of the BAB. Therefore, I propose that we no longer > make inclusion of the security-source field mandatory in the BAB. It > should be optional. If the security-source field is not present, > however, and the EID of the previous hop cannot be inferred from some > other part of the bundle, then processing of the BAB shall fail. The > proposed text would say, "If the forwarder of the bundle is not > identified in any other blocks of the bundle (e.g. the optional > Previous-hop insertion block), then the security-source field MUST be > present and MUST identify the forwarder of the bundle." I don't think that works. If the BAB doesn't include the source but the next hop doesn't support the other block that has the info, then the BAB check will probably fail. I could accept something like the source SHOULD NOT be omitted unless the node "knows" the BAB needn't contain it (due to it being elsewhere in the block or from lower layer information or whatever). A better way is to say that the BAB SHOULD contain the source. > 2. Under the "Notes" section of 3.2.2, it says, "URI encoding will be a > cause for errors if any node rewrites the dectionary...we simple hae to > live with this problem". BBN wonders why we can't just put in a > statement like, "A node SHOULD NOT change the encoding of any URI in the > dictionary field (elg. changing the DNS part of some HTTP URL from lower > case to upper case)." I don't understand the problem sufficiently be > able to respond on this. The problem is that this usually happens transparently when the bundle is synched to disk using s/w 'A' and then read from disk and forwarded by s/w 'B' and they do different things with upper/lower case (or things like "%20" vs " " etc). So, no harm to say this, but its probably an unavoidable source of integrity failures. If we can provide some test vectors that'd help - can we Pete? > 3. In section 3.4, Bundles received from other nodes, 5th paragraph, it > says that "...the node MUST decrypt the relevant parts of the bundle > according to the ciphersuite specification and delete the CH in > question." BBN wants to know what to do if decryption fails. I propose > we add a sentence here that says, "If the relevant parts of the bundle > cannot be decrypted (i.e., the decription key cannot be deduced or > decryption fails), the behavior of the bundle protocol agent will be as > specified in the CB Block Processing Flags, unless overridden by the > local security policy." Is this okay with you? Sure. (What's the CB Block Processing Flags say?) > 4. If the CH-RSA-AES-PAYLOAD-PSH ciphersuite is used, the first CH must > have a ciphersuite parameter that contains a 16-byte IV, optionally > followed by a key identifier. Is it true that the way we tell whether or > not there is only an IV versus an IV followed by a key ID is by the > length specified in the ciphersuite parameters SDNV? If this SDNV shows > the ciphersuite parameters field to be 16 bytes long, then we know only > an IV is included. If this SDNV shows the ciphersuite parameters field > to be longer than 16 bytes, then we know that both an IV and a key ID is > included, and the length of the key ID is the length shown in the SDNV > minus 16 bytes. Is this correct? If so, BBN was unsure of it so we > should probably explicitly say this in the spec. All correct. Good to spell it out (as long as we don't use too many words:-) > 5. To be sure I am correct, in the CH-RSA-AES-PAYLOAD-PSH ciphersuite > definition, the input to the KDF is the BEK catenated wtih the IV from > the ciphersuite parameter of the first CH, right? (BBN was unclear on > whether there is a single IV in the first CH or whether each CH includes > an IV). It is my understanding that there is a single IV in the first > CH. Subsequent CHs do not contain any of the optional fields (such as > ciphersuite parameters) that are included in the first CH. Is my > understanding correct? Think so. Would be happy to change this kind of stuff for either implementation reasons or because someone's security analysis shows a reason. (And I'd also still like to start using a counter mode.) 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 kAI4NUY23335 for ; Fri, 17 Nov 2006 20:23:30 -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 kAI4NRLQ013549; Fri, 17 Nov 2006 22:23:27 -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 kAI4NQvh007060; Fri, 17 Nov 2006 22:23:27 -0600 Received: from [192.168.4.109] ([157.185.80.253]) by nemo.columbia.ads.sparta.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Nov 2006 23:23:26 -0500 From: "Peter Lovell" To: Susan , "Stephen Farrell" Cc: "Howard Weiss" , Date: Fri, 17 Nov 2006 23:23:20 -0500 Message-Id: <20061118042320.974753071@127.0.0.1> In-Reply-To: <8E507634779E22488719233DB3DF9FF0012296F0@IMCSRV4.MITRE.ORG> References: <455DABC2.6050200@cs.tcd.ie> <8E507634779E22488719233DB3DF9FF0012296F0@IMCSRV4.MITRE.ORG> 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: 18 Nov 2006 04:23:26.0284 (UTC) FILETIME=[4ACA88C0:01C70AC9] Subject: [dtn-security] Re(2): Bundle Security Protocol: one more item 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, >Now that I think about it, there may be more to consider with regard to >how this bit works in relation to the security blocks. It is all bound >up in the issue of how security works if some nodes don't support it. > >Suppose for example there are nodes 1, 2, and 3 and only nodes 1 and 3 >implement the Bundle Security Protocol. This means that if node 1 >inserts a BAB and forwards the bundle to node 2, and node 2 doesn't >understand the BAB and isn't configured to delete the BAB or delete the >bundle, then node 2 will forward the bundle to node 3 with this "block >was forwarde without being processed" bit set in the BAB. When node 3 >receives the bundle and tries to authenticate the security result in >the BAB, it won't authenticate (because of this bit change). This may >be okay for the BAB, but it would work the same for the PSH and I'm not >sure that's okay. > >If node 1 is a PSH-source, node 2 doesn't understand the PSH and node 3 >is a PSH-dest, then if node 2 forwards the bundle with this bit set in >the PSH, then I think we either have to specify that this bit must be >reset by a node before the node validates the security result in the >PSH or that this bit must be masked out so that it is omitted from the >mutable canonicalization form of the bundle. (same for CH I think.) > >Assuming this is true, does anyone have a preference for whether we >should mandate that nodes processing the PSH reset this bit before >calculating the security result or whether we should just leave this >bit out of the mutable canoncial form? > >Any other thoughts? in fact, yes :) Two of them. ----- First is that we need to better define what "processing" is. I mentioned this the other day in a somewhat different context (intermediate validation) but it certainly is a big issue here. Do the various block-processors define what processing is, and what is meant by "success" and "failure", or are these topics for the bundle spec? And when the bit can be turned on here and off there and on again in yet a third place, what real meaning does it have?? With regard to processing, what does it mean, for example, for a PS block if the current node is not the security destination? Does that change if the current node does in fact have sufficient information to verify the payload? If it does and the verification fails, does the current node still forward the bad bundle? Another example is to think of what it means to receive a bundle but not have the extension necessary to interpret it, and then to receive a bundle with a security block and have that block fail the validation check. The latter is clearly a "failure" but what about the former? It's not a success but is it a failure? If we mark it as "could not be processed" then might other nodes interpret that to mean it really failed. I'm sure we can't specify "processing" in particular detail but we should define how it is specified, and the various limits. ----- My second issue is less closely related to your original question. The bundle spec at present refers to extensions but doesn't define them, which is OK. But there are problems which arise because, as you describe, a bundle may be processed differently at various nodes. Your 1-2-3 example in the second paragraph above is a good example. I believe that the base bundle specification should contain a certain minimum requirement with regard to extension blocks in order that predictable processing can happen. For example, the bundle specification describes extension blocks but does not specify that block types 2, 3 and 4 are used by and reserved for the security protocol. So an implementation could define its own set of 2,3 and 4 and still be conformant with the bundle protocol. What a mess that would be. We need the base specification to require that extensions are implemented in accord with the appropriate specification. The extensions are optional and you can omit them and be in conformance, but you can't be in conformance if your implementation + extensions violates the various specifications. So, you don't have to do them, but you can't do them differently. Especially in the case of security, we might provide a small description in the base spec which defines 2, 3 and 4 and specifies what a non- security implementation should do if it encounters blocks of those types. I suggest that this specify that 2 [BA] be discarded and 3 and 4 [PS and C] be forwarded unchanged for someone else to deal with. This might override the "discard" flag setting, or might not. That's an open question, and should be decided and specified [there are good arguments for and against]. ----- Regards.....Peter Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [192.160.51.76]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id kAHKPvY20318 for ; Fri, 17 Nov 2006 12:25:57 -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 kAHKPv25020788 for ; Fri, 17 Nov 2006 15:25:57 -0500 Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (Postfix) with ESMTP id 0CA21BEFB for ; Fri, 17 Nov 2006 15:25:57 -0500 (EST) Received: from imcfe2.MITRE.ORG (imcfe2.mitre.org [129.83.29.4]) by smtp-bedford.mitre.org (8.12.11.20060308/8.12.11) with ESMTP id kAHKPuan020765; Fri, 17 Nov 2006 15:25:56 -0500 Received: from IMCSRV4.MITRE.ORG ([129.83.20.161]) by imcfe2.MITRE.ORG with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Nov 2006 15:25:56 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C70A86.9585752C" Date: Fri, 17 Nov 2006 15:25:54 -0500 Message-ID: <8E507634779E22488719233DB3DF9FF001229817@IMCSRV4.MITRE.ORG> In-Reply-To: <8E507634779E22488719233DB3DF9FF001228E04@IMCSRV4.MITRE.ORG> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Bundle Security Protocol items for discussion Thread-Index: AccHY8fyBEqx0jp0SPmXlBJ124qKsADIS4Fw From: "Symington, Susan F." To: "Symington, Susan F." , "Stephen Farrell" , "Howard Weiss" , "Peter Lovell" Cc: X-OriginalArrivalTime: 17 Nov 2006 20:25:56.0090 (UTC) FILETIME=[95F1DDA0:01C70A86] Subject: [dtn-security] RE: Bundle Security Protocol items for discussion 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: This is a multi-part message in MIME format. ------_=_NextPart_001_01C70A86.9585752C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Security authors and pundits, =20 Thanks for your input in the past few days. It is helping to improve the spec. =20 As far as I can tell, below are the only remaining items that we need to resolve before we can wrap up this next revision of the Bundle Security Protocol. I would appreciate receiving your input on these issues. Once I roll in whatever revisions these generate, I will circulate version 3 of the Bundle Security Protocol for your review. =20 Thanks. =20 -susan =20 ***************************************************************** Susan Symington The MITRE Corporation susan@mitre.org 703-983-7209 (voice) 703-983-7142 (fax) ****************************************************************** =20 ________________________________ From: Symington, Susan F.=20 Sent: Monday, November 13, 2006 3:39 PM To: Stephen Farrell; 'Howard Weiss' Cc: Symington, Susan F. Subject: Bundle Security Protocol items for discussion =09 =09 Stephen and Howie, =20 The following are Items we need to discuss wrt the bundle security protocol that were brought up by BBN: =20 1. If a bundle includes a previous hop insertion block (defined in its own internet draft) with an EID-only or EID-with-Timestamp-formatted information record, then this means that the bundle already includes the EID of its previous hop (in its dictionary), with pointers to this previous hop EID (in its previous-hop insertion block). In this case, it would be redundant to include the EID of the previous hop in the security-source field of the BAB. Therefore, I propose that we no longer make inclusion of the security-source field mandatory in the BAB. It should be optional. If the security-source field is not present, however, and the EID of the previous hop cannot be inferred from some other part of the bundle, then processing of the BAB shall fail. The proposed text would say, "If the forwarder of the bundle is not identified in any other blocks of the bundle (e.g. the optional Previous-hop insertion block), then the security-source field MUST be present and MUST identify the forwarder of the bundle."=20 =20 2. Under the "Notes" section of 3.2.2, it says, "URI encoding will be a cause for errors if any node rewrites the dectionary...we simple hae to live with this problem". BBN wonders why we can't just put in a statement like, "A node SHOULD NOT change the encoding of any URI in the dictionary field (elg. changing the DNS part of some HTTP URL from lower case to upper case)." I don't understand the problem sufficiently be able to respond on this. =20 3. In section 3.4, Bundles received from other nodes, 5th paragraph, it says that "...the node MUST decrypt the relevant parts of the bundle according to the ciphersuite specification and delete the CH in question." BBN wants to know what to do if decryption fails. I propose we add a sentence here that says, "If the relevant parts of the bundle cannot be decrypted (i.e., the decription key cannot be deduced or decryption fails), the behavior of the bundle protocol agent will be as specified in the CB Block Processing Flags, unless overridden by the local security policy." Is this okay with you? =20 4. If the CH-RSA-AES-PAYLOAD-PSH ciphersuite is used, the first CH must have a ciphersuite parameter that contains a 16-byte IV, optionally followed by a key identifier. Is it true that the way we tell whether or not there is only an IV versus an IV followed by a key ID is by the length specified in the ciphersuite parameters SDNV? If this SDNV shows the ciphersuite parameters field to be 16 bytes long, then we know only an IV is included. If this SDNV shows the ciphersuite parameters field to be longer than 16 bytes, then we know that both an IV and a key ID is included, and the length of the key ID is the length shown in the SDNV minus 16 bytes. Is this correct? If so, BBN was unsure of it so we should probably explicitly say this in the spec. [Susan] Now that we have redefined the format of the Abstrace Security Block such that the parameters field morphed into a compound field (parameters-length field and parameters data field), I propose that we specify in teh CH-RSA_AES-PAYLOAD-PSH ciphersuite that if the parameters-length field has a value equal to 16, then the parameters data field consists of only a 16-bye IV. If the parameters-length field has a value greater than 16, then the parameters data field consists of a 16-byte IV followed by a key identifier, and the length of that key identifier is the value in the parameters length field minus 16. =20 5. To be sure I am correct, in the CH-RSA-AES-PAYLOAD-PSH ciphersuite definition, the input to the KDF is the BEK catenated wtih the IV from the ciphersuite parameter of the first CH, right? (BBN was unclear on whether there is a single IV in the first CH or whether each CH includes an IV). It is my understanding that there is a single IV in the first CH. Subsequent CHs do not contain any of the optional fields (such as ciphersuite parameters) that are included in the first CH. Is my understanding correct? =20 -susan =20 =09 ***************************************************************** Susan Symington The MITRE Corporation susan@mitre.org 703-983-7209 (voice) 703-983-7142 (fax) =09 ****************************************************************** =20 ------_=_NextPart_001_01C70A86.9585752C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Security authors and = pundits,
 
Thanks for your input in the past few = days. It is=20 helping to improve the spec.
 
As far as I can tell, below are the only = remaining items=20 that we need to resolve before we can wrap up this next revision of the = Bundle=20 Security Protocol. I would appreciate receiving your input on these = issues. Once=20 I roll in whatever revisions these generate, I will circulate = version 3 of=20 the Bundle Security Protocol for your review.
 
Thanks.
 
-susan
 
****************************************************************= *
Susan = Symington
The MITRE = Corporation
susan@mitre.org
703-983-7209 = (voice)
703-983-7142 = (fax)
****************************************************************= **
 

From: Symington, Susan F. =
Sent:=20 Monday, November 13, 2006 3:39 PM
To: Stephen Farrell; = 'Howard=20 Weiss'
Cc: Symington, Susan F.
Subject: Bundle = Security=20 Protocol items for discussion

Stephen and=20 Howie,
 
The = following are=20 Items we need to discuss wrt the bundle security protocol that were = brought up=20 by BBN:
 
1. = If a bundle=20 includes a previous hop insertion block (defined in its own internet = draft)=20 with an EID-only or EID-with-Timestamp-formatted information record, = then this=20 means that the bundle already includes the EID of its previous hop (in = its=20 dictionary), with pointers to this previous hop EID (in its = previous-hop=20 insertion block). In this case, it would be redundant to include the = EID of=20 the previous hop in the security-source field of the BAB. Therefore, I = propose=20 that we no longer make inclusion of the security-source field = mandatory in the=20 BAB. It should be optional. If the security-source field is not = present,=20 however, and the EID of the previous hop cannot be inferred from some = other=20 part of the bundle, then processing of the BAB shall fail. The = proposed text=20 would say, "If the forwarder of the bundle is not identified in any = other=20 blocks of the bundle (e.g. the optional Previous-hop insertion block), = then=20 the security-source field MUST be present and MUST identify the = forwarder of=20 the bundle."
 
2. = Under the=20 "Notes" section of 3.2.2, it says, "URI encoding will be a cause for = errors if=20 any node rewrites the dectionary...we simple hae to live with this=20 problem".  BBN wonders why we can't just put in a statement like, = "A node=20 SHOULD NOT change the encoding of any URI in the dictionary field = (elg.=20 changing the DNS part of some HTTP URL from lower case to upper = case)." =20 I don't understand the problem sufficiently be able to respond on=20 this.
 
3. = In section 3.4,=20 Bundles received from other nodes, 5th paragraph, it says that "...the = node=20 MUST decrypt the relevant parts of the bundle according to the = ciphersuite=20 specification and delete the CH in question."  BBN wants to know = what to=20 do if decryption fails.  I propose we add a sentence here that = says, "If=20 the relevant parts of the bundle cannot be decrypted (i.e., the = decription key=20 cannot be deduced or decryption fails), the behavior of the bundle = protocol=20 agent will be as specified in the CB Block Processing Flags, unless = overridden=20 by the local security policy." Is this okay with = you?
 
4. If the=20 CH-RSA-AES-PAYLOAD-PSH ciphersuite is used, the first CH must have a=20 ciphersuite parameter that contains a 16-byte IV, optionally followed = by a key=20 identifier. Is it true that the way we tell whether or not there is = only an IV=20 versus an IV followed by a key ID is by the length specified in the=20 ciphersuite parameters SDNV?  If this SDNV shows the ciphersuite=20 parameters field to be 16 bytes long, then we know only an IV is=20 included.  If this SDNV shows the ciphersuite parameters field to = be=20 longer than 16 bytes, then we know that both an IV and a key ID is = included,=20 and the length of the key ID is the length shown in the SDNV minus 16 = bytes.=20 Is this correct?  If so, BBN was unsure of it so we should = probably=20 explicitly say this in the spec.
[Susan] Now that we have redefined the format of = the=20 Abstrace Security Block such that the parameters = field morphed=20 into a  compound field (parameters-length field and=20  parameters data field), I propose that we specify in teh=20 CH-RSA_AES-PAYLOAD-PSH ciphersuite that if the parameters-length field = has a=20 value equal to 16, then the parameters data field consists of only a = 16-bye=20 IV. If the parameters-length field has a value greater than 16, then = the=20 parameters data field consists of a 16-byte IV followed by a key = identifier,=20 and the length of that key identifier is the value in the parameters = length=20 field minus 16.
 
5. = To be sure I am=20 correct, in the CH-RSA-AES-PAYLOAD-PSH ciphersuite definition, the = input to=20 the KDF is the BEK catenated wtih the IV from the ciphersuite = parameter of the=20 first CH, right?  (BBN was unclear on whether there is a single = IV in the=20 first CH or whether each CH includes an IV).  It is my = understanding that=20 there is a single IV in the first CH. Subsequent CHs do not contain = any of the=20 optional fields (such as ciphersuite parameters) that are included in = the=20 first CH.  Is my understanding correct?
 
-susan
 
****************************************************************= *
Susan = Symington
The MITRE = Corporation
susan@mitre.org
703-983-7209 = (voice)
703-983-7142 = (fax)
****************************************************************= **
 
------_=_NextPart_001_01C70A86.9585752C-- 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 kAHI7JY19328 for ; Fri, 17 Nov 2006 10:07:19 -0800 Received: from Vams.imx2 (imx2.tcd.ie [134.226.1.156]) by imx2.tcd.ie (Postfix) with SMTP id 50D2068213; Fri, 17 Nov 2006 18:07:13 +0000 (GMT) Received: from imx2.tcd.ie ([134.226.1.156]) by imx2.tcd.ie ([134.226.1.156]) with SMTP (gateway) id A0509E4D323; Fri, 17 Nov 2006 18:07:13 +0000 Received: from [127.0.0.1] (csvpn.cs.tcd.ie [134.226.52.36]) by imx2.tcd.ie (Postfix) with ESMTP id D7C1768213; Fri, 17 Nov 2006 18:07:12 +0000 (GMT) Message-ID: <455DFA86.1080802@cs.tcd.ie> Date: Fri, 17 Nov 2006 18:08:06 +0000 From: Stephen Farrell User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Peter Lovell Cc: "Symington, Susan F." , hsw , dtn-security@mailman.dtnrg.org References: <20061117000457.309686795@127.0.0.1> <8E507634779E22488719233DB3DF9FF0012296CB@IMCSRV4.MITRE.ORG> <20061117180403.31940@nemo.columbia.sparta.com> In-Reply-To: <20061117180403.31940@nemo.columbia.sparta.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiVirus-Status: MessageID = A1509E4D323 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.56.3 VDF=8.1400) Subject: [dtn-security] Re: Bundle Security Protocol details 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: Peter Lovell wrote: > I don't know of a digest mechanism which produces results which vary in > length but I can imagine that there are some. I don't believe there are any such. > However, I don't think this is a big deal. If we require fixed length > then that's OK with me. We just need to clarify what we mean. Yes, let's do that. 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 kAHI4DY19265 for ; Fri, 17 Nov 2006 10:04:13 -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 kAHI479S011103; Fri, 17 Nov 2006 12:04:07 -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 kAHI46gp020049; Fri, 17 Nov 2006 12:04:07 -0600 Received: from [157.185.81.177] ([157.185.81.177]) by nemo.columbia.ads.sparta.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Nov 2006 13:04:06 -0500 From: "Peter Lovell" To: "Symington, Susan F." , "Stephen Farrell" Cc: hsw , Date: Fri, 17 Nov 2006 13:04:03 -0500 Message-Id: <20061117180403.31940@nemo.columbia.sparta.com> In-Reply-To: <8E507634779E22488719233DB3DF9FF0012296CB@IMCSRV4.MITRE.ORG> References: <20061117000457.309686795@127.0.0.1> <8E507634779E22488719233DB3DF9FF0012296CB@IMCSRV4.MITRE.ORG> X-Mailer: CTM PowerMail version 5.2.3 build 4406 English MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Nov 2006 18:04:06.0302 (UTC) FILETIME=[C5B743E0:01C70A72] Subject: [dtn-security] Re(4): Bundle Security Protocol details 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, >>My interpretation is that the source, destination and security >>are compound fields, as suggested by having a single bit for >>each. As such, security-result-length and security-result >>would both be in the first block (res bit set) or both be >>in the second (res bit off). > >Yes, I agree. I suggest that we clarify the language to indicate that "security result" is a compound field, consisting of "security result length" and "security result data". The phrase "security result" refers to the compound field. Bit 11 ("res" bit) indicates whether or not the "security result" (length +data) is in a block (bit is set) or not (bit is zero). Length+data always go together and are never split. >>In addition, there is no requirement that the >>security-result-length be known in advance. Of course, >>in many cases it will be but I'm not aware >>that it is required to be. > >Well I've been assuming it is always known in advance. >Is this an invalid assumption? I don't think it's invalid, it's just that I had not also made that assumption. I don't know of a digest mechanism which produces results which vary in length but I can imagine that there are some. >>If the security-result-length is included in the canonicalization >>then it must be fixed before any digesting begins. If it is not >>fixed, then canonicalization must exclude the security result data >>(as it already does), the security result length (because it is >>size known since it's SDNV) and the block-length field must be >>not known, nor is its adjusted to exclude the size for these two. >> >>If we digest the length field than it can't ever be variable-length. >> > >Why can't it be variable length? The problem comes if you have multiple BA blocks. Not the "split block" kind, but where there are multiple BAs for some reason, such as key- rollover or whatever. Which one do you canonicalize first and what value can you use for the length of the second, if you don't know that until you do the second? The answer is that you can't do this unless the lengths for ALL BAs are known before you start digesting for ANY of them. And these lengths also are part of the overall block length for each block. Since I didn't want to preclude variable-length, and also because it seemed that "security result" intended to mean "length+data", I had thought to exclude both parts of that field from canonicalization. However, I don't think this is a big deal. If we require fixed length then that's OK with me. We just need to clarify what we mean. >>>2. The new "security result offset" field that is being suggested >>>should indicte the offset of the start of the security result field >>>(not of the security result length field). In line with the definition suggested at the top, I prefer that it point to the start of the "security result" field and not the start of the data field ["security result data"]. This is the same start point as the length field["security result length"], of course. Thanks.....Peter 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 kAHG5WY18425 for ; Fri, 17 Nov 2006 08:05:32 -0800 Received: from Vams.imx2 (imx2.tcd.ie [134.226.1.156]) by imx2.tcd.ie (Postfix) with SMTP id 30FD36826E; Fri, 17 Nov 2006 16:05:25 +0000 (GMT) Received: from imx2.tcd.ie ([134.226.1.156]) by imx2.tcd.ie ([134.226.1.156]) with SMTP (gateway) id A00B392D836; Fri, 17 Nov 2006 16:05:25 +0000 Received: from [127.0.0.1] (cswireless62-182.cs.tcd.ie [134.226.62.182]) by imx2.tcd.ie (Postfix) with ESMTP id 271A36826E; Fri, 17 Nov 2006 16:05:25 +0000 (GMT) Message-ID: <455DDDFB.8020402@cs.tcd.ie> Date: Fri, 17 Nov 2006 16:06:19 +0000 From: Stephen Farrell User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: dtn-security@mailman.dtnrg.org Cc: Peter Lovell , Howard Weiss Subject: Re: [dtn-security] RE: Bundle Security Protocol: one more item References: <8E507634779E22488719233DB3DF9FF001229708@IMCSRV4.MITRE.ORG> In-Reply-To: <8E507634779E22488719233DB3DF9FF001229708@IMCSRV4.MITRE.ORG> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiVirus-Status: MessageID = A10B392D836 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.56.3 VDF=8.1400) 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: Symington, Susan F. wrote: > I don't understand the replay threat. What do you mean by, "It means an > attacker could force > the processing of blocks in PSB's bundles and could replay those"? Maybe not too big a deal but if its not digested, then a bad guy can keep modifying this bit on all the bundles he sees emerging from a forwarded and in that way affect the operation of the DTN, maybe consuming resources or forcing wrong routes or whatever. > I agree that we need to put in a statement saying that this bit should > be masked in the PSB and CB (what about the BAB?) so that it is omitted > from the mutable canonical form. I don't believe that this bit should > be masked in the primary bundle block, since every node is required to > be able to process this block. Why on earth would the primary block have such a bit? Since that'd carry no useful information at all, I've no problem with it being in or out of digesting. The BAB emitter can do whatever it wants to with this. Doesn't matter since the BAB will be checked before anyone is supposed to get a chance to muck with any flag so its ok to include this in BAB digesting. S. 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 kAHFsFY18283 for ; Fri, 17 Nov 2006 07:54:16 -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 kAHFsFAw005464 for ; Fri, 17 Nov 2006 10:54:15 -0500 Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (Postfix) with ESMTP id 189C5BF7C for ; Fri, 17 Nov 2006 10:54:15 -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 kAHFsEeN005448; Fri, 17 Nov 2006 10:54:14 -0500 Received: from IMCSRV4.MITRE.ORG ([129.83.20.161]) by IMCFE1.MITRE.ORG with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Nov 2006 10:54:14 -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" Date: Fri, 17 Nov 2006 10:54:12 -0500 Message-ID: <8E507634779E22488719233DB3DF9FF001229708@IMCSRV4.MITRE.ORG> In-Reply-To: <455DD9E9.1050006@cs.tcd.ie> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Bundle Security Protocol: one more item Thread-Index: AccKX8XXA34frHP3RfacprBsIUJdgAAAHRnw From: "Symington, Susan F." To: "Stephen Farrell" Cc: "Peter Lovell" , "Howard Weiss" , X-OriginalArrivalTime: 17 Nov 2006 15:54:14.0241 (UTC) FILETIME=[A1491D10:01C70A60] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by webbie.berkeley.intel-research.net id kAHFsFY18283 Subject: [dtn-security] RE: Bundle Security Protocol: one more item 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 don't understand the replay threat. What do you mean by, "It means an attacker could force the processing of blocks in PSB's bundles and could replay those"? I agree that we need to put in a statement saying that this bit should be masked in the PSB and CB (what about the BAB?) so that it is omitted from the mutable canonical form. I don't believe that this bit should be masked in the primary bundle block, since every node is required to be able to process this block. -susan ***************************************************************** Susan Symington The MITRE Corporation susan@mitre.org 703-983-7209 (voice) 703-983-7142 (fax) ****************************************************************** >-----Original Message----- >From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] >Sent: Friday, November 17, 2006 10:49 AM >To: Symington, Susan F. >Cc: Peter Lovell; Howard Weiss; dtn-security@mailman.dtnrg.org >Subject: Re: Bundle Security Protocol: one more item > > > >Symington, Susan F. wrote: >> Suppose for example there are nodes 1, 2, and 3 and only >nodes 1 and 3 >> implement the Bundle Security Protocol. This means that if node 1 >> inserts a BAB and forwards the bundle to node 2, and node 2 doesn't >> understand the BAB and isn't configured to delete the BAB or >delete the >> bundle, then node 2 will forward the bundle to node 3 with >this "block >> was forwarde without being processed" bit set in the BAB. When node 3 >> receives the bundle and tries to authenticate the security result in >> the BAB, it won't authenticate (because of this bit change). This may >> be okay for the BAB, but it would work the same for the PSH >and I'm not >> sure that's okay. > >If the BAB verifies in that case, then something is quite weird. >If the BAB fails, then the bundle's toast so this bit is irrelevant. > >> >> If node 1 is a PSH-source, node 2 doesn't understand the PSH >and node 3 >> is a PSH-dest, then if node 2 forwards the bundle with this >bit set in >> the PSH, then I think we either have to specify that this bit must be >> reset by a node before the node validates the security result in the >> PSH or that this bit must be masked out so that it is >omitted from the >> mutable canonicalization form of the bundle. (same for CH I think.) >> >> Assuming this is true, does anyone have a preference for whether we >> should mandate that nodes processing the PSH reset this bit before >> calculating the security result or whether we should just leave this >> bit out of the mutable canoncial form? > >Ignore the bit for c14n purposes. Easy. > >Ok, that doesn't quite work though. It means an attacker could force >the processing of blocks in PSB's bundles and could replay those. So >it has to be an input to digesting in the PSB. OTOH, this silly bit >is supposed to be modified en-route, so it has to be mutable. Bummer. > >So, in the end, we have to ignore the bit for c14n purposes. > >We can (and MUST) certainly ignore the bit for security processing >purposes. > >There should be a security consideration saying that this kind of >replay can happen and why we have to live with that. > >Stephen. > > 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 kAHFm9Y18222 for ; Fri, 17 Nov 2006 07:48:09 -0800 Received: from Vams.imx2 (imx2.tcd.ie [134.226.1.156]) by imx2.tcd.ie (Postfix) with SMTP id 983FE68284; Fri, 17 Nov 2006 15:48:03 +0000 (GMT) Received: from imx2.tcd.ie ([134.226.1.156]) by imx2.tcd.ie ([134.226.1.156]) with SMTP (gateway) id A07EC394C51; Fri, 17 Nov 2006 15:48:03 +0000 Received: from [127.0.0.1] (cswireless62-182.cs.tcd.ie [134.226.62.182]) by imx2.tcd.ie (Postfix) with ESMTP id 8F95368284; Fri, 17 Nov 2006 15:48:03 +0000 (GMT) Message-ID: <455DD9E9.1050006@cs.tcd.ie> Date: Fri, 17 Nov 2006 15:48:57 +0000 From: Stephen Farrell User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: "Symington, Susan F." Cc: Peter Lovell , Howard Weiss , dtn-security@mailman.dtnrg.org References: <8E507634779E22488719233DB3DF9FF0012296F0@IMCSRV4.MITRE.ORG> In-Reply-To: <8E507634779E22488719233DB3DF9FF0012296F0@IMCSRV4.MITRE.ORG> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiVirus-Status: MessageID = A17EC394C51 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.56.3 VDF=8.1400) Subject: [dtn-security] Re: Bundle Security Protocol: one more item 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: Symington, Susan F. wrote: > Suppose for example there are nodes 1, 2, and 3 and only nodes 1 and 3 > implement the Bundle Security Protocol. This means that if node 1 > inserts a BAB and forwards the bundle to node 2, and node 2 doesn't > understand the BAB and isn't configured to delete the BAB or delete the > bundle, then node 2 will forward the bundle to node 3 with this "block > was forwarde without being processed" bit set in the BAB. When node 3 > receives the bundle and tries to authenticate the security result in > the BAB, it won't authenticate (because of this bit change). This may > be okay for the BAB, but it would work the same for the PSH and I'm not > sure that's okay. If the BAB verifies in that case, then something is quite weird. If the BAB fails, then the bundle's toast so this bit is irrelevant. > > If node 1 is a PSH-source, node 2 doesn't understand the PSH and node 3 > is a PSH-dest, then if node 2 forwards the bundle with this bit set in > the PSH, then I think we either have to specify that this bit must be > reset by a node before the node validates the security result in the > PSH or that this bit must be masked out so that it is omitted from the > mutable canonicalization form of the bundle. (same for CH I think.) > > Assuming this is true, does anyone have a preference for whether we > should mandate that nodes processing the PSH reset this bit before > calculating the security result or whether we should just leave this > bit out of the mutable canoncial form? Ignore the bit for c14n purposes. Easy. Ok, that doesn't quite work though. It means an attacker could force the processing of blocks in PSB's bundles and could replay those. So it has to be an input to digesting in the PSB. OTOH, this silly bit is supposed to be modified en-route, so it has to be mutable. Bummer. So, in the end, we have to ignore the bit for c14n purposes. We can (and MUST) certainly ignore the bit for security processing purposes. There should be a security consideration saying that this kind of replay can happen and why we have to live with that. Stephen. Received: from smtp-mclean.mitre.org (smtp-mclean.mitre.org [192.80.55.71]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id kAHFeeY18151 for ; Fri, 17 Nov 2006 07:40:40 -0800 Received: from smtp-mclean.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-mclean.mitre.org (8.12.11.20060308/8.12.11) with SMTP id kAHFedDa016978 for ; Fri, 17 Nov 2006 10:40:39 -0500 Received: from smtp-mclean.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-mclean.mitre.org (Postfix) with ESMTP id F11301BD82 for ; Fri, 17 Nov 2006 10:40:38 -0500 (EST) Received: from imcfe2.MITRE.ORG (imcfe2.mitre.org [129.83.29.4]) by smtp-mclean.mitre.org (8.12.11.20060308/8.12.11) with ESMTP id kAHFeWGK016882; Fri, 17 Nov 2006 10:40:38 -0500 Received: from IMCSRV4.MITRE.ORG ([129.83.20.161]) by imcfe2.MITRE.ORG with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Nov 2006 10:40:37 -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" Date: Fri, 17 Nov 2006 10:40:34 -0500 Message-ID: <8E507634779E22488719233DB3DF9FF0012296F0@IMCSRV4.MITRE.ORG> In-Reply-To: <455DABC2.6050200@cs.tcd.ie> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Bundle Security Protocol: one more item Thread-Index: AccKREL8UoyJcQzoSbisAA9zMJiB0gAFxnsQ From: "Symington, Susan F." To: "Stephen Farrell" Cc: "Peter Lovell" , "Howard Weiss" , X-OriginalArrivalTime: 17 Nov 2006 15:40:37.0372 (UTC) FILETIME=[BA64CBC0:01C70A5E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by webbie.berkeley.intel-research.net id kAHFeeY18151 Subject: [dtn-security] RE: Bundle Security Protocol: one more item 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: The point of the bit is to indicate that the bundle passed through a node that doesn't support the block, and that node that doesn't support the block didn't delete the block (obviously) or delete the bundle (obviously). It first came up when we were trying to define a block that essentially accumulated the EIDs of all the nodes that the bundle passed through. We wanted a way to know that the bundle had passed through some nodes that didn't add their EIDs to the accumulating path log (because the nodes didn't support the optional block). Now that I think about it, there may be more to consider with regard to how this bit works in relation to the security blocks. It is all bound up in the issue of how security works if some nodes don't support it. Suppose for example there are nodes 1, 2, and 3 and only nodes 1 and 3 implement the Bundle Security Protocol. This means that if node 1 inserts a BAB and forwards the bundle to node 2, and node 2 doesn't understand the BAB and isn't configured to delete the BAB or delete the bundle, then node 2 will forward the bundle to node 3 with this "block was forwarde without being processed" bit set in the BAB. When node 3 receives the bundle and tries to authenticate the security result in the BAB, it won't authenticate (because of this bit change). This may be okay for the BAB, but it would work the same for the PSH and I'm not sure that's okay. If node 1 is a PSH-source, node 2 doesn't understand the PSH and node 3 is a PSH-dest, then if node 2 forwards the bundle with this bit set in the PSH, then I think we either have to specify that this bit must be reset by a node before the node validates the security result in the PSH or that this bit must be masked out so that it is omitted from the mutable canonicalization form of the bundle. (same for CH I think.) Assuming this is true, does anyone have a preference for whether we should mandate that nodes processing the PSH reset this bit before calculating the security result or whether we should just leave this bit out of the mutable canoncial form? Any other thoughts? -susan ***************************************************************** Susan Symington The MITRE Corporation susan@mitre.org 703-983-7209 (voice) 703-983-7142 (fax) ****************************************************************** >-----Original Message----- >From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] >Sent: Friday, November 17, 2006 7:32 AM >To: Symington, Susan F. >Cc: Peter Lovell; Howard Weiss; dtn-security@mailman.dtnrg.org >Subject: Re: Bundle Security Protocol: one more item > > > >Symington, Susan F. wrote: >> Security pundits: >> >> One more item that I would like to address in the next >revision of the >> Bundle Security Protocol: >> >> Currently, section 3.7 of the Bundle Protocol says the following: >> >> "Whenever a bundle is forwarded that contains one or more extension >> blocks that could not be processed, the "Block was >forwarded without >> being processed" flag must be set to 1 within the block processing >> flags of each such block. For each block flagged in this way, the >> flag may optionally be cleared (i.e., set to zero) by another node >> that subsequently receives the bundle and is able to process that >> block; the specifications defining the various extension >blocks are >> expected to define the circumstances under which this flag may be >> cleared, if any. " >> >> >> This means that in the Bundle Security Protocol we need to >define the >> circumstances under >> which the "Block was forwarded without being processed" flag may be >> cleared, if any. >> >> Anyone care to take a stab at this? > >If you decrypt then you'll be deleting blocks anyway so I think >that'd be ok. Any such bit will disappear (a good thing IMO). > >BAB is irrelevant here I hope since they don't get forwarded. > >So that leaves the PSB and our one mandatory ciphersuite. > >If you successfully verify a signature, but don't remove the >PSB, I'd say leave the bit alone and forward whatever you >got. > >The reason being that it'd be bogus to have a flag that says >"someone once verified a signature here" with no further >details. Subsequent nodes can all verify the signature >if they so choose (with this ciphersuite), since verification >is sort-of idempotent if you know what I mean. > >In future, someone may want to define a brand new "security >result analysis" block that might say "bob checked alice's signature >yesterday and it was ok then, including a check with charlie's >OSCP repsonder for alice's cert serial #1234 issued by dave's >CA and bob also generated an evidence token for alice's signature >(using eddy for trusted time) and lodged that with fred." Doing >that sensibly requires more than one bit, and really requires >that bob add his own PSB as well, so we don't want the "processed" >flag to be mistakenly used as a "signature is good" signal. > >Or, I could agree to setting the bit to a random value (a generic >way to remove meaning:-). > >[As an aside - what is that bit good for anyway?] > >Stephen. > > > Received: from imx2.tcd.ie (imx2.tcd.ie [134.226.1.156]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id kAHF6gY17930 for ; Fri, 17 Nov 2006 07:06:42 -0800 Received: from Vams.imx2 (imx2.tcd.ie [134.226.1.156]) by imx2.tcd.ie (Postfix) with SMTP id 252EF68240; Fri, 17 Nov 2006 15:06:36 +0000 (GMT) Received: from imx2.tcd.ie ([134.226.1.156]) by imx2.tcd.ie ([134.226.1.156]) with SMTP (gateway) id A064462199C; Fri, 17 Nov 2006 15:06:36 +0000 Received: from [127.0.0.1] (cswireless62-182.cs.tcd.ie [134.226.62.182]) by imx2.tcd.ie (Postfix) with ESMTP id 13F6268240; Fri, 17 Nov 2006 15:06:36 +0000 (GMT) Message-ID: <455DD032.50009@cs.tcd.ie> Date: Fri, 17 Nov 2006 15:07:30 +0000 From: Stephen Farrell User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: "Symington, Susan F." Cc: Peter Lovell , hsw , dtn-security@mailman.dtnrg.org References: <8E507634779E22488719233DB3DF9FF0012296CB@IMCSRV4.MITRE.ORG> In-Reply-To: <8E507634779E22488719233DB3DF9FF0012296CB@IMCSRV4.MITRE.ORG> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiVirus-Status: MessageID = A164462199C 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.56.3 VDF=8.1400) Subject: [dtn-security] Re: Bundle Security Protocol details 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: Symington, Susan F. wrote: > The key issue seems to be the assumption that the security result > length will be known before it is calculated. Is this a bad assumption? I think its a fine assumption, so long as "known," means "known to the module that implements the ciphersuite." But if someone has a counterexample I'd be interested in seeing that. S. Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [192.160.51.76]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id kAHF3NY17873 for ; Fri, 17 Nov 2006 07:03:23 -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 kAHF3MQk005848 for ; Fri, 17 Nov 2006 10:03:22 -0500 Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (Postfix) with ESMTP id A0371BEFB for ; Fri, 17 Nov 2006 10:03:22 -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 kAHF3MoD005828; Fri, 17 Nov 2006 10:03:22 -0500 Received: from IMCSRV4.MITRE.ORG ([129.83.20.161]) by IMCFE1.MITRE.ORG with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Nov 2006 10:03:21 -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" Date: Fri, 17 Nov 2006 10:03:17 -0500 Message-ID: <8E507634779E22488719233DB3DF9FF0012296CB@IMCSRV4.MITRE.ORG> In-Reply-To: <20061117000457.309686795@127.0.0.1> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Bundle Security Protocol details Thread-Index: AccJ3XXa3jCIwUhsSnWv49AdmDwrSQAeoQ9A From: "Symington, Susan F." To: "Peter Lovell" , "Stephen Farrell" Cc: "hsw" , X-OriginalArrivalTime: 17 Nov 2006 15:03:21.0816 (UTC) FILETIME=[85E60580:01C70A59] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by webbie.berkeley.intel-research.net id kAHF3NY17873 Subject: [dtn-security] RE: Bundle Security Protocol details 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: Peter, My responses are inline. Thanks for your attention to this. -susan ***************************************************************** Susan Symington The MITRE Corporation susan@mitre.org 703-983-7209 (voice) 703-983-7142 (fax) ****************************************************************** >-----Original Message----- >From: Peter Lovell [mailto:peter.lovell@sparta.com] >Sent: Thursday, November 16, 2006 7:05 PM >To: Symington, Susan F.; Stephen Farrell >Cc: hsw; dtn-security@mailman.dtnrg.org >Subject: Re: Bundle Security Protocol details > >Hi Susan, > >>I am in the process of making the changes to the Bundle Security >>Protocol based on the comments that BBN had in their requirements >>document and also on the suggestion below by Peter Lovell. >> >>In actually making the edits with regard to Peter's >suggestion (below), >>I was forced to look at this more carefully and in so doing I realized >>that my understanding of the spec seems to differ a little from the >>assertions made in Peter's suggestion, so I would like to get a few >>details clarified and make sure we all agree on the following: >> >>1. The notes on canonicalization say that the security result is to be >>omitted. These notes do not say (or mean to imply) that the security >>result length field is to be omitted. In fact, the security result >>length field and its value is to be included in the calculation of the >>BAB security result. We want the BAB security result to be calculated >>over the entire bundle exactly as it appears, with all its fields and >>their values except for the security result field. > >I had been regarding the term "security result" field as a general >reference to length+data. The description though does name >them separately. > >However, in several places the language seems to suggest that length >+data are closely related and are to be regarded as a compound field. >For example, the "res" bit (bit 11) says that it "...indicates whether >or not the ASH contains security result length and security >result fields." > >What happens then for a two-part block scenario? The description at the >bottom of page 10 says that the security result must be absent from the >first block, and must be in the second block. Where is the security- >result-length? In the first block, or does it precede the security >result data in the second block? And is the "res" flag set in the first >block if it contains length but not the data? Good point. We need to clarify this. > >My interpretation is that the source, destination and security are >compound fields, as suggested by having a single bit for each. As such, >security-result-length and security-result would both be in the first >block (res bit set) or both be in the second (res bit off). Yes, I agree. > >In addition, there is no requirement that the security-result-length be >known in advance. Of course, in many cases it will be but I'm not aware >that it is required to be. Well I've been assuming it is always known in advance. Is this an invalid assumption? > >If the security-result-length is included in the canonicalization then >it must be fixed before any digesting begins. If it is not fixed, then >canonicalization must exclude the security result data (as it already >does), the security result length (because it is not known, nor is its >size known since it's SDNV) and the block-length field must be adjusted >to exclude the size for these two. > >If we digest the length field than it can't ever be variable-length. > Why can't it be variable length? I guess it depends on what you mean by variable length. As long as the length of the security result can be known before it is calculated, the length can be any value. The key issue seems to be the assumption that the security result length will be known before it is calculated. Is this a bad assumption? > >>2. The new "security result offset" field that is being suggested >>should indicte the offset of the start of the security result field >>(not of the security result length field). > >This depends upon what we decide for the previous item. > >However, having it point to the length field is slightly nicer. If it >does, we can find the length and process the data. But if it points to >the data, we cannot discover the length except by walking through the >block. Not a big deal either way. > > >>3. We should add an additional canonicalization note to say that the >>new security result offset field (like the "res" bit of the >ciphersuite >>ID) is part of the canonical form. In other words, when the BAB is >>calculated on the bundle, the res field will have a value of 1 and the >>security result offset field will have its correct offset value. > >I assume that res would be 1 in a single-block scenario, and 0 if the >result is in a trailer block. Yes. You are right. My example was imprecise in that it took into account only the 1-block case. > > >>4. Similarly, the value of the block data length field should be the >>length of the entire bundle, including the security result field. It >>should not change to subtract the length of the security result field >>when we calculate the security result, even though we won't calculate >>the security result over the security result field. > >Depends upon whether or not the security-result-length is fixed > >Cheers.....Peter > > Received: from imx2.tcd.ie (imx2.tcd.ie [134.226.1.156]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id kAHCVEY16941 for ; Fri, 17 Nov 2006 04:31:14 -0800 Received: from Vams.imx2 (imx2.tcd.ie [134.226.1.156]) by imx2.tcd.ie (Postfix) with SMTP id 6049D680F2; Fri, 17 Nov 2006 12:31:08 +0000 (GMT) Received: from imx2.tcd.ie ([134.226.1.156]) by imx2.tcd.ie ([134.226.1.156]) with SMTP (gateway) id A07CFB5BC62; Fri, 17 Nov 2006 12:31:08 +0000 Received: from [127.0.0.1] (unknown [134.226.144.16]) by imx2.tcd.ie (Postfix) with ESMTP id 575D4680F2; Fri, 17 Nov 2006 12:31:08 +0000 (GMT) Message-ID: <455DABC2.6050200@cs.tcd.ie> Date: Fri, 17 Nov 2006 12:32:02 +0000 From: Stephen Farrell User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: "Symington, Susan F." Cc: Peter Lovell , Howard Weiss , dtn-security@mailman.dtnrg.org References: <8E507634779E22488719233DB3DF9FF0012295D9@IMCSRV4.MITRE.ORG> In-Reply-To: <8E507634779E22488719233DB3DF9FF0012295D9@IMCSRV4.MITRE.ORG> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiVirus-Status: MessageID = A17CFB5BC62 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.56.3 VDF=8.1400) Subject: [dtn-security] Re: Bundle Security Protocol: one more item 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: Symington, Susan F. wrote: > Security pundits: > > One more item that I would like to address in the next revision of the > Bundle Security Protocol: > > Currently, section 3.7 of the Bundle Protocol says the following: > > "Whenever a bundle is forwarded that contains one or more extension > blocks that could not be processed, the "Block was forwarded without > being processed" flag must be set to 1 within the block processing > flags of each such block. For each block flagged in this way, the > flag may optionally be cleared (i.e., set to zero) by another node > that subsequently receives the bundle and is able to process that > block; the specifications defining the various extension blocks are > expected to define the circumstances under which this flag may be > cleared, if any. " > > > This means that in the Bundle Security Protocol we need to define the > circumstances under > which the "Block was forwarded without being processed" flag may be > cleared, if any. > > Anyone care to take a stab at this? If you decrypt then you'll be deleting blocks anyway so I think that'd be ok. Any such bit will disappear (a good thing IMO). BAB is irrelevant here I hope since they don't get forwarded. So that leaves the PSB and our one mandatory ciphersuite. If you successfully verify a signature, but don't remove the PSB, I'd say leave the bit alone and forward whatever you got. The reason being that it'd be bogus to have a flag that says "someone once verified a signature here" with no further details. Subsequent nodes can all verify the signature if they so choose (with this ciphersuite), since verification is sort-of idempotent if you know what I mean. In future, someone may want to define a brand new "security result analysis" block that might say "bob checked alice's signature yesterday and it was ok then, including a check with charlie's OSCP repsonder for alice's cert serial #1234 issued by dave's CA and bob also generated an evidence token for alice's signature (using eddy for trusted time) and lodged that with fred." Doing that sensibly requires more than one bit, and really requires that bob add his own PSB as well, so we don't want the "processed" flag to be mistakenly used as a "signature is good" signal. Or, I could agree to setting the bit to a random value (a generic way to remove meaning:-). [As an aside - what is that bit good for anyway?] Stephen. Received: from imx2.tcd.ie (imx2.tcd.ie [134.226.1.156]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id kAHCJFY16848 for ; Fri, 17 Nov 2006 04:19:15 -0800 Received: from Vams.imx2 (imx2.tcd.ie [134.226.1.156]) by imx2.tcd.ie (Postfix) with SMTP id 88523680E4; Fri, 17 Nov 2006 12:19:09 +0000 (GMT) Received: from imx2.tcd.ie ([134.226.1.156]) by imx2.tcd.ie ([134.226.1.156]) with SMTP (gateway) id A074127ADDD; Fri, 17 Nov 2006 12:19:09 +0000 Received: from [127.0.0.1] (unknown [134.226.144.16]) by imx2.tcd.ie (Postfix) with ESMTP id 5FEBA680E4; Fri, 17 Nov 2006 12:19:09 +0000 (GMT) Message-ID: <455DA8F3.9020603@cs.tcd.ie> Date: Fri, 17 Nov 2006 12:20:03 +0000 From: Stephen Farrell User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Peter Lovell Cc: Susan , hsw , dtn-security@mailman.dtnrg.org References: <20061115001449.1919806739@127.0.0.1> <8E507634779E22488719233DB3DF9FF0012295BA@IMCSRV4.MITRE.ORG> <20061117000457.309686795@127.0.0.1> In-Reply-To: <20061117000457.309686795@127.0.0.1> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiVirus-Status: MessageID = A174127ADDD 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.56.3 VDF=8.1400) Subject: [dtn-security] Re: Bundle Security Protocol details 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 Pete, I'd be happy with everything that Susan wrote. I also agree with you that the result-length & result are to be kept together in the same block. We should say that. You seem to be implying that there may be ciphersuites where you don't know the result length in advance, is that right? I'm not aware of any such ciphersuite as it happens. Are you? If not, then I think its fine to assume that the length is known before digesting (the c14n & digest fnc. are specified by the ciphersuite, so you've been to that code already). S. Peter Lovell wrote: > Hi Susan, > >> I am in the process of making the changes to the Bundle Security >> Protocol based on the comments that BBN had in their requirements >> document and also on the suggestion below by Peter Lovell. >> >> In actually making the edits with regard to Peter's suggestion (below), >> I was forced to look at this more carefully and in so doing I realized >> that my understanding of the spec seems to differ a little from the >> assertions made in Peter's suggestion, so I would like to get a few >> details clarified and make sure we all agree on the following: >> >> 1. The notes on canonicalization say that the security result is to be >> omitted. These notes do not say (or mean to imply) that the security >> result length field is to be omitted. In fact, the security result >> length field and its value is to be included in the calculation of the >> BAB security result. We want the BAB security result to be calculated >> over the entire bundle exactly as it appears, with all its fields and >> their values except for the security result field. > > I had been regarding the term "security result" field as a general > reference to length+data. The description though does name them separately. > > However, in several places the language seems to suggest that length > +data are closely related and are to be regarded as a compound field. > For example, the "res" bit (bit 11) says that it "...indicates whether > or not the ASH contains security result length and security result fields." > > What happens then for a two-part block scenario? The description at the > bottom of page 10 says that the security result must be absent from the > first block, and must be in the second block. Where is the security- > result-length? In the first block, or does it precede the security > result data in the second block? And is the "res" flag set in the first > block if it contains length but not the data? > > My interpretation is that the source, destination and security are > compound fields, as suggested by having a single bit for each. As such, > security-result-length and security-result would both be in the first > block (res bit set) or both be in the second (res bit off). > > In addition, there is no requirement that the security-result-length be > known in advance. Of course, in many cases it will be but I'm not aware > that it is required to be. > > If the security-result-length is included in the canonicalization then > it must be fixed before any digesting begins. If it is not fixed, then > canonicalization must exclude the security result data (as it already > does), the security result length (because it is not known, nor is its > size known since it's SDNV) and the block-length field must be adjusted > to exclude the size for these two. > > If we digest the length field than it can't ever be variable-length. > > >> 2. The new "security result offset" field that is being suggested >> should indicte the offset of the start of the security result field >> (not of the security result length field). > > This depends upon what we decide for the previous item. > > However, having it point to the length field is slightly nicer. If it > does, we can find the length and process the data. But if it points to > the data, we cannot discover the length except by walking through the > block. Not a big deal either way. > > >> 3. We should add an additional canonicalization note to say that the >> new security result offset field (like the "res" bit of the ciphersuite >> ID) is part of the canonical form. In other words, when the BAB is >> calculated on the bundle, the res field will have a value of 1 and the >> security result offset field will have its correct offset value. > > I assume that res would be 1 in a single-block scenario, and 0 if the > result is in a trailer block. > > >> 4. Similarly, the value of the block data length field should be the >> length of the entire bundle, including the security result field. It >> should not change to subtract the length of the security result field >> when we calculate the security result, even though we won't calculate >> the security result over the security result field. > > Depends upon whether or not the security-result-length is fixed > > Cheers.....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 kAH0FEY09762 for ; Thu, 16 Nov 2006 16:15:14 -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 kAH0FAJv021392; Thu, 16 Nov 2006 18:15:10 -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 kAH0FAFn004412; Thu, 16 Nov 2006 18:15:11 -0600 Received: from [192.168.4.103] ([157.185.80.253]) by nemo.columbia.ads.sparta.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Nov 2006 19:15:10 -0500 From: "Peter Lovell" To: Susan , "Stephen Farrell" Cc: hsw , Date: Thu, 16 Nov 2006 19:04:57 -0500 Message-Id: <20061117000457.309686795@127.0.0.1> In-Reply-To: <8E507634779E22488719233DB3DF9FF0012295BA@IMCSRV4.MITRE.ORG> References: <20061115001449.1919806739@127.0.0.1> <8E507634779E22488719233DB3DF9FF0012295BA@IMCSRV4.MITRE.ORG> X-Mailer: CTM PowerMail version 5.5 build 4456 English (PPC) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Nov 2006 00:15:10.0446 (UTC) FILETIME=[71C448E0:01C709DD] Subject: [dtn-security] Re: Bundle Security Protocol details 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, >I am in the process of making the changes to the Bundle Security >Protocol based on the comments that BBN had in their requirements >document and also on the suggestion below by Peter Lovell. > >In actually making the edits with regard to Peter's suggestion (below), >I was forced to look at this more carefully and in so doing I realized >that my understanding of the spec seems to differ a little from the >assertions made in Peter's suggestion, so I would like to get a few >details clarified and make sure we all agree on the following: > >1. The notes on canonicalization say that the security result is to be >omitted. These notes do not say (or mean to imply) that the security >result length field is to be omitted. In fact, the security result >length field and its value is to be included in the calculation of the >BAB security result. We want the BAB security result to be calculated >over the entire bundle exactly as it appears, with all its fields and >their values except for the security result field. I had been regarding the term "security result" field as a general reference to length+data. The description though does name them separately. However, in several places the language seems to suggest that length +data are closely related and are to be regarded as a compound field. For example, the "res" bit (bit 11) says that it "...indicates whether or not the ASH contains security result length and security result fields." What happens then for a two-part block scenario? The description at the bottom of page 10 says that the security result must be absent from the first block, and must be in the second block. Where is the security- result-length? In the first block, or does it precede the security result data in the second block? And is the "res" flag set in the first block if it contains length but not the data? My interpretation is that the source, destination and security are compound fields, as suggested by having a single bit for each. As such, security-result-length and security-result would both be in the first block (res bit set) or both be in the second (res bit off). In addition, there is no requirement that the security-result-length be known in advance. Of course, in many cases it will be but I'm not aware that it is required to be. If the security-result-length is included in the canonicalization then it must be fixed before any digesting begins. If it is not fixed, then canonicalization must exclude the security result data (as it already does), the security result length (because it is not known, nor is its size known since it's SDNV) and the block-length field must be adjusted to exclude the size for these two. If we digest the length field than it can't ever be variable-length. >2. The new "security result offset" field that is being suggested >should indicte the offset of the start of the security result field >(not of the security result length field). This depends upon what we decide for the previous item. However, having it point to the length field is slightly nicer. If it does, we can find the length and process the data. But if it points to the data, we cannot discover the length except by walking through the block. Not a big deal either way. >3. We should add an additional canonicalization note to say that the >new security result offset field (like the "res" bit of the ciphersuite >ID) is part of the canonical form. In other words, when the BAB is >calculated on the bundle, the res field will have a value of 1 and the >security result offset field will have its correct offset value. I assume that res would be 1 in a single-block scenario, and 0 if the result is in a trailer block. >4. Similarly, the value of the block data length field should be the >length of the entire bundle, including the security result field. It >should not change to subtract the length of the security result field >when we calculate the security result, even though we won't calculate >the security result over the security result field. Depends upon whether or not the security-result-length is fixed Cheers.....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 kAGLCbY08563 for ; Thu, 16 Nov 2006 13:12:37 -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 kAGLCaHe026940 for ; Thu, 16 Nov 2006 16:12:36 -0500 Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (Postfix) with ESMTP id 88B55BF7B for ; Thu, 16 Nov 2006 16:12:36 -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 kAGLCarO026920; Thu, 16 Nov 2006 16:12:36 -0500 Received: from IMCSRV4.MITRE.ORG ([129.83.20.161]) by IMCFE1.MITRE.ORG with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Nov 2006 16:12:35 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C709C3.EFFC30D7" Date: Thu, 16 Nov 2006 16:12:34 -0500 Message-ID: <8E507634779E22488719233DB3DF9FF0012295D9@IMCSRV4.MITRE.ORG> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Bundle Security Protocol: one more item Thread-Index: AccJw++LfVqMzDqHSYWznSa+Z0GUxw== From: "Symington, Susan F." To: "Stephen Farrell" , "Peter Lovell" , "Howard Weiss" Cc: X-OriginalArrivalTime: 16 Nov 2006 21:12:35.0753 (UTC) FILETIME=[F042C990:01C709C3] Subject: [dtn-security] Bundle Security Protocol: one more item 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: This is a multi-part message in MIME format. ------_=_NextPart_001_01C709C3.EFFC30D7 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Security pundits: =20 One more item that I would like to address in the next revision of the Bundle Security Protocol: =20 Currently, section 3.7 of the Bundle Protocol says the following: =20 "Whenever a bundle is forwarded that contains one or more extension=20 blocks that could not be processed, the "Block was forwarded without being processed" flag must be set to 1 within the block processing=20 flags of each such block. For each block flagged in this way, the=20 flag may optionally be cleared (i.e., set to zero) by another node=20 that subsequently receives the bundle and is able to process that=20 block; the specifications defining the various extension blocks are=20 expected to define the circumstances under which this flag may be=20 cleared, if any. " =20 =20 This means that in the Bundle Security Protocol we need to define the circumstances under which the "Block was forwarded without being processed" flag may be cleared, if any. =20 Anyone care to take a stab at this? =20 -susan =20 ***************************************************************** Susan Symington The MITRE Corporation susan@mitre.org 703-983-7209 (voice) 703-983-7142 (fax) ****************************************************************** =20 ------_=_NextPart_001_01C709C3.EFFC30D7 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Security=20 pundits:
 
One = more item that I=20 would like to address in the next revision of the Bundle Security=20 Protocol:
 
Currently, section=20 3.7 of the Bundle Protocol says the following:
 
"Whenever a bundle is forwarded that = contains=20 one or more extension
   blocks that could not be = processed, the=20 "Block was forwarded without
   being processed" flag must = be set=20 to 1 within the block processing
   flags of each such=20 block.  For each block flagged in this way, the
   = flag may=20 optionally be cleared (i.e., set to zero) by another node =
   that=20 subsequently receives the bundle and is able to process that =
  =20 block; the specifications defining the various extension blocks are=20
   expected to define the circumstances under which this = flag may=20 be
   cleared, if any. "
 
 
This means=20 that in the Bundle Security Protocol we need to define the circumstances = under
which the=20 "Block was forwarded without being processed" flag may be cleared, if=20 any.
 
Anyone care to=20 take a stab at this?
 
-susan
 
****************************************************************= *
Susan = Symington
The MITRE = Corporation
susan@mitre.org
703-983-7209 = (voice)
703-983-7142 = (fax)
****************************************************************= **
 
------_=_NextPart_001_01C709C3.EFFC30D7-- Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [192.160.51.76]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id kAGKXmY08222 for ; Thu, 16 Nov 2006 12:33:48 -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 kAGKXlvQ017408 for ; Thu, 16 Nov 2006 15:33:47 -0500 Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (Postfix) with ESMTP id 89FE5BF7E for ; Thu, 16 Nov 2006 15:33:47 -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 kAGKXl8m017383; Thu, 16 Nov 2006 15:33:47 -0500 Received: from IMCSRV4.MITRE.ORG ([129.83.20.161]) by IMCFE1.MITRE.ORG with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Nov 2006 15:33:46 -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" Date: Thu, 16 Nov 2006 15:33:45 -0500 Message-ID: <8E507634779E22488719233DB3DF9FF0012295BA@IMCSRV4.MITRE.ORG> In-Reply-To: <20061115001449.1919806739@127.0.0.1> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Bundle Security Protocol details Thread-Index: AccISxs1rRpTV1HCSBiHMiS0Sevv1gBb5K7Q From: "Symington, Susan F." To: "Peter Lovell" , "Stephen Farrell" Cc: "hsw" , X-OriginalArrivalTime: 16 Nov 2006 20:33:46.0751 (UTC) FILETIME=[841148F0:01C709BE] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by webbie.berkeley.intel-research.net id kAGKXmY08222 Subject: [dtn-security] Bundle Security Protocol details 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: Stephen, Peter, and Howie: I am in the process of making the changes to the Bundle Security Protocol based on the comments that BBN had in their requirements document and also on the suggestion below by Peter Lovell. In actually making the edits with regard to Peter's suggestion (below), I was forced to look at this more carefully and in so doing I realized that my understanding of the spec seems to differ a little from the assertions made in Peter's suggestion, so I would like to get a few details clarified and make sure we all agree on the following: 1. The notes on canonicalization say that the security result is to be omitted. These notes do not say (or mean to imply) that the security result length field is to be omitted. In fact, the security result length field and its value is to be included in the calculation of the BAB security result. We want the BAB security result to be calculated over the entire bundle exactly as it appears, with all its fields and their values except for the security result field. 2. The new "security result offset" field that is being suggested should indicte the offset of the start of the security result field (not of the security result length field). 3. We should add an additional canonicalization note to say that the new security result offset field (like the "res" bit of the ciphersuite ID) is part of the canonical form. In other words, when the BAB is calculated on the bundle, the res field will have a value of 1 and the security result offset field will have its correct offset value. 4. Similarly, the value of the block data length field should be the length of the entire bundle, including the security result field. It should not change to subtract the length of the security result field when we calculate the security result, even though we won't calculate the security result over the security result field. In summary, we don't want to change the values of any fields of the bundle. We want the security result calculated over all the fields as they are, with the one exception that the security result field is omitted. Do we all agree on this? -susan ***************************************************************** Susan Symington The MITRE Corporation susan@mitre.org 703-983-7209 (voice) 703-983-7142 (fax) ****************************************************************** >-----Original Message----- >From: Peter Lovell [mailto:peter.lovell@sparta.com] >Sent: Tuesday, November 14, 2006 7:15 PM >To: Symington, Susan F.; Stephen Farrell; Scott Burleigh >Cc: hsw; Peter Lovell; Michael Demmer; DTNRG >Subject: discussion items > > > >Format of security blocks (ASB) >------------------------------- > >There's an open question about one item with strict canonicalization, >which was discussed on email last week. It woulld be helpful to look at >security spec section 3.2.1 [page 17] and the general diagram Figure 2 >on page 8. > >The question is what value to use for the header (block) data length >field "len". > >The notes on canonicalization say that the security result >(data and its >length field) is to be omitted, but don't say what value to >use for "len". > >I suspect that it should be the length the block would be if the >security result were omitted, that is, size of the block less the size >of the security result and the size of the security result size field >itself (SDNV). > >The second part of the issue is that it's hard to arrive at that value >-- you have to slog your way through all the fields one by one. > >Stephen has suggested two changes to help here ... >1. change the "params" field to be param-length (SDNV) followed by > param-data (that many octets). > >2. add a "security offset" field immediately after the >ciphersuite field. > This is an optional SDNV, present only if the "res" bit is >set indicating > that a security-result field is present in this block. The >value in the > field is the offset of the start of the "res-len" field >relative to the > start of the block. > > >I propose that we make these two changes, and define the "len" field >more closely. >