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, 2 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.