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 l3PKgQY09699 for ; Wed, 25 Apr 2007 13:42:27 -0700 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 l3PKgPTi020061 for ; Wed, 25 Apr 2007 15:42:25 -0500 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 l3PKgPUn006966 for ; Wed, 25 Apr 2007 15:42:26 -0500 Received: from [192.168.4.99] ([157.185.80.253]) by nemo.columbia.ads.sparta.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Apr 2007 16:42:25 -0400 From: "Peter Lovell" To: Date: Wed, 25 Apr 2007 16:42:24 -0400 Message-Id: <20070425204224.1395967896@127.0.0.1> X-Mailer: CTM PowerMail version 5.5.3 build 4480 English (PPC) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Apr 2007 20:42:25.0336 (UTC) FILETIME=[3B431380:01C7877A] X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (M4.sparta.com [157.185.61.2]); Wed, 25 Apr 2007 15:42:25 -0500 (CDT) Subject: [dtn-security] BSP draft issues 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: Working through the notes from Howie's Big Red Pen, I come across a couple of not-quite-editing questions. I'm sure I'll find more :) Anyhow, we might be able to deal also with these before Dublin so please let me have your opinions. ---------------- The discussion of confidentiality in section 2.4 makes mention of a way to collect several blocks together and encrypt them as a single clump. Do we really want to allow this, or should we have blocks encrypted on a one-to-one basis? Because of the block-sequence issues, I would like to remove this "collection" and have it one-to-one only. There may have been a size-efficiency reason for doing the collection but now we have EID-references that's much better. ------------------ In section 3.2.2 on mutable canonicalization, there's a discussion about what's included and what isn't. In the part about the payload, it says that we include the "block was forwarded without being processed" flag because no-one should ever set it, as all nodes must be able to process it. I'm not sure that is really true. Maybe the flag isn't set, but it's not always possible to "process" the payload block. It might be an admin record, or encrypted, or maybe something else. I don't want to get into the issue of what might or might not happen to that bit, as it's more properly a bundle protocol issue rather than BSP. But unless someone has an objection, I'd like to treat the bit in payload flags the same way we do for extension blocks - regard it as mutable and exclude it from canonicalization. ------------------ Thanks.....Peter Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id l3OHdUY29811 for ; Tue, 24 Apr 2007 10:39:30 -0700 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 l3OHdSoU000804; Tue, 24 Apr 2007 12:39:28 -0500 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 l3OHdTtd015742; Tue, 24 Apr 2007 12:39:29 -0500 Received: from [192.168.4.99] ([157.185.80.253]) by nemo.columbia.ads.sparta.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Apr 2007 13:39:28 -0400 From: "Peter Lovell" To: Susan Cc: Date: Tue, 24 Apr 2007 13:39:26 -0400 Message-Id: <20070424173926.100798624@127.0.0.1> In-Reply-To: <8E507634779E22488719233DB3DF9FF00175290D@IMCSRV4.MITRE.ORG> References: <8E507634779E22488719233DB3DF9FF00175290D@IMCSRV4.MITRE.ORG> X-Mailer: CTM PowerMail version 5.5.3 build 4480 English (PPC) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Apr 2007 17:39:28.0564 (UTC) FILETIME=[822ED740:01C78697] X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (M4.sparta.com [157.185.61.2]); Tue, 24 Apr 2007 12:39:29 -0500 (CDT) Subject: [dtn-security] Re(7): [dtn-interest] block-sequencing issue 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: On Thu, Apr 19, 2007, Symington, Susan F. wrote: >Peter, > >I have a question about the BSP that relates to the below message that >you sent out in February. >You argued eloquently for the requirement that the ordering of blocks >be preserved at all nodes, and now this change has been made to the BP. >Which this change, the ordering of the bundles can be used to indicate >in what order they should be processed. > >What I'm not clear about is where in the BSP the text actually >specifies what order certain operations should be performed in. For >example, If node 1 calculates and inserts a PSB1 on the bundle and then >the next node, node 2, calculates and inserts a PSB2 on the bundle >(including the BSP1 that was inserted by node 1) then some later node >that wants to verify the security result of BSP 1 needs to know to >exclude BSP2 and a node that wants to verify the security result of >BSP2 needs to know to include BSP1. From your email, it seems that the >relative order of BSP1 and BSP2 in the bundle is what indicates which >signature covers which. My concern is that (unless I am missing it), >the specification isn't very clear on how the relative ordering of two >blocks determines how the security result of one does (or doesn't) >include the other block. > >The only text in the spec that I could find that seems to address this >issue is in 3.2.2, where it says, > " - the ciphersuite will likely specify that the "current" security > block security result field not be considered part of the > canonical form. This differs from the case in strict > canonicalisation since we might use the mutable canonicalisation > algorithm to handle sequential signatures, where later signatures > should cover earlier ones." > >Am I missing some text somewhere? > >Don't we need to add text to the PSB-RSA-SHA256 section, for example, >that says something like: > >"If a PSB with this ciphersuite is being inserted into a bundle then: > - it must be added after all other PSBs (if any) that are in the >bundle, > - its canonical form must include all PSBs that precede the PSB in >question and must exclude the security result field of the PSB in >question. > >When verifying the security result in a PSB that uses this ciphersuite, >all PSBs that precede the PSB in question must be included as part of >the canonical form, all PSBs that follow the PSB in question must be >excluded, and all fields of the PSB in question except for the security >result field must be included?" > >(I'm assuming that this is how your implementation works.) > >-susan Hi Susan, You are correct - there is additional language needed in BSP to discuss the sequencing, as Keith's email had also suggested. The block sequence is critical for things such as PS digests, as I mentioned and as is now described in the spec. A second reason for maintaining order is to determine the process sequence, which was mentioned only lightly during the discussion. Although we need language to define the processing order, that has been hard to pin down. I've been trying to leave it open and use the BSP code development as a guide to what we need to codify. There are some general principles I've been using ... 1. some actions don't need sequence at all, and can be done any time 2. some actions don't cause a change but must happen at a specific point in the sequence, digest creation is a typical example 3. some actions change data and must happen at a specific point, encryption being an example of this 4. the "layering" outward from the payload block is an indicator of the processing sequence There are some actions which don't have a marker in the sequence, with fragmentation being the most obvious. Although there may be ways to determine in some cases just when a bundle was fragmented, I'm not sure if we can generally do it. For example, can we always tell whether fragmentation was before encryption, or after it? We certainly can sometimes tell, but I'm not certain about "always". I'm thinking about establishing a new extension block type to track modifications, for those situations where there isn't a block already. Although it would be a "block", core code would understand it. I'm thinking of having it as a block mainly so the sequence/layering is quite clear. It would then be easy to determine, for example, that a bundle was fragmented, then encrypted, and fragmented again -- no uncertainty at all. This might also be a good alternative for bundle-in-bundle encapsulation. The payload would then not be an administrative record, with all the side effects you described in your recent email. Instead, we'd have an extension block processor which deals with BiB, just as a confidentiality ciphersuite does encryption. One advantage of this approach is that the block can have the "relicate in every fragment" flag set, so all fragments carry the BiB labeling (having the admin- record information at the front of the payload means that it it's only in the zero-offset fragment). Regards.....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 l3KHMmY04903 for ; Fri, 20 Apr 2007 10:22:48 -0700 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 l3KHMlSO029530; Fri, 20 Apr 2007 12:22:47 -0500 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 l3KHMl6Y015896; Fri, 20 Apr 2007 12:22:48 -0500 Received: from [192.168.4.99] ([157.185.80.253]) by nemo.columbia.ads.sparta.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 20 Apr 2007 13:22:47 -0400 From: "Peter Lovell" To: , Susan Cc: "Peter Lovell" Subject: Re: [dtn-security] A comment on BSP draft -03 Date: Fri, 20 Apr 2007 13:22:45 -0400 Message-Id: <20070420172245.2084852048@127.0.0.1> In-Reply-To: <8E507634779E22488719233DB3DF9FF001752B28@IMCSRV4.MITRE.ORG> References: <8E507634779E22488719233DB3DF9FF001752B28@IMCSRV4.MITRE.ORG> X-Mailer: CTM PowerMail version 5.5.3 build 4480 English (PPC) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Apr 2007 17:22:47.0366 (UTC) FILETIME=[83C52660:01C78370] X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (M4.sparta.com [157.185.61.2]); Fri, 20 Apr 2007 12:22:47 -0500 (CDT) 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, On Fri, Apr 20, 2007, Symington, Susan F. wrote: > >1. The EID references could contain ZERO, one or two EIDs. That's true. I guess I was thinking of the reference code implementation which omits the field entirely if there are no entries. >2. I dont' think you should call it bit 6. Just call it by the flag >name, in case the flags change place sometime in the BP. I had suggested that BP include short names for these, in addition to the very-long-winded-descriptive-labels-which-lose-people's-attention-as- they-read-to-the-end. I'll catch this next time around. >3. I don't think that using only the ordering of the EIDs is >sufficient. What if only one EID is present. How does the node know >whether this is the security-source or the security-destination? I >think we need some other indicator to be able to tell the difference. This was a KISS call on my part when we were doing the suggestion. The only extension blocks with two EIDs are security ones, and we already have flags in the ciphersuite field to say which are present. It's like moving those fields from the block-specific-data into the preamble -- the same rules apply. If there are two in the list, it's sec-source then sec-dest just as it was previously in the block data. If there's only one, the flags in ciphersuite tell you which, and the other is null, just as it was previously. If the count is zero then they're both null. No other blocks presently have more than one EID, so the issue does not come up elsewhere. If/when new blocks are defined with more, they'll have to include some way to deal with this. I was mindful of this issue during the discussions, and tried to get some way to simply define a null EID. That, of course, is not the same as "dtn:none" but more like the usage in BSP where, for example, a null sec-dest means that sec-dest is the bundle destination. Obviously this is not at all the same as "dtn:none" as a destination. My suggestion was to include a single NULL byte as the start of the dictionary. That way, a reference of {0, 0} would be guaranteed to refer to a null EID. Unfortunately that suggestion was not adopted, so if you need a null EID in the list then you have to actually create one and add it. 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 l3KEtXY03400 for ; Fri, 20 Apr 2007 07:55:33 -0700 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 l3KEtXew007967 for ; Fri, 20 Apr 2007 10:55:33 -0400 Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (Postfix) with ESMTP id 14897C023 for ; Fri, 20 Apr 2007 10:55:33 -0400 (EDT) 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 l3KEtW2J007956 for ; Fri, 20 Apr 2007 10:55:32 -0400 Received: from IMCSRV4.MITRE.ORG ([129.83.20.161]) by imcfe2.MITRE.ORG with Microsoft SMTPSVC(6.0.3790.1830); Fri, 20 Apr 2007 10:55:32 -0400 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_01C7835B.F1981BCE" Date: Fri, 20 Apr 2007 10:55:31 -0400 Message-ID: <8E507634779E22488719233DB3DF9FF001752B28@IMCSRV4.MITRE.ORG> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: A comment on BSP draft -03 Thread-Index: AceDW/FbZr39NsuHR1KWcYCRkrMDLA== From: "Symington, Susan F." To: X-OriginalArrivalTime: 20 Apr 2007 14:55:32.0453 (UTC) FILETIME=[F1C06950:01C7835B] Subject: [dtn-security] A comment on BSP draft -03 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_01C7835B.F1981BCE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Peter,=20 =20 Below are some comments on the following text from the version -03 draft of the BSP that you recently sent to dtn-dev: =20 - EID references - composite field defined in [2] containing references to one or two EIDs. Presence of EIDs is indicated by by the setting of bit 6 ("block contains an EID-reference field") of the block processing control flags. If one or more is present, flags in the ciphersuite ID field, described below, specify which. The possible EIDs are, in order:- =20 - (optional) Security-source - specifies the security source for the service. If this is omitted, then the source of the bundle is assumed to be the security-source. =20 - (optional) Security-destination - specifies the security destination for the service. If this is omitted, then the destination of the bundle is assumed to be the security- destination. =20 Both EID fields may be omitted, in which case the composite field itself is empty, as defined in [2]. In this case neither count nor references appear, and bit 6 is not set. ------------------------------------------------------- =20 1. The EID references could contain ZERO, one or two EIDs. 2. I dont' think you should call it bit 6. Just call it by the flag name, in case the flags change place sometime in the BP. 3. I don't think that using only the ordering of the EIDs is sufficient. What if only one EID is present. How does the node know whether this is the security-source or the security-destination? I think we need some other indicator to be able to tell the difference.=20 =20 -susan =20 =20 ***************************************************************** Susan Symington The MITRE Corporation susan@mitre.org 703-983-7209 (voice) 703-983-7142 (fax) ****************************************************************** =20 ------_=_NextPart_001_01C7835B.F1981BCE Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Peter,=20

 

Below are = some comments=20 on the following text from the version -03 draft of the BSP that you = recently=20 sent to dtn-dev:

 

- EID references - composite field defined in [2] = containing

     =20 references to one or two EIDs.  Presence of EIDs is indicated=20 by

      by=20 the setting of bit 6 ("block contains an EID-reference = field")

      of=20 the block processing control flags. =20 If one or more is present,

     =20 flags in the ciphersuite ID field, described below, specify=20 which.

      The=20 possible EIDs are, in order:-

 

      -=20 (optional) Security-source - specifies the security source = for

      the=20 service.  If this is = omitted, then=20 the source of the bundle is

     =20 assumed to be the security-source.

 

      -=20 (optional) Security-destination - specifies the = security

     =20 destination for the service. =20 If this is omitted, then the

     =20 destination of the bundle is assumed to be the=20 security-

     =20 destination.

 

     =20 Both EID fields may be omitted, in which case the composite=20 field

     =20 itself is empty, as defined in [2]. =20 In this case neither count

      nor=20 references appear, and bit 6 is not set.

-------------------------------------------------------

 

1. The = EID references=20 could contain ZERO, one or two EIDs.

2. I = dont' think you=20 should call it bit 6.  Just call it by the flag name, in case the = flags=20 change place sometime in the BP.

3. I = don't think that=20 using only the ordering of the EIDs is sufficient.  What if only = one EID is=20 present.  How does the node know whether this is the = security-source or the=20 security-destination? I think we need some other indicator to be able to = tell=20 the difference.

 

-susan

 

 
****************************************************************= *
Susan = Symington
The MITRE = Corporation
susan@mitre.org
703-983-7209 = (voice)
703-983-7142 = (fax)
****************************************************************= **
 
------_=_NextPart_001_01C7835B.F1981BCE--