Received: from nmta3.jpl.nasa.gov (nmta3.jpl.nasa.gov [137.78.160.108]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id jB7LQ1g26528 for ; Wed, 7 Dec 2005 13:26:01 -0800 Received: from xmta3.jpl.nasa.gov (xmta3.jpl.nasa.gov [137.78.160.111]) by nmta3.jpl.nasa.gov (Switch-3.1.7/Switch-3.1.7) with ESMTP id jB7LPtR2015625; Wed, 7 Dec 2005 13:25:55 -0800 Received: from [127.0.0.1] (dhcp-79-22-154.jpl.nasa.gov [137.79.22.154]) by xmta3.jpl.nasa.gov (Switch-3.1.7/Switch-3.1.7) with ESMTP id jB7LPrq0013147; Wed, 7 Dec 2005 13:25:55 -0800 Message-ID: <43975361.0@jpl.nasa.gov> Date: Wed, 07 Dec 2005 13:25:53 -0800 From: Scott Burleigh User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: dtn-security@mailman.dtnrg.org CC: "Susan F. Symington" , Howard Weiss Subject: Re: [dtn-security] bundle security protocol changes... References: <4395CF25.3060108@cs.tcd.ie> In-Reply-To: <4395CF25.3060108@cs.tcd.ie> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: dhcp-79-22-154.jpl.nasa.gov [137.79.22.154] X-Source-Sender: Scott.Burleigh@jpl.nasa.gov X-AUTH: Internal IP 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 Farrell wrote: > Folks, > > Susan, Howie and I just had a call (thanks skype!) about things > to do with the next rev of the bundle security draft [1] and > the list below are my rough notes about the main changes we're > planning. We'd welcome any comments before doing the I-D > production donkey-work:-) > > We're aiming a bit optimisitically at having -01 out before > the holidays. > > Cheers, > Stephen. > > [1] http://tools.ietf.org/id/draft-irtf-dtnrg-bundle-security-00.txt > > - Align terminology with the latest bundle spec. > > - Allow a header to follow the payload in order to carry > signatures and MACs. I think the easiest way to do that > is to just let it be defined per ciphersuite, so that e.g. > HMAC-in-front would be a different ciphersuite from > HMAC-at-the-end (which would require two BAH/PSH headers > in the bundle). Security result is therefore also > optional in an ASH and we add a bit to indicate its > presence. > > - I think that we ought to allow more bits for the > ciphersuite say adding another byte to get 13 bits. > > - Accomodate the changed SDNV. Some fields (e.g. > security result) will now be an SDNV encoded length > followed by the required number of octets. > > - Define a type for this header since its no longer > in the bundle spec. I guess '2' is fine? Sure. Or, as you point out in your response to Mike, maybe '2' and '3' and '4' because you've got three new header types. > I don't think > an ASH needs an overall length since the flags and > thereafter individual optional fields each specify > their own lengths. I think we're now all agreed that all of these headers need header data length (and also header processing control flags), as per 3.1 of the Bundle Protocol spec. > - C14N. I dunno what to do here yet. This might have > to wait on someone coding it all up to be something we > can do correctly. But we'll probably think of stuff > as we edit it. > > - Since the bundle spec has gotten rid of most of > its API stuff, can we do the same? I would say Sure. > - Deal with combinations of PSH/BAH & CH. There's > more needed there: > > - Just for a starter let's say that we add a new field > to the ASH so we can correlate the front-end and rear-end > pairs (say if >1 PSH is applied). We could call that > the 'marker' and make it optional for the 1st > application of an ASH - all subsequent ASH's would > have to include a unique marker. (Might a counter > be better?) > > - Next for CH we include the enciphered payloads in > the additional CH header. What I mean is that the > first CH of a (marker-matching-set) should contain > the keying material and subsequent ones should contain > (n the security result field) the ciphertext (e.g. > encrypted payloads). A single CH can contain > ciphertext for >1 header. The 1st CH can also contain > ciphertext for some headers. > > - PSH and CH service (with markers) can be applied to > any headers you like in the obvious way, except that > each service applicaiton has to envelope the others. > > - One exception is that if you're using a signature > ciphersuite then if subsequent encryption has to include > both the signed data and the signature and not just > the signed data. > > - And since that's all very complicated, we mandate > support for only one of each type of ciphersuite (or > even fewer), and we also mandate that nodes only > need support say one level of combining. Other nodes > could of course do more, but that'd be subject to > further specification/profiling in some other RFC. This sounds okay to me, Stephen. Scott Received: from relay.imagine.ie (relay.imagine.ie [87.232.1.41]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id jB6KNkg17472 for ; Tue, 6 Dec 2005 12:23:46 -0800 Received: from mail2.int.imagine.ie (mail2 [87.232.1.153]) by relay.imagine.ie (Postfix) with ESMTP id 240344075; Tue, 6 Dec 2005 20:23:45 +0000 (GMT) Received: from [127.0.0.1] (dsl-102-234.cust.imagine.ie [87.232.102.234]) by mail2.int.imagine.ie (8.13.4/8.13.4/Debian-3) with ESMTP id jB6KNer1024359; Tue, 6 Dec 2005 20:23:43 GMT Message-ID: <4395F319.4060405@cs.tcd.ie> Date: Tue, 06 Dec 2005 20:22:49 +0000 From: Stephen Farrell User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: dtn-security@mailman.dtnrg.org CC: "Susan F. Symington" , Howard Weiss Subject: Re: [dtn-security] bundle security protocol changes... References: <4395CF25.3060108@cs.tcd.ie> <20051206190244.GH3095@pisco.cs.berkeley.edu> In-Reply-To: <20051206190244.GH3095@pisco.cs.berkeley.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Bayes-Prob: 0.0001 (Score 0) X-Spam-Score: 0.00 () [Hold at 8.00] X-Canit-Stats-ID: 139830 - ed9659af6a0c (trained as not-spam) X-CanItPRO-Stream: outgoing X-Scanned-By: CanIt (www . roaringpenguin . com) on 87.232.1.53 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 Mike, Michael Demmer wrote: >>- Allow a header to follow the payload in order to carry >>signatures and MACs. I think the easiest way to do that >>is to just let it be defined per ciphersuite, so that e.g. >>HMAC-in-front would be a different ciphersuite from >>HMAC-at-the-end (which would require two BAH/PSH headers >>in the bundle). Security result is therefore also >>optional in an ASH and we add a bit to indicate its >>presence. > > Can you briefly explain why two BAH/PSH headers are required for the > case where the sig/MAC follows the payload. This may be obvious but I > don't get it. So the ciphersuite is up-front, so a node with only small buffers can still handle large bundles. Using the same header type before and after is just one possible design, but seems simplest to me given the way we'll be mixing multiple applications of security headers later on. > Also, just so we're on the same page, the rational for having the sig > at the end is that you can start sending the payload bits before > you've calculated the signature on the whole thing? As such you don't > need to pull the whole payload into memory, generate the MAC, then > send the MAC and send the payload? Yes, exactly. Its for nodes with small buffers who handle large bundles (or where scaling creates the same effect). >>- Define a type for this header since its no longer >>in the bundle spec. I guess '2' is fine? I don't think >>an ASH needs an overall length since the flags and >>thereafter individual optional fields each specify >>their own lengths. > > > But for implementations that don't include the security support, we > need these headers to follow the standard header preamble (with > length) so they can be skipped when processing the bundle. Very true. And I'd forgotten about it. (Susan had also pointed out that we need three different header values for BAH, PSH and CH too.) Thanks for catching that. [...] > For the above points, I'm too far removed to understand all of what > you're proposing to even begin to comment :) Yep they're just abbreviated notes. Basically though what we want to be able to eventually support is something a bit like a mixture of s/mime's ability to forward encrypted mail adding a new signature and a sequence of VPN tunnels. Clearly some ascii-art is needed. Stephen. Received: from pisco.CS.Berkeley.EDU (Debian-exim@pisco.CS.Berkeley.EDU [128.32.37.175]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id jB6J2ig16916 for ; Tue, 6 Dec 2005 11:02:44 -0800 Received: from demmer by pisco.CS.Berkeley.EDU with local (Exim 4.50) id 1Eji5M-0001g0-1w; Tue, 06 Dec 2005 11:02:44 -0800 Date: Tue, 6 Dec 2005 11:02:44 -0800 From: Michael Demmer To: dtn-security@mailman.dtnrg.org Cc: "Susan F. Symington" , Howard Weiss Subject: Re: [dtn-security] bundle security protocol changes... Message-ID: <20051206190244.GH3095@pisco.cs.berkeley.edu> References: <4395CF25.3060108@cs.tcd.ie> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4395CF25.3060108@cs.tcd.ie> User-Agent: Mutt/1.5.9i 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: > - Allow a header to follow the payload in order to carry > signatures and MACs. I think the easiest way to do that > is to just let it be defined per ciphersuite, so that e.g. > HMAC-in-front would be a different ciphersuite from > HMAC-at-the-end (which would require two BAH/PSH headers > in the bundle). Security result is therefore also > optional in an ASH and we add a bit to indicate its > presence. Can you briefly explain why two BAH/PSH headers are required for the case where the sig/MAC follows the payload. This may be obvious but I don't get it. Also, just so we're on the same page, the rational for having the sig at the end is that you can start sending the payload bits before you've calculated the signature on the whole thing? As such you don't need to pull the whole payload into memory, generate the MAC, then send the MAC and send the payload? > - Define a type for this header since its no longer > in the bundle spec. I guess '2' is fine? I don't think > an ASH needs an overall length since the flags and > thereafter individual optional fields each specify > their own lengths. But for implementations that don't include the security support, we need these headers to follow the standard header preamble (with length) so they can be skipped when processing the bundle. > - C14N. I dunno what to do here yet. This might have > to wait on someone coding it all up to be something we > can do correctly. But we'll probably think of stuff > as we edit it. > > - Since the bundle spec has gotten rid of most of > its API stuff, can we do the same? > > - Deal with combinations of PSH/BAH & CH. There's > more needed there: > > - Just for a starter let's say that we add a new field > to the ASH so we can correlate the front-end and rear-end > pairs (say if >1 PSH is applied). We could call that > the 'marker' and make it optional for the 1st > application of an ASH - all subsequent ASH's would > have to include a unique marker. (Might a counter > be better?) > > - Next for CH we include the enciphered payloads in > the additional CH header. What I mean is that the > first CH of a (marker-matching-set) should contain > the keying material and subsequent ones should contain > (n the security result field) the ciphertext (e.g. > encrypted payloads). A single CH can contain > ciphertext for >1 header. The 1st CH can also contain > ciphertext for some headers. > > - PSH and CH service (with markers) can be applied to > any headers you like in the obvious way, except that > each service applicaiton has to envelope the others. > > - One exception is that if you're using a signature > ciphersuite then if subsequent encryption has to include > both the signed data and the signature and not just > the signed data. > > - And since that's all very complicated, we mandate > support for only one of each type of ciphersuite (or > even fewer), and we also mandate that nodes only > need support say one level of combining. Other nodes > could of course do more, but that'd be subject to > further specification/profiling in some other RFC. For the above points, I'm too far removed to understand all of what you're proposing to even begin to comment :) -m 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 jB6HoPg16464 for ; Tue, 6 Dec 2005 09:50:26 -0800 Received: from Vams.imx2 (imx2.tcd.ie [134.226.1.156]) by imx2.tcd.ie (Postfix) with SMTP id 1457F68239; Tue, 6 Dec 2005 17:50:19 +0000 (GMT) Received: from imx2.tcd.ie ([134.226.1.156]) by imx2.tcd.ie ([134.226.1.156]) with SMTP (gateway) id A016C211381; Tue, 06 Dec 2005 17:50:19 +0000 Received: from [127.0.0.1] (unknown [134.226.144.16]) by imx2.tcd.ie (Postfix) with ESMTP id 0E52068239; Tue, 6 Dec 2005 17:50:19 +0000 (GMT) Message-ID: <4395CF25.3060108@cs.tcd.ie> Date: Tue, 06 Dec 2005 17:49:25 +0000 From: Stephen Farrell User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: dtn-security@mailman.dtnrg.org Cc: "Susan F. Symington" , Howard Weiss Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiVirus-Status: MessageID = A116C211381 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.974) Subject: [dtn-security] bundle security protocol changes... 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: Folks, Susan, Howie and I just had a call (thanks skype!) about things to do with the next rev of the bundle security draft [1] and the list below are my rough notes about the main changes we're planning. We'd welcome any comments before doing the I-D production donkey-work:-) We're aiming a bit optimisitically at having -01 out before the holidays. Cheers, Stephen. [1] http://tools.ietf.org/id/draft-irtf-dtnrg-bundle-security-00.txt - Align terminology with the latest bundle spec. - Allow a header to follow the payload in order to carry signatures and MACs. I think the easiest way to do that is to just let it be defined per ciphersuite, so that e.g. HMAC-in-front would be a different ciphersuite from HMAC-at-the-end (which would require two BAH/PSH headers in the bundle). Security result is therefore also optional in an ASH and we add a bit to indicate its presence. - I think that we ought to allow more bits for the ciphersuite say adding another byte to get 13 bits. - Accomodate the changed SDNV. Some fields (e.g. security result) will now be an SDNV encoded length followed by the required number of octets. - Define a type for this header since its no longer in the bundle spec. I guess '2' is fine? I don't think an ASH needs an overall length since the flags and thereafter individual optional fields each specify their own lengths. - C14N. I dunno what to do here yet. This might have to wait on someone coding it all up to be something we can do correctly. But we'll probably think of stuff as we edit it. - Since the bundle spec has gotten rid of most of its API stuff, can we do the same? - Deal with combinations of PSH/BAH & CH. There's more needed there: - Just for a starter let's say that we add a new field to the ASH so we can correlate the front-end and rear-end pairs (say if >1 PSH is applied). We could call that the 'marker' and make it optional for the 1st application of an ASH - all subsequent ASH's would have to include a unique marker. (Might a counter be better?) - Next for CH we include the enciphered payloads in the additional CH header. What I mean is that the first CH of a (marker-matching-set) should contain the keying material and subsequent ones should contain (n the security result field) the ciphertext (e.g. encrypted payloads). A single CH can contain ciphertext for >1 header. The 1st CH can also contain ciphertext for some headers. - PSH and CH service (with markers) can be applied to any headers you like in the obvious way, except that each service applicaiton has to envelope the others. - One exception is that if you're using a signature ciphersuite then if subsequent encryption has to include both the signed data and the signature and not just the signed data. - And since that's all very complicated, we mandate support for only one of each type of ciphersuite (or even fewer), and we also mandate that nodes only need support say one level of combining. Other nodes could of course do more, but that'd be subject to further specification/profiling in some other RFC.