Re: [dtn-security] Issue implementing security source/destination with ESB blocks

Stephen Farrell <stephen.farrell@cs.tcd.ie> Mon, 03 September 2012 13:35 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: dtn-security@ietfa.amsl.com
Delivered-To: dtn-security@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2548821F8555 for <dtn-security@ietfa.amsl.com>; Mon, 3 Sep 2012 06:35:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.523
X-Spam-Level:
X-Spam-Status: No, score=-102.523 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tZT12DpkqkBE for <dtn-security@ietfa.amsl.com>; Mon, 3 Sep 2012 06:35:33 -0700 (PDT)
Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 9CE5921F8557 for <dtn-security@irtf.org>; Mon, 3 Sep 2012 06:35:33 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id D3B3A171481; Mon, 3 Sep 2012 14:35:32 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1346679330; bh=VKWNwX11iIJb0u gXjJf4R8G4W12Vb8D33KrI/LI/J5c=; b=iS7+rUt0zFrndr1BILwH/wvyAgjovD nTMxJHVcCvMWCWqs6H47TjGRGmRzdA93QXx0Nys2s5tsdhzHIGWCpAC8ePiHqWm1 nhwsjtGTAj7P0bNUoQT8FonBMiJHCgNHjFzZ6ILmikhS2+k2prY0iy0GbUn2qdJt ahQYanu+0dbXai0oBsMCjwif/KMfFZJn0wKzO9S6quVOEef+LAPhgxsMgvjoA9Oz Ekxe6lZX+0smVuXM1oczVEKCX82JlSTheVPErIQ3x09ozRmhNnDJTQYENg4NK2NV F6923lsPf8J49rTkKhkmVURSMpcRdd2a0fybLCEmgD0dShVgCq7Qa0rw==
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id vi9guUzZ-eq2; Mon, 3 Sep 2012 14:35:30 +0100 (IST)
Received: from [IPv6:2001:770:10:203:801b:1e72:c3a5:ecd8] (unknown [IPv6:2001:770:10:203:801b:1e72:c3a5:ecd8]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id EBB9D17147F; Mon, 3 Sep 2012 14:35:28 +0100 (IST)
Message-ID: <5044B220.7040605@cs.tcd.ie>
Date: Mon, 03 Sep 2012 14:35:28 +0100
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0
MIME-Version: 1.0
To: ahennes1@math.umd.edu
References: <f1abb474b138939c6494addd3ac356bb.squirrel@webmail.math.umd.edu> <CAB9rx+9v4T9f-RXQbzKV67h7wiDbqZoyLjbKSesc+mnJ_TKhtw@mail.gmail.com> <CAB9rx+9WnNdwhDJq9HEqkHW49C+F8q_7MgZuzwzGcp9tH9+BHA@mail.gmail.com> <dd65229141b55c413fa835120b5477aa.squirrel@webmail.math.umd.edu> <20120821141321.215374808@smtp.mail.me.com> <CAB9rx+-ZVvQ+rT8kVMu_TQOUm6q55gtjecWj-qb0oXhdJkmizw@mail.gmail.com> <97735113a72c3d32d66ca834c84ff8a4.squirrel@webmail.math.umd.edu> <20120824185650.1151428911@smtp.mail.me.com> <cae89cc48d18dea2288489bce7473621.squirrel@webmail.math.umd.edu>
In-Reply-To: <cae89cc48d18dea2288489bce7473621.squirrel@webmail.math.umd.edu>
X-Enigmail-Version: 1.4.4
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: dtn-security@irtf.org
Subject: Re: [dtn-security] Issue implementing security source/destination with ESB blocks
X-BeenThere: dtn-security@irtf.org
X-Mailman-Version: 2.1.12
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, 03 Sep 2012 13:35:35 -0000

As a process-point, that's a *big* erratum. If this were
an IETF standards track document, we'd probably encourage
it to be done as I-D that updated the BSP RFC. I don't
believe the IRTF have any agreed policy for when things
should be done as an erratum or as a separate I-D, so
I'll ask about that. Meanwhile, if folks could comment
on the proposal that'd be good, so's when we know what
works process-wise, we'll be ready to go ahead.

S.

On 09/03/2012 02:05 PM, ahennes1@math.umd.edu wrote:
> We've hashed out some of the wording, and below is what we'd like to
> propose for the BSP errata list. Any comments are welcome.
> 
> Thanks,
> Angela
> 
> 
> 
> 
> Section 3.4.1,pg.32 says:
> 
>    The first algorithm that can be used permits no changes at all to the
>    bundle between the security-source and the security-destination.  It
>    is mainly intended for use in BAB ciphersuites.  This algorithm
>    conceptually catenates all blocks in the order presented, but omits
>    all security-result data fields in blocks of this ciphersuite type.
>    That is, when a BAB ciphersuite specifies this algorithm, we omit all
>    BAB security-results for all BAB ciphersuites.  When a PIB
>    ciphersuite specifies this algorithm, we omit all PIB security-
>    results for all PIB ciphersuites.  All security-result length fields
>    are included, even though their corresponding security-result data
>    fields are omitted.
> 
> It should say:
> 
>    The first algorithm that can be used permits no changes at all to the
>    bundle between the security-source and the security-destination, with
>    the exception of one of the Block Processing Control Flags, as
>    described  below.  It is mainly intended for use in BAB ciphersuites.
>    This algorithm conceptually catenates all blocks in the order presented,
>    but omits all security-result data fields in blocks of this ciphersuite
>    type.  That is, when a BAB ciphersuite specifies this algorithm, we omit
>    all BAB security-results for all BAB ciphersuites.  When a PIB
>    ciphersuite specifies this algorithm, we omit all PIB security-
>    results for all PIB ciphersuites.  All security-result length fields
>    are included, even though their corresponding security-result data
>    fields are omitted.
> 
>    Notes:
> 
>    o  In the Block Processing Control Flags field, in every block other
>       than the Primary Block, the flag at bit 5, "Block was forwarded
>       without being processed" is canonicalized as zero.  The Block
> Processing
>       Control Flags field, which is an SDNV, is unpacked into a fixed-width
>       field, and some bits are masked out. The unpacked field is ANDed with
>       mask 0xFFFF FFFF FFFF FFDF to set to zero the "Block was forwarded
>       without being processed" bit for the purposes of canonicalization.
> 
> Notes: If this flag is not zeroed out, when a bundle passes through a
> non-security aware node, this flag will be set. This will then change the
> message digest, and a BAB block will fail to verify.
> 
> 
> 
> Section 3.4.2,pg.35 says:
> 
>    For non-primary blocks being included in the canonicalization, the
>    block processing control flags value used for canonicalization is the
>    unpacked SDNV value with reserved and mutable bits masked to zero.
>    The unpacked value is ANDed with mask 0x0000 0000 0000 0077 to zero
>    reserved bits and the "last block" flag.  The "last block" flag is
>    ignored because BABs and other security blocks MAY be added for some
>    parts of the journey but not others, so the setting of this bit might
>    change from hop to hop.
> 
> It should say:
> 
>    For non-primary blocks being included in the canonicalization, the
>    block processing control flags value used for canonicalization is the
>    unpacked SDNV value with reserved and mutable bits are masked to zero.
>    The unpacked value is ANDed with mask 0x0000 0000 0000 0057 to zero
>    reserved bits, the "last block" flag and the "Block was forwarded
>    without being processed" bit.  The "last block" flag is ignored because
>    BABs and other security blocks MAY be added for some parts of the
>    journey but not others, so the setting of this bit might change from hop
>    to hop. The "Block was forwarded without being processed" flag is
>    ignored because the bundle may pass through a non security-aware node,
>    and this flag would be set.
> 
> 
> 
> Section 2.1,pg.10 says:
> 
>    o  EID-references - composite field defined in [DTNBP] containing
>       references to one or two endpoint identifiers (EIDs).  Presence of
>       the EID-reference field is indicated by the setting of the "Block
>       contains an EID-reference field" (EID_REF) bit of the block
>       processing control flags.  If one or more references are present,
>       flags in the ciphersuite ID field, described below, specify which.
> 
>       If no EID fields are present, then the composite field itself MUST
>       be omitted entirely and the EID_REF bit MUST be unset.  A count
>       field of zero is not permitted.
> 
>    o  The possible EIDs are:
> 
>       *  (OPTIONAL) Security-source - specifies the security-source for
>          the block.  If this is omitted, then the source of the bundle
>          is assumed to be the security-source unless otherwise
>          indicated.
> 
>       *  (OPTIONAL) Security-destination - specifies the security-
>          destination for the block.  If this is omitted, then the
>          destination of the bundle is assumed to be the security-
>          destination unless otherwise indicated.
> 
>       If two EIDs are present, security-source is first and security-
>       destination comes second.
> 
> It should say:
> 
>    o  EID-references - composite field defined in [DTNBP] containing one
>       or more references to endpoint identifiers (EIDs) (optional) [DTNBP].
>       Presence of the EID-reference field is indicated by the setting
>       of the "Block contains an EID-reference field" (EID_REF) bit of
>       the block processing control flags.  If the security-source and
>       security-destination are present, flags in the ciphersuite ID
>       field, described below, specify which. Additional EID references MAY
>       also be present.
> 
>       If no EID fields are present, then the composite field itself MUST
>       be omitted entirely and the EID_REF bit MUST be unset.  A count
>       field of zero is not permitted.
> 
>    o  Among the possible EIDs are:
> 
>       *  (OPTIONAL) Security-source - specifies the security-source for
>          the block.  If this is omitted, then the source of the bundle
>          is assumed to be the security-source unless otherwise
>          indicated.
> 
>       *  (OPTIONAL) Security-destination - specifies the security-
>          destination for the block.  If this is omitted, then the
>          destination of the bundle is assumed to be the security-
>          destination unless otherwise indicated.
> 
>       If present, the security-source and security-destination are the
>       first EID references, with the security-source first, followed by
>       the security-destination.
> 
> 
> 
> Section 2.5,pg.21 says:
> 
>    The process is reversed at the security-destination with the
>    recovered plaintext block replacing the ESB that had encapsulated it.
>    Processing of EID-list entries, if any, is described in Section 2.4,
>    and this MUST be followed in order to correctly recover EIDs.
> 
> It should say:
> 
>    The EID reference to the security-source (if present) is the first
>    entry in the EID list, followed by the EID reference to the security-
>    destination (if present). The EID reference list from the block being
>    protected is then copied to the ESB, and the EID reference count is
>    updated appropriately.
> 
>    The process is reversed at the security-destination with the
>    recovered plaintext block replacing the ESB that had encapsulated it.
>    The security-source and security-destination (if present) are removed
>    from the EID list, and any remaining entries are copied to the
>    recovered plaintext block.
> 
> 
> 
> Section 4.4,pg.50 says:
> 
>    Subsequent ESBs MUST contain a correlator value to link them to the
>    first ESB.  Security-source and security-destination are implied from
>    the first ESB; however, see the discussion in Section 2.4 concerning
>    EID-list entries.  Subsequent ESBs MUST contain security-parameters
>    and security-result fields as follows:
> 
> It should say:
> 
>    Subsequent ESBs MUST contain a correlator value to link them to the
>    first ESB.  Security-source and security-destination are implied from
>    the first ESB; however, see the discussion in Section 2.5 concerning
>    EID-list entries.  Subsequent ESBs MUST contain security-parameters
>    and security-result fields as follows:
> 
> 
> 
> Section 2.5,pg.21 says:
> 
>    The ESB is placed in the bundle in the same position as the block
>    being protected.  That is, the entire original block is processed
>    (encrypted, etc.) and encapsulated in a "replacing" ESB-type block,
>    and this appears in the bundle at the same sequential position as the
>    original block.  The processed data is placed in the security-result
>    field.
> 
> It should say:
> 
>    The ESB is placed in the bundle in the same position as the block
>    being protected.  That is, the entire original block is processed
>    (encrypted, etc.) and encapsulated in a "replacing" ESB-type block,
>    and this appears in the bundle at the same sequential position as the
>    original block.  The processed data is placed in the security-result
>    field.
> 
>    Any existing EID-list in the to-be-encapsulated original block
>    remains exactly as-is, and is copied to the EID-list for the
>    replacing block.  The encapsulation process MUST NOT replace or
>    remove the existing EID-list entries.  This is critically important
>    for correct updating of entries at the security-destination. The
>    EID-list copied into the replacing block MAY be preceded by EID
>    references for the security-source and security-destination.
> 
> 
> _______________________________________________
> dtn-security mailing list
> dtn-security@irtf.org
> https://www.irtf.org/mailman/listinfo/dtn-security
> 
>