Re: [dtn-security] Updated SBSP Document
Amy Alford <aloomis@sarn.org> Mon, 02 June 2014 15:32 UTC
Return-Path: <aloomis@sarn.org>
X-Original-To: dtn-security@ietfa.amsl.com
Delivered-To: dtn-security@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7712E1A0385 for <dtn-security@ietfa.amsl.com>; Mon, 2 Jun 2014 08:32:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.723
X-Spam-Level:
X-Spam-Status: No, score=0.723 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Voau4WEKUhYG for <dtn-security@ietfa.amsl.com>; Mon, 2 Jun 2014 08:32:37 -0700 (PDT)
Received: from mail-ob0-f174.google.com (mail-ob0-f174.google.com [209.85.214.174]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 620251A0371 for <dtn-security@irtf.org>; Mon, 2 Jun 2014 08:32:37 -0700 (PDT)
Received: by mail-ob0-f174.google.com with SMTP id uz6so4679976obc.5 for <dtn-security@irtf.org>; Mon, 02 Jun 2014 08:32:31 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=1EPZl3kseo4XnPZ4MwluKAt6GcWP0r3/Uet08Q2BnxQ=; b=MV81ZlasmjlKdA79taxFM7rbwZhG0B8HccUW9WCoKDyjWS/h2gIPEg9EuO7H1aTxYO QA9S2aRF65yxcTIt+L14dNArliy4+kX5oILqtwEOCBd6ZKubGbxFHA/vW497/UmylGx7 knxPabBhGCZOEUhXY61bLWIBh8M0S1x8/qSjlKTPO1XyTJ6dVljwqsmQsAaw/CLIctQz A50FoQFdu7eMo7OAkN+WVBSOPXGi2WVIc/lO43xHJ7iiT9JUJ91jHN5OdWRS8rdp7FBl UQYz5tsXvHRv4O+TetC+g5O4byD2RF9o9xjCh+c8ly7wQn++LvO5P5PzIBvPoekVxUKX lG8g==
X-Gm-Message-State: ALoCoQmeKLMPodzc3mKomNWjwZrFu1FZgaQ6ixuyh+dMTDwvuMDQEROuUYAMWbXzQQKzYF4K/jeV
MIME-Version: 1.0
X-Received: by 10.182.60.65 with SMTP id f1mr3763698obr.78.1401723151824; Mon, 02 Jun 2014 08:32:31 -0700 (PDT)
Received: by 10.182.176.5 with HTTP; Mon, 2 Jun 2014 08:32:31 -0700 (PDT)
In-Reply-To: <A5BEAD028815CB40A32A5669CF737C3B423B369E@ap-embx-sp40.RES.AD.JPL>
References: <329D879C76FDD04AAAE84BB1D89B3970094FBF9EAA@aplesfreedom.dom1.jhuapl.edu> <94CFB3711B4CAE4DBFC5BEB3374BF0C60D1835@NDMSMBX404.ndc.nasa.gov> <A5BEAD028815CB40A32A5669CF737C3B423B369E@ap-embx-sp40.RES.AD.JPL>
Date: Mon, 02 Jun 2014 11:32:31 -0400
Message-ID: <CAB9rx+9RDz3nudRifan8Sfo+44EjnPsvm=G0z5S53qCo6GOUJg@mail.gmail.com>
From: Amy Alford <aloomis@sarn.org>
To: "Burleigh, Scott C (312G)" <scott.c.burleigh@jpl.nasa.gov>
Content-Type: multipart/alternative; boundary="089e01538ad889cda804fadc1a1f"
Archived-At: http://mailarchive.ietf.org/arch/msg/dtn-security/zNRuvfnTBRMdWkE1esSfGH3_M_o
Cc: "dtn-security@irtf.org" <dtn-security@irtf.org>
Subject: Re: [dtn-security] Updated SBSP Document
X-BeenThere: dtn-security@irtf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Security." <dtn-security.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/dtn-security>, <mailto:dtn-security-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/dtn-security/>
List-Post: <mailto:dtn-security@irtf.org>
List-Help: <mailto:dtn-security-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/dtn-security>, <mailto:dtn-security-request@irtf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Jun 2014 15:32:41 -0000
I'm also responding inline. On Fri, May 30, 2014 at 3:17 PM, Burleigh, Scott C (312G) < scott.c.burleigh@jpl.nasa.gov> wrote: > A couple of remarks on David’s comments, in-line below. > > > > Scott > > > > *From:* dtn-security [mailto:dtn-security-bounces@irtf.org] *On Behalf Of > *Zoller, David A. (MSFC-EO50)[HOSC SERVICES CONTRACT] > *Sent:* Thursday, May 29, 2014 12:09 PM > *To:* Birrane, Edward J.; dtn-security@irtf.org > *Subject:* Re: [dtn-security] Updated SBSP Document > > > > Ed, > > Good work - the SBSP spec continues to evolve nicely. I’ll kick off the > discussions with my comments below. > > Cheers, > > DZ > > > > > > > > *[Page 12] 2.4 Bundle Authentication Block* > > The security-target MUST be the entire bundle, which MUST be > > represented by a <block type><occurrence number> of <0x00><0x00>. > > · Per 3.4 Bundle Fragmentation and Reassembly, bundle > authentication may be applied to bundle fragments as well as non-fragmented > bundles. > > · If a bundle fragment is received that has a BAB, there is no > way to determine if the BAB applies to the bundle fragment or if it applies > to an entire bundle that was later fragmented by a non-security-aware BA. > > o I propose that a <block type><occurrence number> of <0x00><payload > frag length> indicate that the BAB applies to a bundle fragment > > · If such a bundle fragment is further fragmented by a > non-security-aware BA then the <payload frag length> can be used to > determine that the original fragmented bundle must be reassembled before > authentication is checked because it will not match the length field in the > payload block. > > o Some discussion may be desirable in section 3.4 as well as 2.4 if > accepted > > Ø When a BAB is attached to a bundle that is a fragment, the bundle that > it applies to is always that fragment, never the bundle that carried the > original payload (of which the current bundle’s payload is a fragment). > Since BABs are not end-to-end, the BAB for an original un-fragmented bundle > will never be carried forward in any fragments generated from that bundle > (see the last paragraph of 3.3.1), so there’s no ambiguity. But this does > bring up an important point: the block processing control flags of the BAB > must always have the “replicate in every fragment” flag set to 0. > > > Maybe I'm misunderstanding here, but fragmentation can happen between a BAB source and a BAB dest if a non-security aware node is between the two. Requiring the "DO_NOT_FRAGMENT" flag solves this. > > > *[Page 14] 2.6 Block Confidentiality Block* > > The block processing control flags value can be set to whatever > > values are required by local policy, except that a Lone BCB or > > First BCB MUST have the "replicate in every fragment" flag set. > > This indicates to a receiving node that the payload portion in > > each fragment represents cipher-text. > > · The intent here is only if the target of the Lone BCB or First > BCB is the payload block which would need to be added if this is kept as a > requirement. > > · I think this requirement should be removed or at least reduced > to a "MAY" > > 1. It assumes that the Lone or First BCB must be prior to the > payload block which is not a specific requirement and is not necessary in > any case for SBSP > > 2. A BCB block could be quite large and add a lot of bandwidth > overhead if included in every fragment > > 3. I do not see a benefit gained by including the block in every > fragment > > i. Even the destination > node likely cannot decrypt any individual fragment except the first one > and it probably would only decrypt a partial bundle as a last resort or > forensic function if the entire bundle was not received before expiration > > ii. Intermediate nodes > shouldn't generally be poking around in bundle payloads anyway and no need > to provide additional clues as to whether a fragment payload is encrypted > or a bunch of binary values – keep the bad guys guessing and wasting CPU > cycles if possible > > iii. BSP includes this > requirement - have any of the implementations found a need or benefit for > this and would it still apply in context of the SBSP? > > Ø I think this a good point. Since all decryption should only happen at > the bundle destination, which is where all the fragments are going to have > to end up, why not forward all BCBs (for all blocks that have them) only > with the fragment whose offset is zero? > Is there a possibility of an intermediate node adding a BIB to the fragment, unaware that there's already a BCB on the whole payload? I really hate the interaction between fragmentation and BSP. I feel like tightly locking down how the two of them combine avoids a lot of pitfalls and ambiguity. > > > > > > *[Page 24] 3.1.2.3 Extension Block Canonicalization* > > The block-length is canonicalized as its unpacked SDNV value. If the > > data to be canonicalized is less than the complete, original block > > data, this field contains the size of the data being canonicalized > > (the "effective block") rather than the actual size of the block. > > · Section 3.1.2.1 (Primary Block Canonicalization) details the > length fields as 4 byte values and effectively reserves the term "unpacked > SDNV value" to mean the 8 byte value. I recommend using the same convention > here. > > o Personally, I would specify all SDNV values canonicalized as 8 byte > values and be done with it > > · Add a statement to the effect: > > o The entirety or portion(s) of the block body data are canonicalized > as is. > > Ø I agree about canonicalizing all SDNVs as 8-byte values. FWIW, I > think the canonicalization in bundle security protocol is a major pain in > the neck. Is the mutability of blocks – the need to exclude mutable fields > from hash computations – the main reason for it? Is there no way to > simplify? > > > I think the major issue is the dictionary, since it can be modified even if the actual eid's in the block are stable. The flags are straightforward. In BSP, there's also a big issue with tail chasing when a PIB block is required to include chunks of itself in it's own hash. IIRC, SBSP avoids that entirely.
- [dtn-security] Updated SBSP Document Birrane, Edward J.
- Re: [dtn-security] Updated SBSP Document Zoller, David A. (MSFC-EO50)[HOSC SERVICES CONTRACT]
- Re: [dtn-security] Updated SBSP Document Burleigh, Scott C (312G)
- Re: [dtn-security] Updated SBSP Document Amy Alford
- Re: [dtn-security] Updated SBSP Document Burleigh, Scott C (312G)
- Re: [dtn-security] Updated SBSP Document Scott, Keith L.
- Re: [dtn-security] Updated SBSP Document Burleigh, Scott C (312G)