Re: [dtn-security] bundle security protocol changes...

Scott Burleigh <Scott.Burleigh@jpl.nasa.gov> Wed, 07 December 2005 21:26 UTC

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 <dtn-security@mailman.dtnrg.org>; 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 <Scott.Burleigh@jpl.nasa.gov>
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" <susan@mitre.org>, Howard Weiss <hsw@sparta.com>
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: <http://mailman.dtnrg.org/mailman/listinfo/dtn-security>, <mailto:dtn-security-request@mailman.dtnrg.org?subject=unsubscribe>
List-Id: DTN Security Discussion <dtn-security.mailman.dtnrg.org>
List-Post: <mailto:dtn-security@mailman.dtnrg.org>
List-Help: <mailto:dtn-security-request@mailman.dtnrg.org?subject=help>
List-Subscribe: <http://mailman.dtnrg.org/mailman/listinfo/dtn-security>, <mailto:dtn-security-request@mailman.dtnrg.org?subject=subscribe>
List-Archive: <http://mailman.dtnrg.org/pipermail/dtn-security/>

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