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

Scott Burleigh <> Wed, 07 December 2005 21:26 UTC

Received: from ( []) by (8.11.6/8.11.6) with ESMTP id jB7LQ1g26528 for <>; Wed, 7 Dec 2005 13:26:01 -0800
Received: from ( []) by (Switch-3.1.7/Switch-3.1.7) with ESMTP id jB7LPtR2015625; Wed, 7 Dec 2005 13:25:55 -0800
Received: from [] ( []) by (Switch-3.1.7/Switch-3.1.7) with ESMTP id jB7LPrq0013147; Wed, 7 Dec 2005 13:25:55 -0800
Message-ID: <>
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
CC: "Susan F. Symington" <>, Howard Weiss <>
Subject: Re: [dtn-security] bundle security protocol changes...
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Source-IP: []
X-AUTH: Internal IP
X-Mailman-Version: 2.0.13
Precedence: bulk
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]
> - 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.