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

Michael Demmer <> Tue, 06 December 2005 19:02 UTC

Received: from pisco.CS.Berkeley.EDU (Debian-exim@pisco.CS.Berkeley.EDU []) by (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 <>
Cc: "Susan F. Symington" <>, Howard Weiss <>
Subject: Re: [dtn-security] bundle security protocol changes...
Message-ID: <>
References: <>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.9i
X-Mailman-Version: 2.0.13
Precedence: bulk
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 :)