Re: [dtn-security] 00 version of the Bundle Security Protocol Spec.

Stephen Farrell <stephen.farrell@cs.tcd.ie> Tue, 07 June 2005 13:41 UTC

Received: from smtp3.tcd.ie (smtp3.tcd.ie [134.226.1.158]) by webbie.berkeley.intel-research.net (8.11.6/8.11.6) with ESMTP id j57DfEV01850 for <dtn-security@mailman.dtnrg.org>; Tue, 7 Jun 2005 06:41:14 -0700
Received: from Vams.smtp3 (smtp3.tcd.ie [134.226.1.158]) by smtp3.tcd.ie (Postfix) with SMTP id 04D5614C01F for <dtn-security@mailman.dtnrg.org>; Tue, 7 Jun 2005 14:41:03 +0100 (IST)
Received: from smtp3.tcd.ie ([134.226.1.158]) by smtp3.tcd.ie ([134.226.1.158]) with SMTP (gateway) id A03A55E4020; Tue, 07 Jun 2005 14:41:03 +0100
Received: from [134.226.36.26] (sfarrel2.dsg.cs.tcd.ie [134.226.36.26]) by smtp3.tcd.ie (Postfix) with ESMTP id CCD0614C01F for <dtn-security@mailman.dtnrg.org>; Tue, 7 Jun 2005 14:41:03 +0100 (IST)
Message-ID: <42A5A4FB.6040607@cs.tcd.ie>
Date: Tue, 07 Jun 2005 14:45:31 +0100
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: dtn-security@mailman.dtnrg.org
Subject: Re: [dtn-security] 00 version of the Bundle Security Protocol Spec.
References: <200505241854.j4OIsx724035@smtp-bedford-dr.mitre.org> <429CA44A.4000405@jpl.nasa.gov>
In-Reply-To: <429CA44A.4000405@jpl.nasa.gov>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
X-AntiVirus-Status: Checked by TCD Vexira. (version=1.55.010 VDF=8.752)
X-AntiVirus-Status: NONE
X-AntiVirus-Status: Action Taken:
X-AntiVirus-Status: Host: smtp3.tcd.ie
X-AntiVirus-Status: MessageID = A13A55E4020
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/>

Foks,

Catching up after a week of sporadic access...

Scott Burleigh wrote:

> Susan F. Symington wrote:
> 
>> All,
>> Attached is our first draft of the DTN Bundle Security Protocol 
>> Specification. Please read it and provide comments.
> Hi. I've got a few comments on the substance of the spec, but not many; 
[...]

> Yes. In general, I think the clearest way to link these two documents in 
> a cleanly decoupled fashion is this:
> 
> 1. Number most of the paragraphs in the BP spec individually, so that 
> other documents can easily refer to them.

That's not usual IETF practice and could run afoul of RFC
editor procedures. Better to just number sections that
need to be referenced unless you like being a guinea pig.

> 2. Include in the BP spec, somewhere at the start of the procedure 
> specifications, a note to the effect that "the procedures mandated by 
> this specification are neither exhaustive nor exclusive; supplementary 
> DTN protocol specifications (including, but not restricted to, the 
> Bundle Security Protocol) may require that additional measures be taken 
> at specified junctures in these procedures; such additional measures 
> shall not override or supersede the mandated BP procedures, except that 
> they may in some cases make these procedures moot by requiring, for 
> example, that implementations conforming to the supplementary protocol 
> terminate the processing of a given incoming or outgoing bundle due to a 
> fault condition recognized by that protocol."
> 3. Remove all other security-specific language from the BP spec.

Nope. We've agreed that the security *protocol* stuff is in the
separate draft. The base spec still has to include whatever
security considerations apply since otherwise an implementer
who's not coding up the security protocol will miss out on
all that good advice.

> 4. Modify the Security spec to say things like "The following procedure 
> MUST be performed immediately before the start of the BP procedure 
> described in w.x.y.z: blah blah blah."

Whatever. So long as the procedures are informative and the
protocol specs. normative. (Note: I've no problem if the
procedures are RECOMMENDED or even if implementations
MUST produce the same outputs, but there's no reason
everyone's code has to have the same abstract APIs etc.)

> 2. In section 2.2: is it your intent that the CH remains in the bundle 
> even after decryption by the CH security destination, so that it can 
> appear in the Data.indication at a bundle destination that isn't the 
> decryptor? 

Not really. Generally a CH will be stripped at the CH-dest.
I could probably invent some kind of shared secret case
where retaining it is necessary but it'd be a corner case.
(Note though that we've yet to analyse the CH/PSH combinations
so some use case might crop up there. Ditto for IBE I
suppose.)

There's currently no extension with the semantics "this
bundle used to be encrypted & I decrypted it & here's how".
I'd be surprised if that were worthwhile though.

 > If so, what's the rationale for that? Likewise, does the PSH
> remain in the bundle even after verification by a PSH security 
> destination that isn't the bundle destination?

The PSH case is different. For signature schemes its quite
possible that many nodes could check the correctness of the
signature bits, but only for some nodes to be able to check
key/revocation status. In that case, it does make sense to
allow nodes after the PSH-dest to see/check the PSH. With
MACs there'll be similar cases which arise if/when we get
to sort-of-secure-multicast.

> 4. In section 3.1: if you use really big keys, does this cause the 
> security result (the result of applying a key in a calculation) to be 
> really big as well? Too big to fit into 16 bytes? Do we need SDNVs to be 
> coded for 1-2-4-8-16-32-64-128 for this purpose, or will the 
> 1-2-3-4-5-6-8-16 coding Mike proposed be sufficient?

See separate thread.

> 6. Section 4.2: I don't think we really need to have a canonical form 
> for bundles; instead, the Bundle Protocol Specification needs to define 
> the canonical sequence in which bundle data elements are considered in 
> the calculation of signatures, MACs, etc. The former is the physical 
> form -- the on-the-wire format -- of the bundle, which doesn't matter; 
> the latter is the *logical* form -- the Security Protocol's view -- of 
> the bundle, which can always be readily computed from the former. You're 
> already implicitly recognizing this by talking about headers that are 
> "(logically) removed" from the bundle prior to calculation and endpoint 
> ID strings that must be "substituted for their corresponding fields in 
> the concatenated bundle header." I think it would greatly simplify the 
> spec to simply say something like "the BSP view of a bundle shall 
> comprise the logical concatenation of the following data elements" and 
> then talk about performing calculations on the BSP view of the bundle. 
> (You do something like this in the third paragraph of 4.3, third 
> sentence. I think it's the right approach.)

As Susan said the canonical form isn't necessarily transmitted ever
so I think we mean the same thing. We'll probably disagree about
how easy it is though, since in my experience this is the hardest
thing to get right for any data integrity service.

> 11. Re Comment.26: the security policy database has to be discussed in 
> this document, where it makes sense, not in the BP spec.

Not quite! To the extent that it makes no reference to BAH/CH/PSH
you could argue that security policy discussion really has to
be in the base spec since that's where the reader/coder starts
and is as far as many will get.

Seems wrong to have a MUST type reference to the security protocol
spec from the base spec which is what you'll otherwise need.

Stephen.