From ahennes1@math.umd.edu Mon Sep 3 06:05:31 2012 Return-Path: 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 E551B21F8540 for ; Mon, 3 Sep 2012 06:05:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] 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 dxsT9vnELOd5 for ; Mon, 3 Sep 2012 06:05:28 -0700 (PDT) Received: from mailfilter.ece.umd.edu (mailfilter.ece.umd.edu [129.2.90.4]) by ietfa.amsl.com (Postfix) with ESMTP id A523721F853E for ; Mon, 3 Sep 2012 06:05:28 -0700 (PDT) X-ASG-Debug-ID: 1346677526-04739d1028244330001-NoPDhg Received: from svr4.math.umd.edu (svr4.math.umd.edu [129.2.56.14]) by mailfilter.ece.umd.edu with ESMTP id hlUHYyTMQEB4F6po; Mon, 03 Sep 2012 09:05:26 -0400 (EDT) X-Barracuda-Envelope-From: ahennes1@math.umd.edu X-Barracuda-Apparent-Source-IP: 129.2.56.14 Received: by svr4.math.umd.edu (Postfix, from userid 48) id 0AA3C6FC83; Mon, 3 Sep 2012 09:05:25 -0400 (EDT) Received: from 69.243.25.71 by webmail.math.umd.edu with HTTP; Mon, 3 Sep 2012 09:05:25 -0400 Message-ID: In-Reply-To: <20120824185650.1151428911@smtp.mail.me.com> References: <20120821141321.215374808@smtp.mail.me.com> <97735113a72c3d32d66ca834c84ff8a4.squirrel@webmail.math.umd.edu> <20120824185650.1151428911@smtp.mail.me.com> Date: Mon, 3 Sep 2012 09:05:25 -0400 From: ahennes1@math.umd.edu X-ASG-Orig-Subj: Re: Issue implementing security source/destination with ESB blocks To: "Peter Lovell" , dtn-security@irtf.org User-Agent: SquirrelMail/1.4.20 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Barracuda-Connect: svr4.math.umd.edu[129.2.56.14] X-Barracuda-Start-Time: 1346677526 X-Barracuda-URL: http://mailfilter.ece.umd.edu:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at ece.umd.edu X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=7.0 KILL_LEVEL=1000.0 tests=NO_REAL_NAME X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.107488 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 NO_REAL_NAME From: does not include a real name 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2012 13:05:32 -0000 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. From ahennes1@math.umd.edu Mon Sep 3 06:16:51 2012 Return-Path: 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 83D9B21F8557 for ; Mon, 3 Sep 2012 06:16:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.299 X-Spam-Level: X-Spam-Status: No, score=-5.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 FNhEB4395qsw for ; Mon, 3 Sep 2012 06:16:51 -0700 (PDT) Received: from mailfilter.ece.umd.edu (mailfilter.ece.umd.edu [129.2.90.4]) by ietfa.amsl.com (Postfix) with ESMTP id ED09421F8555 for ; Mon, 3 Sep 2012 06:16:50 -0700 (PDT) X-ASG-Debug-ID: 1346678209-04739d1027244c80001-NoPDhg Received: from svr4.math.umd.edu (svr4.math.umd.edu [129.2.56.14]) by mailfilter.ece.umd.edu with ESMTP id 0mPRT84jEgrkj8a7; Mon, 03 Sep 2012 09:16:49 -0400 (EDT) X-Barracuda-Envelope-From: ahennes1@math.umd.edu X-Barracuda-Apparent-Source-IP: 129.2.56.14 Received: by svr4.math.umd.edu (Postfix, from userid 48) id D2F4C6FC83; Mon, 3 Sep 2012 09:16:49 -0400 (EDT) Received: from 69.243.25.71 by webmail.math.umd.edu with HTTP; Mon, 3 Sep 2012 09:16:49 -0400 Message-ID: <279c4cc191e03bc0e78fac8ce45954ad.squirrel@webmail.math.umd.edu> Date: Mon, 3 Sep 2012 09:16:49 -0400 From: ahennes1@math.umd.edu X-ASG-Orig-Subj: Expiring Internet-Drafts To: dtn-security@irtf.org, kwburgi@tycho.ncsc.mil User-Agent: SquirrelMail/1.4.20 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Barracuda-Connect: svr4.math.umd.edu[129.2.56.14] X-Barracuda-Start-Time: 1346678209 X-Barracuda-URL: http://mailfilter.ece.umd.edu:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at ece.umd.edu X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=7.0 KILL_LEVEL=1000.0 tests=NO_REAL_NAME X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.107488 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 NO_REAL_NAME From: does not include a real name Subject: [dtn-security] Expiring Internet-Drafts X-BeenThere: dtn-security@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Security." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2012 13:16:51 -0000 Our drafts will be expiring soon, and we haven't received any feedback on them: http://tools.ietf.org/html/draft-hennessy-bsp-suiteb-profile-00 http://tools.ietf.org/html/draft-hennessy-bsp-suiteb-ciphersuites-00 We think they're completed, so if we don't get any feedback we'll ask the chairs to do a last-call and proceed. Thanks, Angela From stephen.farrell@cs.tcd.ie Mon Sep 3 06:35:35 2012 Return-Path: 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 ; 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 ; 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 ; 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 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: <20120821141321.215374808@smtp.mail.me.com> <97735113a72c3d32d66ca834c84ff8a4.squirrel@webmail.math.umd.edu> <20120824185650.1151428911@smtp.mail.me.com> In-Reply-To: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 > > From ahennes1@math.umd.edu Mon Sep 3 06:38:52 2012 Return-Path: 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 988A521F8575 for ; Mon, 3 Sep 2012 06:38:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 FPuimZ-L9R43 for ; Mon, 3 Sep 2012 06:38:52 -0700 (PDT) Received: from mailfilter.ece.umd.edu (mailfilter.ece.umd.edu [129.2.90.4]) by ietfa.amsl.com (Postfix) with ESMTP id 1E82621F856D for ; Mon, 3 Sep 2012 06:38:52 -0700 (PDT) X-ASG-Debug-ID: 1346679530-04739d10282459c0001-NoPDhg Received: from svr4.math.umd.edu (svr4.math.umd.edu [129.2.56.14]) by mailfilter.ece.umd.edu with ESMTP id KGt52sDcfBQDBbgD; Mon, 03 Sep 2012 09:38:50 -0400 (EDT) X-Barracuda-Envelope-From: ahennes1@math.umd.edu X-Barracuda-Apparent-Source-IP: 129.2.56.14 Received: by svr4.math.umd.edu (Postfix, from userid 48) id D6F5C6FC83; Mon, 3 Sep 2012 09:38:50 -0400 (EDT) Received: from 69.243.25.71 by webmail.math.umd.edu with HTTP; Mon, 3 Sep 2012 09:38:50 -0400 Message-ID: <2665b4bca07d1e0d3d9de88844cc02e9.squirrel@webmail.math.umd.edu> Date: Mon, 3 Sep 2012 09:38:50 -0400 From: ahennes1@math.umd.edu X-ASG-Orig-Subj: Implementing Security Destinations in DTN2 To: dtn-security@irtf.org User-Agent: SquirrelMail/1.4.20 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Barracuda-Connect: svr4.math.umd.edu[129.2.56.14] X-Barracuda-Start-Time: 1346679530 X-Barracuda-URL: http://mailfilter.ece.umd.edu:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at ece.umd.edu X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=7.0 KILL_LEVEL=1000.0 tests=BSF_SC0_MISMATCH_TO, NO_REAL_NAME X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.107490 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 NO_REAL_NAME From: does not include a real name 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header Subject: [dtn-security] Implementing Security Destinations in DTN2 X-BeenThere: dtn-security@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Security." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2012 13:38:52 -0000 We're working on adding support for defining security source/destinations in DTN2 (which could be different than the bundle src/dest). This raised the issue of whether or not we should route the bundle to the security destination (if defined), rather than the bundle destination. If we don't route the bundle through the security dest, then it may be discarded at the bundle dest if it did not pass through the security dest in transit. There are also some practical issues that are raised. There can be a security destination for PIB/PCB, and a (possibly different) security dest for ESB, and we'd have to decide which one to choose. Also, the routers in DTN2 access the bundle destination themselves, i.e. bundle->dest(). They would each have to be corrected to use some other value. Any comments/feedback would be appreciated. thanks, Angela From ianglennon@gmail.com Mon Sep 3 09:54:59 2012 Return-Path: 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 69A5421F8419 for ; Mon, 3 Sep 2012 09:54:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 bAIG-XT5Q9UX for ; Mon, 3 Sep 2012 09:54:58 -0700 (PDT) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by ietfa.amsl.com (Postfix) with ESMTP id 4712D21F866D for ; Mon, 3 Sep 2012 09:54:58 -0700 (PDT) Received: by lbbgg13 with SMTP id gg13so3229007lbb.13 for ; Mon, 03 Sep 2012 09:54:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=AHzJXvlstqezB/+F/iC9a8r+yJDTeB42KJhjnPeX5ao=; b=jZFMXYFLXQN4j4pauQvfSxvmNrPiRFakz+BIEkHAe7g/ybz2COOImcMy/jd2pofoI7 KlHzm/V38/l1pnhCxXovxDAOXEVD34lXSImBhSyJf4EnEgWsHb+3EmW5cLkC0kmG9WbU Vijdjmw0SUPjPKYd6/vcLVlB1iX2525boY4xn4FphFux4gRss7Q2MFQS9jWeIRGL3Qp9 ufDBU0hoBQCL8NcLpfSx4Gx8SES6g9jbnTqDLCmPEffRhKDliVlVwBOFHSwsVht8zTkq A/fov04POOMsfVu7FLfLiWrFx0Chz5RIVaVMkW5NUv35xQ8TjyaEMvMRF7KCtH4zYicC NkZA== MIME-Version: 1.0 Received: by 10.152.146.169 with SMTP id td9mr14367962lab.42.1346691297102; Mon, 03 Sep 2012 09:54:57 -0700 (PDT) Received: by 10.112.37.9 with HTTP; Mon, 3 Sep 2012 09:54:56 -0700 (PDT) In-Reply-To: <2665b4bca07d1e0d3d9de88844cc02e9.squirrel@webmail.math.umd.edu> References: <2665b4bca07d1e0d3d9de88844cc02e9.squirrel@webmail.math.umd.edu> Date: Mon, 3 Sep 2012 17:54:56 +0100 Message-ID: From: Ian Glennon To: dtn-security@irtf.org Content-Type: multipart/alternative; boundary=e89a8f23458962cc5b04c8cf006b Cc: ahennes1@math.umd.edu Subject: Re: [dtn-security] Implementing Security Destinations in DTN2 X-BeenThere: dtn-security@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Security." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2012 16:54:59 -0000 --e89a8f23458962cc5b04c8cf006b Content-Type: text/plain; charset=ISO-8859-1 If the security destination did not handle the bundle would the bundle payload not still be encrypted, or sigs needing verification? If the security dest is defined then it should be preferred simply because the contents have not yet been handled (data not decrypted, sigs not verified, etc) and the payload would be useless or untrusted, but would the bundle dest not forward it on to the security dest anyway so that the operations can be completed? The final bundle can then be sent on to the bundle destination, assuming of course that it is different to the security destination. /2p Ian On 3 September 2012 14:38, wrote: > We're working on adding support for defining security source/destinations > in DTN2 (which could be different than the bundle src/dest). > > This raised the issue of whether or not we should route the bundle to the > security destination (if defined), rather than the bundle destination. If > we don't route the bundle through the security dest, then it may be > discarded at the bundle dest if it did not pass through the security dest > in transit. > > There are also some practical issues that are raised. There can be a > security destination for PIB/PCB, and a (possibly different) security dest > for ESB, and we'd have to decide which one to choose. > > Also, the routers in DTN2 access the bundle destination themselves, i.e. > bundle->dest(). They would each have to be corrected to use some other > value. > > > Any comments/feedback would be appreciated. > > > thanks, > Angela > _______________________________________________ > dtn-security mailing list > dtn-security@irtf.org > https://www.irtf.org/mailman/listinfo/dtn-security > --e89a8f23458962cc5b04c8cf006b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable If the security destination did not handle the bundle would the bundle payl= oad not still be encrypted, or sigs needing verification?=A0

If the= security dest is defined then it should be preferred simply because the co= ntents have not yet been handled (data not decrypted, sigs not verified, et= c) and the payload would be useless or untrusted, but would the bundle dest= not forward it on to the security dest anyway so that the operations can b= e completed?=A0

The final bundle can then be sent on to the bundle destination, assumin= g of course that it is different to the security destination.

/2p
Ian

On 3 September 2012 14:38, <ahennes1@math.umd.edu> wrote:
We're working on adding support for defi= ning security source/destinations
in DTN2 (which could be different than the bundle src/dest).

This raised the issue of whether or not we should route the bundle to the security destination (if defined), rather than the bundle destination. If we don't route the bundle through the security dest, then it may be
discarded at the bundle dest if it did not pass through the security dest in transit.

There are also some practical issues that are raised. There can be a
security destination for PIB/PCB, and a (possibly different) security dest<= br> for ESB, and we'd have to decide which one to choose.

Also, the routers in DTN2 access the bundle destination themselves, i.e. bundle->dest(). They would each have to be corrected to use some other value.


Any comments/feedback would be appreciated.


thanks,
Angela
_______________________________________________
dtn-security mailing list
dtn-security@irtf.org
https://www.irtf.org/mailman/listinfo/dtn-security

--e89a8f23458962cc5b04c8cf006b-- From plovell@mac.com Tue Sep 4 10:25:03 2012 Return-Path: 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 20DC621E804E for ; Tue, 4 Sep 2012 10:25:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 COlelToGRFYK for ; Tue, 4 Sep 2012 10:25:02 -0700 (PDT) Received: from st11p00mm-asmtp003.mac.com (st11p00mm-asmtpout003.mac.com [17.172.81.2]) by ietfa.amsl.com (Postfix) with ESMTP id 2FAD211E809A for ; Tue, 4 Sep 2012 10:25:01 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from [192.168.76.196] (static-96-244-17-67.bltmmd.fios.verizon.net [96.244.17.67]) by st11p00mm-asmtp003.mac.com (Oracle Communications Messaging Server 7u4-23.01(7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTPSA id <0M9U00GIT5PNCV30@st11p00mm-asmtp003.mac.com> for dtn-security@irtf.org; Tue, 04 Sep 2012 17:25:00 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.7.7855,1.0.431,0.0.0000 definitions=2012-09-04_06:2012-09-04, 2012-09-04, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1203120001 definitions=main-1209040169 From: Peter Lovell To: ahennes1@math.umd.edu, dtn-security@irtf.org Date: Tue, 04 Sep 2012 13:24:58 -0400 Message-id: <20120904172458.1767559740@smtp.mail.me.com> In-reply-to: <2665b4bca07d1e0d3d9de88844cc02e9.squirrel@webmail.math.umd.edu> References: <2665b4bca07d1e0d3d9de88844cc02e9.squirrel@webmail.math.umd.edu> X-Mailer: CTM PowerMail version 6.1.3 build 4650 English (intel) Subject: Re: [dtn-security] Implementing Security Destinations in DTN2 X-BeenThere: dtn-security@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Security." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2012 17:25:03 -0000 >We're working on adding support for defining security source/destinations >in DTN2 (which could be different than the bundle src/dest). > >This raised the issue of whether or not we should route the bundle to the >security destination (if defined), rather than the bundle destination. If >we don't route the bundle through the security dest, then it may be >discarded at the bundle dest if it did not pass through the security dest >in transit. > >There are also some practical issues that are raised. There can be a >security destination for PIB/PCB, and a (possibly different) security dest >for ESB, and we'd have to decide which one to choose. > >Also, the routers in DTN2 access the bundle destination themselves, i.e. >bundle->dest(). They would each have to be corrected to use some other >value. > Hi Angela, a problem indeed! We did discuss this during development of BSP ... >Specification of a security-destination other than the bundle- >destination creates a routing requirement that the bundle somehow be >directed to the security-destination node on its way to the final >destination. This requirement is presently private to the >ciphersuite, since routing nodes are not required to implement >security processing. At one point I suggested that addition of PCB should adjust the bundle-dest to be the new security-dest, saving the previous bundle-dest for later restoration. This would certainly cause the bundle to be properly processed with regard to decryption. Although there might be other side-effects, no-one proposed any, however the plan was not adopted. The "nesting" characteristic of PCBs would mean that nodes were visited in correct order in the case of super-encryption. I am not sure how this might interact with ESBs. I think that adopting the same approach (use security-dest as bundle-dest, save bundle-dest for later restoration) should work and produce a correct result. However I will admit that I haven't pondered the ESB/PCB interaction very much. I think it should "just work". There might be other ways to adjust routing to ensure that the bundle visits the appropriate nodes. But those would require extensive changes to both BP and routing schemes -- neither of which seem likely. So the push/pop idea for bundle-dest seems to be the only realistic solution. Of course, there needs to be an EID-ref maintained in an EID-list somewhere so that dictionary compression/adjustment doesn't break things. That would be something like the plan for the list in the ESB. Cheers.....Peter From scott.c.burleigh@jpl.nasa.gov Wed Sep 5 07:43:30 2012 Return-Path: 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 80DDF21F84E4 for ; Wed, 5 Sep 2012 07:43:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 JDZiQXidejC8 for ; Wed, 5 Sep 2012 07:43:29 -0700 (PDT) Received: from mail.jpl.nasa.gov (sentrion3.jpl.nasa.gov [128.149.139.109]) by ietfa.amsl.com (Postfix) with ESMTP id CE0B721F84D3 for ; Wed, 5 Sep 2012 07:43:29 -0700 (PDT) Received: from mail.jpl.nasa.gov (ap-ehub-sp01.jpl.nasa.gov [128.149.137.148]) by smtp.jpl.nasa.gov (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q85EhSbl009908 (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits) verified NO); Wed, 5 Sep 2012 07:43:28 -0700 Received: from AP-EMBX-SP20.RES.AD.JPL ([169.254.8.34]) by ap-ehub-sp01.RES.AD.JPL ([169.254.3.211]) with mapi id 14.02.0298.004; Wed, 5 Sep 2012 07:43:28 -0700 From: "Burleigh, Scott C (313B)" To: Peter Lovell , "ahennes1@math.umd.edu" , "dtn-security@irtf.org" Thread-Topic: [dtn-security] Implementing Security Destinations in DTN2 Thread-Index: AQHNidl408x5VPurU0S61vNwFESAMJd65g8AgADr4cA= Date: Wed, 5 Sep 2012 14:43:27 +0000 Message-ID: References: <2665b4bca07d1e0d3d9de88844cc02e9.squirrel@webmail.math.umd.edu> <20120904172458.1767559740@smtp.mail.me.com> In-Reply-To: <20120904172458.1767559740@smtp.mail.me.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.149.137.26] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Source-Sender: scott.c.burleigh@jpl.nasa.gov X-AUTH: Authorized X-Mailman-Approved-At: Wed, 05 Sep 2012 07:56:36 -0700 Subject: Re: [dtn-security] Implementing Security Destinations in DTN2 X-BeenThere: dtn-security@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Security." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 14:43:30 -0000 Actually ION exercises something like this push/pop mechanism, internally, = in route computation, and I suspect other implementations do it as well: in= the course of computing the route to the final destination, the forwarder = may select an interim endpoint to forward the bundle to and may then re-ent= er route computation in order to figure out how to route the bundle to that= interim endpoint. So long as all the routers along the path follow the sa= me strategy, there's no need to record the interim endpoint in the bundle; = it's an internal procedure. None of the ION forwarders currently pay attention to security destinations= when computing routes, so security destinations are never chosen as interi= m endpoints, but that modification seems plausible. You'd want to be sure = that the block citing a given security destination was always removed as so= on as the bundle arrives at that destination, though, and we would want som= e sort of extension block ordering convention (or whatever) for nesting sec= urity destinations in a standardized way. Scott -----Original Message----- From: dtn-security-bounces@irtf.org [mailto:dtn-security-bounces@irtf.org] = On Behalf Of Peter Lovell Sent: Tuesday, September 04, 2012 10:25 AM To: ahennes1@math.umd.edu; dtn-security@irtf.org Subject: Re: [dtn-security] Implementing Security Destinations in DTN2 >We're working on adding support for defining security=20 >source/destinations in DTN2 (which could be different than the bundle src/= dest). > >This raised the issue of whether or not we should route the bundle to=20 >the security destination (if defined), rather than the bundle=20 >destination. If we don't route the bundle through the security dest,=20 >then it may be discarded at the bundle dest if it did not pass through=20 >the security dest in transit. > >There are also some practical issues that are raised. There can be a=20 >security destination for PIB/PCB, and a (possibly different) security=20 >dest for ESB, and we'd have to decide which one to choose. > >Also, the routers in DTN2 access the bundle destination themselves, i.e. >bundle->dest(). They would each have to be corrected to use some other >value. > Hi Angela, a problem indeed! We did discuss this during development of BSP ... >Specification of a security-destination other than the bundle-=20 >destination creates a routing requirement that the bundle somehow be=20 >directed to the security-destination node on its way to the final=20 >destination. This requirement is presently private to the ciphersuite,=20 >since routing nodes are not required to implement security processing. At one point I suggested that addition of PCB should adjust the bundle-dest= to be the new security-dest, saving the previous bundle-dest for later res= toration. This would certainly cause the bundle to be properly processed wi= th regard to decryption. Although there might be other side-effects, no-one= proposed any, however the plan was not adopted. The "nesting" characterist= ic of PCBs would mean that nodes were visited in correct order in the case = of super-encryption. I am not sure how this might interact with ESBs. I think that adopting the = same approach (use security-dest as bundle-dest, save bundle-dest for later= restoration) should work and produce a correct result. However I will admi= t that I haven't pondered the ESB/PCB interaction very much. I think it sho= uld "just work". There might be other ways to adjust routing to ensure that the bundle visit= s the appropriate nodes. But those would require extensive changes to both = BP and routing schemes -- neither of which seem likely. So the push/pop ide= a for bundle-dest seems to be the only realistic solution. Of course, there= needs to be an EID-ref maintained in an EID-list somewhere so that diction= ary compression/adjustment doesn't break things. That would be something li= ke the plan for the list in the ESB. Cheers.....Peter _______________________________________________ dtn-security mailing list dtn-security@irtf.org https://www.irtf.org/mailman/listinfo/dtn-security From ahennes1@math.umd.edu Wed Sep 5 13:56:44 2012 Return-Path: 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 8CEE921F86D4 for ; Wed, 5 Sep 2012 13:56:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.185 X-Spam-Level: X-Spam-Status: No, score=-4.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, RCVD_IN_DNSWL_MED=-4] 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 OShtIgQ2dJTX for ; Wed, 5 Sep 2012 13:56:43 -0700 (PDT) Received: from mailfilter.ece.umd.edu (mailfilter.ece.umd.edu [129.2.90.4]) by ietfa.amsl.com (Postfix) with ESMTP id 319FA21F86B7 for ; Wed, 5 Sep 2012 13:56:43 -0700 (PDT) X-ASG-Debug-ID: 1346878601-04739d1032a50d0001-NoPDhg Received: from svr4.math.umd.edu ([129.2.56.14]) by mailfilter.ece.umd.edu with ESMTP id iSe29kh3OiFGz608; Wed, 05 Sep 2012 16:56:41 -0400 (EDT) X-Barracuda-Envelope-From: ahennes1@math.umd.edu X-Barracuda-Apparent-Source-IP: 129.2.56.14 Received: by svr4.math.umd.edu (Postfix, from userid 48) id 702866FC83; Wed, 5 Sep 2012 16:56:41 -0400 (EDT) Received: from 65.127.220.136 by webmail.math.umd.edu with HTTP; Wed, 5 Sep 2012 16:56:41 -0400 Message-ID: <6af37e4869b76826d4d2108e3eef82b3.squirrel@webmail.math.umd.edu> In-Reply-To: References: <2665b4bca07d1e0d3d9de88844cc02e9.squirrel@webmail.math.umd.edu> <20120904172458.1767559740@smtp.mail.me.com> Date: Wed, 5 Sep 2012 16:56:41 -0400 From: ahennes1@math.umd.edu X-ASG-Orig-Subj: RE: [dtn-security] Implementing Security Destinations in DTN2 To: "Burleigh, Scott C (313B)" User-Agent: SquirrelMail/1.4.20 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Barracuda-Connect: UNKNOWN[129.2.56.14] X-Barracuda-Start-Time: 1346878601 X-Barracuda-URL: http://mailfilter.ece.umd.edu:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at ece.umd.edu X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=7.0 KILL_LEVEL=1000.0 tests=BSF_SC0_MISMATCH_TO, NO_REAL_NAME X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.107710 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 NO_REAL_NAME From: does not include a real name 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header Cc: "dtn-security@irtf.org" Subject: Re: [dtn-security] Implementing Security Destinations in DTN2 X-BeenThere: dtn-security@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Security." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 20:56:44 -0000 I think this push/pop idea makes the most sense of anything we've talked about. It seems like it would require some modification to the spec, however, and maybe a flag to set when the bundle-dest is being stored somewhere. Thanks, Angela > Actually ION exercises something like this push/pop mechanism, internally, > in route computation, and I suspect other implementations do it as well: > in the course of computing the route to the final destination, the > forwarder may select an interim endpoint to forward the bundle to and may > then re-enter route computation in order to figure out how to route the > bundle to that interim endpoint. So long as all the routers along the > path follow the same strategy, there's no need to record the interim > endpoint in the bundle; it's an internal procedure. > > None of the ION forwarders currently pay attention to security > destinations when computing routes, so security destinations are never > chosen as interim endpoints, but that modification seems plausible. You'd > want to be sure that the block citing a given security destination was > always removed as soon as the bundle arrives at that destination, though, > and we would want some sort of extension block ordering convention (or > whatever) for nesting security destinations in a standardized way. > > Scott > > -----Original Message----- > From: dtn-security-bounces@irtf.org [mailto:dtn-security-bounces@irtf.org] > On Behalf Of Peter Lovell > Sent: Tuesday, September 04, 2012 10:25 AM > To: ahennes1@math.umd.edu; dtn-security@irtf.org > Subject: Re: [dtn-security] Implementing Security Destinations in DTN2 > >>We're working on adding support for defining security >>source/destinations in DTN2 (which could be different than the bundle >> src/dest). >> >>This raised the issue of whether or not we should route the bundle to >>the security destination (if defined), rather than the bundle >>destination. If we don't route the bundle through the security dest, >>then it may be discarded at the bundle dest if it did not pass through >>the security dest in transit. >> >>There are also some practical issues that are raised. There can be a >>security destination for PIB/PCB, and a (possibly different) security >>dest for ESB, and we'd have to decide which one to choose. >> >>Also, the routers in DTN2 access the bundle destination themselves, i.e. >>bundle->dest(). They would each have to be corrected to use some other >>value. >> > > > Hi Angela, > > a problem indeed! We did discuss this during development of BSP ... > >>Specification of a security-destination other than the bundle- >>destination creates a routing requirement that the bundle somehow be >>directed to the security-destination node on its way to the final >>destination. This requirement is presently private to the ciphersuite, >>since routing nodes are not required to implement security processing. > > At one point I suggested that addition of PCB should adjust the > bundle-dest to be the new security-dest, saving the previous bundle-dest > for later restoration. This would certainly cause the bundle to be > properly processed with regard to decryption. Although there might be > other side-effects, no-one proposed any, however the plan was not adopted. > The "nesting" characteristic of PCBs would mean that nodes were visited in > correct order in the case of super-encryption. > > I am not sure how this might interact with ESBs. I think that adopting the > same approach (use security-dest as bundle-dest, save bundle-dest for > later restoration) should work and produce a correct result. However I > will admit that I haven't pondered the ESB/PCB interaction very much. I > think it should "just work". > > There might be other ways to adjust routing to ensure that the bundle > visits the appropriate nodes. But those would require extensive changes to > both BP and routing schemes -- neither of which seem likely. So the > push/pop idea for bundle-dest seems to be the only realistic solution. Of > course, there needs to be an EID-ref maintained in an EID-list somewhere > so that dictionary compression/adjustment doesn't break things. That would > be something like the plan for the list in the ESB. > > Cheers.....Peter > > > > > > > _______________________________________________ > dtn-security mailing list > dtn-security@irtf.org > https://www.irtf.org/mailman/listinfo/dtn-security > From plovell@mac.com Wed Sep 5 21:36:59 2012 Return-Path: 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 EAC3121F851C for ; Wed, 5 Sep 2012 21:36:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 1nZ+6qZqkEMM for ; Wed, 5 Sep 2012 21:36:59 -0700 (PDT) Received: from st11p00mm-asmtp003.mac.com (st11p00mm-asmtp003.mac.com [17.172.81.2]) by ietfa.amsl.com (Postfix) with ESMTP id 632BE21F851B for ; Wed, 5 Sep 2012 21:36:59 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from [192.168.1.98] (pool-96-255-127-40.washdc.fios.verizon.net [96.255.127.40]) by st11p00mm-asmtp003.mac.com (Oracle Communications Messaging Server 7u4-23.01(7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTPSA id <0M9W00KV1VHLSK50@st11p00mm-asmtp003.mac.com> for dtn-security@irtf.org; Thu, 06 Sep 2012 04:36:58 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.7.7855,1.0.431,0.0.0000 definitions=2012-09-06_01:2012-09-06, 2012-09-06, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1203120001 definitions=main-1209050364 From: Peter Lovell To: ahennes1@math.umd.edu, Scott Burleigh Date: Thu, 06 Sep 2012 00:36:56 -0400 Message-id: <20120906043656.504416340@smtp.mail.me.com> In-reply-to: <6af37e4869b76826d4d2108e3eef82b3.squirrel@webmail.math.umd.edu> References: <2665b4bca07d1e0d3d9de88844cc02e9.squirrel@webmail.math.umd.edu> <20120904172458.1767559740@smtp.mail.me.com> <6af37e4869b76826d4d2108e3eef82b3.squirrel@webmail.math.umd.edu> X-Mailer: CTM PowerMail version 6.1.3 build 4650 English (intel) Cc: dtn-security@irtf.org Subject: [dtn-security] Re(2): Implementing Security Destinations in DTN2 X-BeenThere: dtn-security@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Security." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 04:37:00 -0000 On Thu, Sep 12, 2013, ahennes1@math.umd.edu wrote: >I think this push/pop idea makes the most sense of anything we've talked >about. It seems like it would require some modification to the spec, >however, and maybe a flag to set when the bundle-dest is being stored >somewhere. Hi Angela, it would if it were to be general for all PC and ES ciphersuites. On the other hand, one could define one's own ciphersuite that worked this way and have no impact on anything else, I believe. The general solution is to be greatly preferred but, as Stephen noted, it's way to big for an erratum. I am pleased to hear from Scott that ION uses a mechanism along these lines. HIs concern about removal of the address-change-block is a valid one but will not be a problem in our case as we would (a)use the security block to hold the reference, and (b)push/pop the address simultaneous with add/delete of the security block (i.e. encrypt/decrypt). Cheers.....Peter From plovell@mac.com Sat Sep 22 18:22:19 2012 Return-Path: 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 E1E5B21F8512 for ; Sat, 22 Sep 2012 18:22:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 WX8xCGq0h+5l for ; Sat, 22 Sep 2012 18:22:18 -0700 (PDT) Received: from st11p00mm-asmtp004.mac.com (st11p00mm-asmtpout004.mac.com [17.172.81.3]) by ietfa.amsl.com (Postfix) with ESMTP id C849621F84D5 for ; Sat, 22 Sep 2012 18:22:18 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from [192.168.1.98] (pool-96-255-127-40.washdc.fios.verizon.net [96.255.127.40]) by st11p00mm-asmtp004.mac.com (Oracle Communications Messaging Server 7u4-23.01(7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTPSA id <0MAS005J53T20F80@st11p00mm-asmtp004.mac.com> for dtn-security@irtf.org; Sun, 23 Sep 2012 01:22:18 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.7.7855,1.0.431,0.0.0000 definitions=2012-09-22_04:2012-09-21, 2012-09-22, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1203120001 definitions=main-1209220381 From: Peter Lovell To: ahennes1@math.umd.edu, Scott Burleigh Date: Sat, 22 Sep 2012 21:22:12 -0400 Message-id: <20120923012212.319238544@smtp.mail.me.com> In-reply-to: <6af37e4869b76826d4d2108e3eef82b3.squirrel@webmail.math.umd.edu> References: <2665b4bca07d1e0d3d9de88844cc02e9.squirrel@webmail.math.umd.edu> <20120904172458.1767559740@smtp.mail.me.com> <6af37e4869b76826d4d2108e3eef82b3.squirrel@webmail.math.umd.edu> X-Mailer: CTM PowerMail version 6.1.3 build 4650 English (intel) Cc: dtn-security@irtf.org Subject: [dtn-security] Re(2): Implementing Security Destinations in DTN2 X-BeenThere: dtn-security@irtf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Security." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Sep 2012 01:22:20 -0000 Hi Scott and Angela, I said some messages ago that I hadn't thought about this too much but expected it to "just work". I've thought about it some more, and the more I do, the less attractive it is. The scenario I had in mind with my earlier comment is a suitable one but unfortunately it's about the only one. Let me first set some context to help my description. Assume we have a DTN S -- GA -- I1 -- I2 -- GB -- D \ / | \- I3 -- GC -- E S and D are source and destination on controlled-access networks E is a node on another controlled-access network, with a slow link to D GA, GB and GC are gateway devices between those networks and an open network I1, I2 and I3 are intermediate nodes in the open network Assume also that there may be alternate, but similar, paths between S and D. If GA's security rules require traffic to D to be protected across the open network, it will encrypt it using PCB with GB as security-dest. It will use GB as security-dest, rather than D, because it doesn't want the keys to be distributed any more widely than necessary. I realize that cool key-distribution schemes can ameliorate this problem but I'm imagining this to be a network subject to delays and/or bandwidth constraints, so GA and GB have been established with paired keys. GA also has a GA-GC keypair for sending bundles to E. In this scenario, the bundle from S, gatewayed though GA must be sent via GB so it can be decrypted there and sent on its way. If node I1 finds that node I2 is slow/down/whatever, it might decide to route the bundle through I3. I3 does not know the details of the controlled-access networks but knows that GC can get it to D. So I3 sends it that way and the bundle arrives at D, still encrypted. A good solution for this problem is for GA to specify GB as the [temporary] bundle-dest so that I1/I2/I3 will be forced to route it there. This obviously requires that GA save the real bundle-dest somewhere TBD so that GB can restore it. This will work even in the case of super-encryption, as the PCB nesting rules force the push/pop operations to be match correctly. So the idea works well for this case. Thinking now about PIB, it seems to me that the public key needed to verify the bundle will not be very secret. In fact, I have yet to be convinced of any utility at all for a specific security-dest in the case of PIB. Any intermediate node should be able to verify the integrity of a bundle. So now let's think about ESBs. For the reason mentioned above, an integrity check on an extension block seems to be a non-issue -- any node should be able to verify integrity. Which leaves the matter of confidentiality for an extension block. Now, I see the issue of confidentiality for an extension block as quite separate from that for the payload. Over the years we've discussed various scenarios where routing and search actions might be performed on metadata, so that some metadata would be available through keys that were known more widely than those for the payload. For example, metadata might indicate that the payload was a map covering certain coordinates. Another metadata items might specify the times for which the map was valid. And the map payload would indicate the various unit dispositions at that time. The "coordinates" key might have broad distribution, the "time" key be more restricted and the payload key the most closely-held. But now I wonder about just what meaning we should attach to "security-dest" for an encryption ESB. In the scenario above, I would not expect that the ESB would ever be decrypted and the clear-text content be stored back in the bundle. Instead, it would be decrypted for immediate use but remain unchanged in the bundle. I'm sure there are other planned uses for extension blocks and it would be a help if we can craft a few sample use cases so we can think more fruitfully about this problem. This would really help, because I'm imagining horror scenarios where various nodes add an ESB and push the bundle-dest and the bundle routing suddenly goes very, very bad. PCB is OK because there's only one payload, and onion-layering enforces nesting. That's not the case for ESBs so things could go bad. To go back to Scott's comment - it does make sense if we can have some controls and sequencing on it. The push/pop scheme must have a single list and clearly-defined rules, and that means that PCB can't be allowed to do it on its own (unless it's forbidden to all others - not a good proposal). Doing anything of this kind will certainly require changes to 5050. I have heard occasional rumblings that there might be a revision to it so let's think about what we might want/need, and be ready with well-considered proposals. Regards.....Peter On Thu, Sep 12, 2013, ahennes1@math.umd.edu wrote: >I think this push/pop idea makes the most sense of anything we've talked >about. It seems like it would require some modification to the spec, >however, and maybe a flag to set when the bundle-dest is being stored >somewhere. > > >Thanks, >Angela > >> Actually ION exercises something like this push/pop mechanism, internally, >> in route computation, and I suspect other implementations do it as well: >> in the course of computing the route to the final destination, the >> forwarder may select an interim endpoint to forward the bundle to and may >> then re-enter route computation in order to figure out how to route the >> bundle to that interim endpoint. So long as all the routers along the >> path follow the same strategy, there's no need to record the interim >> endpoint in the bundle; it's an internal procedure. >> >> None of the ION forwarders currently pay attention to security >> destinations when computing routes, so security destinations are never >> chosen as interim endpoints, but that modification seems plausible. You'd >> want to be sure that the block citing a given security destination was >> always removed as soon as the bundle arrives at that destination, though, >> and we would want some sort of extension block ordering convention (or >> whatever) for nesting security destinations in a standardized way. >> >> Scott >> >> -----Original Message----- >> From: dtn-security-bounces@irtf.org [mailto:dtn-security-bounces@irtf.org] >> On Behalf Of Peter Lovell >> Sent: Tuesday, September 04, 2012 10:25 AM >> To: ahennes1@math.umd.edu; dtn-security@irtf.org >> Subject: Re: [dtn-security] Implementing Security Destinations in DTN2 >> >>>We're working on adding support for defining security >>>source/destinations in DTN2 (which could be different than the bundle >>> src/dest). >>> >>>This raised the issue of whether or not we should route the bundle to >>>the security destination (if defined), rather than the bundle >>>destination. If we don't route the bundle through the security dest, >>>then it may be discarded at the bundle dest if it did not pass through >>>the security dest in transit. >>> >>>There are also some practical issues that are raised. There can be a >>>security destination for PIB/PCB, and a (possibly different) security >>>dest for ESB, and we'd have to decide which one to choose. >>> >>>Also, the routers in DTN2 access the bundle destination themselves, i.e. >>>bundle->dest(). They would each have to be corrected to use some other >>>value. >>> >> >> >> Hi Angela, >> >> a problem indeed! We did discuss this during development of BSP ... >> >>>Specification of a security-destination other than the bundle- >>>destination creates a routing requirement that the bundle somehow be >>>directed to the security-destination node on its way to the final >>>destination. This requirement is presently private to the ciphersuite, >>>since routing nodes are not required to implement security processing. >> >> At one point I suggested that addition of PCB should adjust the >> bundle-dest to be the new security-dest, saving the previous bundle-dest >> for later restoration. This would certainly cause the bundle to be >> properly processed with regard to decryption. Although there might be >> other side-effects, no-one proposed any, however the plan was not adopted. >> The "nesting" characteristic of PCBs would mean that nodes were visited in >> correct order in the case of super-encryption. >> >> I am not sure how this might interact with ESBs. I think that adopting the >> same approach (use security-dest as bundle-dest, save bundle-dest for >> later restoration) should work and produce a correct result. However I >> will admit that I haven't pondered the ESB/PCB interaction very much. I >> think it should "just work". >> >> There might be other ways to adjust routing to ensure that the bundle >> visits the appropriate nodes. But those would require extensive changes to >> both BP and routing schemes -- neither of which seem likely. So the >> push/pop idea for bundle-dest seems to be the only realistic solution. Of >> course, there needs to be an EID-ref maintained in an EID-list somewhere >> so that dictionary compression/adjustment doesn't break things. That would >> be something like the plan for the list in the ESB. >> >> Cheers.....Peter >> >> >> >> >> >> >> _______________________________________________ >> dtn-security mailing list >> dtn-security@irtf.org >> https://www.irtf.org/mailman/listinfo/dtn-security >> >