From nobody Wed May 28 06:41:22 2014 Return-Path: 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 77D951A0993; Wed, 28 May 2014 06:41:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.853 X-Spam-Level: X-Spam-Status: No, score=-4.853 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 of7XMRLomfOY; Wed, 28 May 2014 06:41:16 -0700 (PDT) Received: from piper.jhuapl.edu (piper.jhuapl.edu [128.244.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECCA81A0149; Wed, 28 May 2014 06:41:15 -0700 (PDT) Received: from aplexcas1.dom1.jhuapl.edu (aplexcas1.dom1.jhuapl.edu [128.244.198.90]) by piper.jhuapl.edu with smtp (TLS: TLSv1/SSLv3,128bits,RC4-MD5) id 6b7a_394c_6e022f8f_d2bc_4891_8eee_4de3b2f39a1c; Wed, 28 May 2014 09:41:10 -0400 Received: from aplesfreedom.dom1.jhuapl.edu ([128.244.198.204]) by aplexcas1.dom1.jhuapl.edu ([128.244.198.90]) with mapi; Wed, 28 May 2014 09:40:07 -0400 From: "Birrane, Edward J." To: "dtn-interest@irtf.org" , "dtn-security@irtf.org" Date: Wed, 28 May 2014 09:40:06 -0400 Thread-Topic: Updated SBSP Document Thread-Index: Ac96egHBtIlHfqjpRHK8eG5est6OOQ== Message-ID: <329D879C76FDD04AAAE84BB1D89B3970094FBF9EAA@aplesfreedom.dom1.jhuapl.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dtn-security/vkAO9ccu_EsjiwpnOYkcubo2spE Subject: [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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 13:41:18 -0000 Good morning. I've released a new version of the Streamlined Bundle Security Protocol (SB= SP) document (see information below). This change incorporates comments received to date, including: - Minor spelling/grammar changes and text cleanup. - Expanded discussion on extension block identification (Section 2.1) - Clarified that a BIB may not be added to sign an encrypted block. (Sectio= n 2.7) - Clarified block processing order in Section 2.7. - Clarified BIB processing (Section 3.3.3) - Simplified bundle fragmentation discussion (Section 3.4) - Clarified interaction of authentication and reactive fragmentation. - Updated policy considerations. I am cross-posting to dtn-interest and dtn-security as an announcement, but= would ask that technical discussion occur on dtn-security. -Ed A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Delay-Tolerant Networking Research Group = Working Group of the IETF. Title : Streamlined Bundle Security Protocol Specificatio= n Author : Edward J. Birrane Filename : draft-irtf-dtnrg-sbsp-01.txt Pages : 34 Date : 2014-05-27 Abstract: This document defines a streamlined bundle security protocol, which provides data authentication, integrity, and confidentiality services for the Bundle Protocol. Capabilities are provided to protect the bundle payload, and additional data that may be included within the bundle, along a single path through a network. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-irtf-dtnrg-sbsp/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-irtf-dtnrg-sbsp-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-irtf-dtnrg-sbsp-01 --- Ed Birrane Principal Professional Staff, Space Department Johns Hopkins Applied Physics Laboratory (W) 443-778-7423 / (F) 443-228-3839 =A0=20 From nobody Thu May 29 12:09:16 2014 Return-Path: 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 DC0CF1A04F6 for ; Thu, 29 May 2014 12:09:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] 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 nl4hD5OKr_Cb for ; Thu, 29 May 2014 12:09:09 -0700 (PDT) Received: from ndjsnpf01.ndc.nasa.gov (ndjsnpf01.ndc.nasa.gov [IPv6:2001:4d0:a302:1100::101]) by ietfa.amsl.com (Postfix) with ESMTP id 40A2E1A0B72 for ; Thu, 29 May 2014 12:09:08 -0700 (PDT) Received: from ndmsppt103.ndc.nasa.gov (ndmsppt103.ndc.nasa.gov [198.117.0.68]) by ndjsnpf01.ndc.nasa.gov (Postfix) with ESMTP id 8021CD055D; Thu, 29 May 2014 14:03:39 -0500 (CDT) Received: from NDMSCHT115.ndc.nasa.gov (ndmscht115-pub.ndc.nasa.gov [198.117.0.215]) by ndmsppt103.ndc.nasa.gov (8.14.5/8.14.5) with ESMTP id s4TJ93Qm009392; Thu, 29 May 2014 14:09:03 -0500 Received: from NDMSMBX404.ndc.nasa.gov ([169.254.4.107]) by NDMSCHT115.ndc.nasa.gov ([198.117.0.215]) with mapi id 14.03.0174.001; Thu, 29 May 2014 14:09:03 -0500 From: "Zoller, David A. (MSFC-EO50)[HOSC SERVICES CONTRACT]" To: "Birrane, Edward J." , "dtn-security@irtf.org" Thread-Topic: Updated SBSP Document Thread-Index: Ac96egHBtIlHfqjpRHK8eG5est6OOQA736Hg Date: Thu, 29 May 2014 19:09:02 +0000 Message-ID: <94CFB3711B4CAE4DBFC5BEB3374BF0C60D1835@NDMSMBX404.ndc.nasa.gov> References: <329D879C76FDD04AAAE84BB1D89B3970094FBF9EAA@aplesfreedom.dom1.jhuapl.edu> In-Reply-To: <329D879C76FDD04AAAE84BB1D89B3970094FBF9EAA@aplesfreedom.dom1.jhuapl.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [198.119.225.34] Content-Type: multipart/alternative; boundary="_000_94CFB3711B4CAE4DBFC5BEB3374BF0C60D1835NDMSMBX404ndcnasa_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.96, 1.0.14, 0.0.0000 definitions=2014-05-29_06:2014-05-29,2014-05-29,1970-01-01 signatures=0 Archived-At: http://mailarchive.ietf.org/arch/msg/dtn-security/NvvaPFm3TSpOGXHEV-50SFXpBXM 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 19:09:15 -0000 --_000_94CFB3711B4CAE4DBFC5BEB3374BF0C60D1835NDMSMBX404ndcnasa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Ed, Good work - the SBSP spec continues to evolve nicely. I'll kick off the dis= cussions 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 of <0x00><0x00>. * Per 3.4 Bundle Fragmentation and Reassembly, bundle authenticatio= n 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 of <0x00> 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 can be used to determine that the = original fragmented bundle must be reassembled before authentication is che= cked 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 acce= pted [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 BC= B is the payload block which would need to be added if this is kept as a re= quirement. * 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 overhe= ad if included in every fragment 3. I do not see a benefit gained by including the block in every frag= ment i. Even the destination n= ode likely cannot decrypt any individual fragment except the first one and = it probably would only decrypt a partial bundle as a last resort or forens= ic function if the entire bundle was not received before expiration ii. Intermediate nodes shou= ldn't generally be poking around in bundle payloads anyway and no need to p= rovide 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 requi= rement - have any of the implementations found a need or benefit for this a= nd would it still apply in context of the SBSP? [Page 24] 3.1.2.3 Extension Block Canonicalization Endpoint ID references in blocks are canonicalized using the de- referenced text form in place of the reference pair. The reference count is not included, nor is the length of the endpoint ID text. The EID reference is, therefore, canonicalized as :, which includes the ":" character. * Need to include a statement to the effect: o Artificial EIDs as defined in this document (ssp reference is 0x00) mu= st be skipped and are not included in the canonicalization. [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 leng= th 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 her= e. o Personally, I would specify all SDNV values canonicalized as 8 byte va= lues 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. [Page 23] 3.1.2.2 Payload Block Canonicalization When canonicalizing the payload block, 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" bit. The "last block" bit 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. Payload blocks are canonicalized as-is, with the exception that, in some instances, only a portion of the payload data is to be protected. In such a case, only those bytes are included in the canonical form, and additional cipher suite parameters are required to specify which part of the payload is protected, as discussed further below. * The processing control flags are pulled out and masked so the Pay= load block can no longer be considered canonicalized "as-is". * A Payload Block is the same underlying format as an Extension Blo= ck with the restriction that the 'block contains an EID-reference field' is= never set and it should follow the same canonicalization methodology as th= at of the Extension Block o I propose a single "Non-Primary Block Canonicalization" section based = on the finalized version of the Extension Block Canonicalization [Page 26] 3.3.2 Receiving BCB Blocks If the relevant parts of an encrypted payload cannot be decrypted (i.e., the decryption key cannot be deduced or decryption fails), then the bundle MUST be discarded and processed no further; in this case, a bundle deletion status report (see [RFC5050]) indicating the decryption failure MAY be generated. * Does a new deletion reason code need to be defined? -----Original Message----- From: dtn-interest [mailto:dtn-interest-bounces@irtf.org] On Behalf Of Birr= ane, Edward J. Sent: Wednesday, May 28, 2014 8:40 AM To: dtn-interest@irtf.org; dtn-security@irtf.org Subject: [dtn-interest] Updated SBSP Document Good morning. I've released a new version of the Streamlined Bundle Security Protocol (SB= SP) document (see information below). This change incorporates comments received to date, including: - Minor spelling/grammar changes and text cleanup. - Expanded discussion on extension block identification (Section 2.1) - Clarified that a BIB may not be added to sign an encrypted block. (Sectio= n 2.7) - Clarified block processing order in Section 2.7. - Clarified BIB processing (Section 3.3.3) - Simplified bundle fragmentation discussion (Section 3.4) - Clarified interaction of authentication and reactive fragmentation. - Updated policy considerations. I am cross-posting to dtn-interest and dtn-security as an announcement, but= would ask that technical discussion occur on dtn-security. -Ed A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Delay-Tolerant Networking Research Group W= orking Group of the IETF. Title : Streamlined Bundle Security Protocol Specificatio= n Author : Edward J. Birrane Filename : draft-irtf-dtnrg-sbsp-01.txt Pages : 34 Date : 2014-05-27 Abstract: This document defines a streamlined bundle security protocol, which provides data authentication, integrity, and confidentiality services for the Bundle Protocol. Capabilities are provided to protect the bundle payload, and additional data that may be included within the bundle, along a single path through a network. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-irtf-dtnrg-sbsp/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-irtf-dtnrg-sbsp-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-irtf-dtnrg-sbsp-01 --- Ed Birrane Principal Professional Staff, Space Department Johns Hopkins Applied Physic= s Laboratory (W) 443-778-7423 / (F) 443-228-3839 _______________________________________________ dtn-interest mailing list dtn-interest@irtf.org https://www.irtf.org/mailman/listinfo/dtn-interest --_000_94CFB3711B4CAE4DBFC5BEB3374BF0C60D1835NDMSMBX404ndcnasa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Ed,

Good work - the SBSP spec continues to evolve nic= ely. 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>.

·       &= nbsp; Per 3.4 Bundle= Fragmentation and Reassembly, bundle authentication may be applied to bund= le fragments as well as non-fragmented bundles.

·       &= nbsp; If a bundle fr= agment 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 wa= s later fragmented by a non-security-aware BA.

o    I propose that= a <block type><occurrence number> of <0x00><payload f= rag length> indicate that the BAB applies to a bundle fragment

·       &= nbsp; If such a bund= le fragment is further fragmented by a non-security-aware BA then the <p= ayload frag length> can be used to determine that the original fragmente= d bundle must be reassembled before authentication is checked because it will not match the length field in the payload block= .

o    Some discussio= n may be desirable in section 3.4 as well as 2.4 if accepted

 

 

 

[Page 14] 2.6 Block Confidentiality Block

= The block processing control flags value can be set to whatever<= /span>

= 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.

·       &= nbsp; The intent her= e is only if the target of the Lone BCB or First BCB is the payload block w= hich would need to be added if this is kept as a requirement.

·       &= nbsp; I think this r= equirement should be removed or at least reduced to a "MAY"

1. &nbs= p;     It assumes tha= t the Lone or First BCB must be prior to the payload block which is not a s= pecific requirement and is not necessary in any case for SBSP

2. &nbs= p;     A BCB block co= uld be quite large and add a lot of bandwidth overhead if included in every= fragment

3. &nbs= p;     I do not see a= benefit gained by including the block in every fragment

  =             &nb= sp;            =             i.  = ;          Even the destination node likely = cannot decrypt any individual fragment except the first one and  it pr= obably would only decrypt a partial bundle as a last resort or forensic function if the entire bundle was not = received before expiration

  =             &nb= sp;            =           ii. &nbs= p;          Intermediate nodes shouldn't gen= erally be poking around in bundle payloads anyway and no need to provide ad= ditional clues as to whether a fragment payload is encrypted or a bunch of binary values – keep t= he bad guys guessing and wasting CPU cycles if possible

  =             &nb= sp;            =          iii. &nb= sp;          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?

 

 

 

[Page 24] 3.1.2.3 Extension Block Canonicalizatio= n

= Endpoint ID references in blocks are canonicalized using the de-=

= referenced text form in place of the reference pair.  The reference

= count is not included, nor is the length of the endpoint ID text.

= The EID reference is, therefore, canonicalized as <scheme>:<SSP>= ;,

= which includes the ":" character.

·       &= nbsp; Need to includ= e a statement to the effect:

o    Artificial EID= s as defined in this document (ssp reference is 0x00) must be skipped and a= re not included in the canonicalization. 

 

[Page 24] 3.1.2.3 Extension Block Canonicalizatio= n

= The block-length is canonicalized as its unpacked SDNV value.  If the<= o:p>

= 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.=

·       &= nbsp; Section 3.1.2.= 1 (Primary Block Canonicalization) details the length fields as 4 byte valu= es and effectively reserves the term "unpacked SDNV value" to mea= n 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 wi= th it

·       &= nbsp; Add a statemen= t to the effect:

o    The entirety o= r portion(s) of the block body data are canonicalized as is.

 

 

[Page 23] 3.1.2.2 Payload Block Canonicalization<= /b>

= When canonicalizing the payload block, the block processing control

= flags value used for canonicalization is the unpacked SDNV value with<= /o:p>

= reserved and mutable bits masked to zero.  The unpacked value is<= /o:p>

= ANDed with mask 0x0000 0000 0000 0077 to zero reserved bits and the

= "last block" bit.  The "last block" bit 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.

=  

= Payload blocks are canonicalized as-is, with the exception that, in

= some instances, only a portion of the payload data is to be

= protected.  In such a case, only those bytes are included in the<= /o:p>

= canonical form, and additional cipher suite parameters are required

= to specify which part of the payload is protected, as discussed<= /span>

= further below.

·       &= nbsp; The processing= control flags are pulled out and masked so the Payload block can no longer= be considered canonicalized "as-is".

·       &= nbsp; A Payload Bloc= k is the same underlying format as an Extension Block with the restriction = that the 'block contains an EID-reference field' is never set and it should= follow the same canonicalization methodology as that of the Extension Block

o    I propose a si= ngle "Non-Primary Block Canonicalization" section based on the fi= nalized version of the Extension Block Canonicalization

 

 

[Page 26] 3.3.2 Receiving BCB Blocks

= If the relevant parts of an encrypted payload cannot be decrypted

= (i.e., the decryption key cannot be deduced or decryption fails),

= then the bundle MUST be discarded and processed no further; in this

= case, a bundle deletion status report (see [RFC5050]) indicating the

= decryption failure MAY be generated.

·       &= nbsp; Does a new del= etion reason code need to be defined?<= o:p>

=  

 

 

 

-----Original Message-----
From: dtn-interest [mailto:dtn-interest-bounces@irtf.org] On Behalf Of Birr= ane, Edward J.
Sent: Wednesday, May 28, 2014 8:40 AM
To: dtn-interest@irtf.org; dtn-security@irtf.org
Subject: [dtn-interest] Updated SBSP Document

 

Good morning.

 

I've released a new version of the Streamlined Bu= ndle Security Protocol (SBSP) document (see information below).<= /p>

 

This change incorporates comments received to dat= e, including:

 

- Minor spelling/grammar changes and text cleanup= .

- Expanded discussion on extension block identifi= cation (Section 2.1)

- Clarified that a BIB may not be added to sign a= n encrypted block. (Section 2.7)

- Clarified block processing order in Section 2.7= .

- Clarified BIB processing (Section 3.3.3)

- Simplified bundle fragmentation discussion (Sec= tion 3.4)

- Clarified interaction of authentication and rea= ctive fragmentation.

- Updated policy considerations.

 

I am cross-posting to dtn-interest and dtn-securi= ty as an announcement, but would ask that technical discussion occur on dtn= -security.

 

-Ed

 

A New Internet-Draft is available from the on-lin= e Internet-Drafts directories.

This draft is a work item of the Delay-Tolerant N= etworking Research Group Working Group of the IETF.

 

        Title&= nbsp;          : Streamlined B= undle Security Protocol Specification

        Author=           : Edward J. Birrane<= o:p>

        Filena= me        : draft-irtf-dtnrg-sbsp-01.txt=

        Pages&= nbsp;          : 34=

        Date&n= bsp;           : 2014-05-= 27

 

Abstract:

   This document defines a streamlined = bundle security protocol, which

   provides data authentication, integr= ity, and confidentiality services

   for the Bundle Protocol.  Capab= ilities are provided to protect the

   bundle payload, and additional data = that may be included within the

   bundle, along a single path through = a network.

 

 

The IETF datatracker status page for this draft i= s:

ht= tps://datatracker.ietf.org/doc/draft-irtf-dtnrg-sbsp/=

 

There's also a htmlized version available at:

http:/= /tools.ietf.org/html/draft-irtf-dtnrg-sbsp-01

 

A diff from the previous version is available at:=

http://www.ietf.org/rfcdiff?url2=3Ddraft-irtf-dtnrg-sbsp-01

 

---

Ed Birrane

Principal Professional Staff, Space Department Jo= hns Hopkins Applied Physics Laboratory

(W) 443-778-7423 / (F) 443-228-3839

 

 

 

_______________________________________________

dtn-interest mailing list

dtn-interest@irtf.org<= /a>

https:/= /www.irtf.org/mailman/listinfo/dtn-interest

--_000_94CFB3711B4CAE4DBFC5BEB3374BF0C60D1835NDMSMBX404ndcnasa_-- From nobody Fri May 30 12:17:19 2014 Return-Path: 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 C66591A045A for ; Fri, 30 May 2014 12:17:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.85 X-Spam-Level: X-Spam-Status: No, score=-4.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] 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 1n9vKtRIivQo for ; Fri, 30 May 2014 12:17:11 -0700 (PDT) Received: from mail.jpl.nasa.gov (smtp.jpl.nasa.gov [128.149.139.109]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E14E1A046A for ; Fri, 30 May 2014 12:17:11 -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.3.1/Sentrion-MTA-4.3.1) with ESMTP id s4UJH5HR009667 (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits) verified NO); Fri, 30 May 2014 12:17:06 -0700 Received: from AP-EMBX-SP40.RES.AD.JPL ([169.254.7.156]) by ap-ehub-sp01.RES.AD.JPL ([169.254.3.182]) with mapi id 14.03.0174.001; Fri, 30 May 2014 12:17:05 -0700 From: "Burleigh, Scott C (312G)" To: "Zoller, David A. (MSFC-EO50)[HOSC SERVICES CONTRACT]" , "Birrane, Edward J." , "dtn-security@irtf.org" Thread-Topic: Updated SBSP Document Thread-Index: Ac96egHBtIlHfqjpRHK8eG5est6OOQA736HgADK/lpA= Date: Fri, 30 May 2014 19:17:04 +0000 Message-ID: References: <329D879C76FDD04AAAE84BB1D89B3970094FBF9EAA@aplesfreedom.dom1.jhuapl.edu> <94CFB3711B4CAE4DBFC5BEB3374BF0C60D1835@NDMSMBX404.ndc.nasa.gov> In-Reply-To: <94CFB3711B4CAE4DBFC5BEB3374BF0C60D1835@NDMSMBX404.ndc.nasa.gov> 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: multipart/alternative; boundary="_000_A5BEAD028815CB40A32A5669CF737C3B423B369Eapembxsp40RESAD_" MIME-Version: 1.0 X-Source-Sender: scott.c.burleigh@jpl.nasa.gov X-AUTH: Authorized Archived-At: http://mailarchive.ietf.org/arch/msg/dtn-security/Bvi5HCVbH-7JpNjKv340T7hto80 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 May 2014 19:17:17 -0000 --_000_A5BEAD028815CB40A32A5669CF737C3B423B369Eapembxsp40RESAD_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable A couple of remarks on David's comments, in-line below. Scott From: dtn-security [mailto:dtn-security-bounces@irtf.org] On Behalf Of Zoll= er, 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 dis= cussions 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 of <0x00><0x00>. =B7 Per 3.4 Bundle Fragmentation and Reassembly, bundle authenticat= ion may be applied to bundle fragments as well as non-fragmented bundles. =B7 If a bundle fragment is received that has a BAB, there is no wa= y to determine if the BAB applies to the bundle fragment or if it applies t= o an entire bundle that was later fragmented by a non-security-aware BA. o I propose that a of <0x00> indicate that the BAB applies to a bundle fragment =B7 If such a bundle fragment is further fragmented by a non-securi= ty-aware BA then the can be used to determine that th= e original fragmented bundle must be reassembled before authentication is c= hecked 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 acce= pted =D8 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 o= riginal payload (of which the current bundle's payload is a fragment). Sin= ce BABs are not end-to-end, the BAB for an original un-fragmented bundle wi= ll never be carried forward in any fragments generated from that bundle (se= e the last paragraph of 3.3.1), so there's no ambiguity. But this does bri= ng up an important point: the block processing control flags of the BAB mus= t always have the "replicate in every fragment" flag set to 0. [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. =B7 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. =B7 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 overhe= ad if included in every fragment 3. I do not see a benefit gained by including the block in every frag= ment i. Even the destination n= ode likely cannot decrypt any individual fragment except the first one and = it probably would only decrypt a partial bundle as a last resort or forens= ic function if the entire bundle was not received before expiration ii. Intermediate nodes shou= ldn't generally be poking around in bundle payloads anyway and no need to p= rovide 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 requi= rement - have any of the implementations found a need or benefit for this a= nd would it still apply in context of the SBSP? =D8 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 w= ith the fragment whose offset is zero? [Page 24] 3.1.2.3 Extension Block Canonicalization Endpoint ID references in blocks are canonicalized using the de- referenced text form in place of the reference pair. The reference count is not included, nor is the length of the endpoint ID text. The EID reference is, therefore, canonicalized as :, which includes the ":" character. =B7 Need to include a statement to the effect: o Artificial EIDs as defined in this document (ssp reference is 0x00) mu= st be skipped and are not included in the canonicalization. =D8 Right, the AEID's offsets don't reference text in the dictionary. Goo= d catch! [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. =B7 Section 3.1.2.1 (Primary Block Canonicalization) details the le= ngth fields as 4 byte values and effectively reserves the term "unpacked SD= NV value" to mean the 8 byte value. I recommend using the same convention h= ere. o Personally, I would specify all SDNV values canonicalized as 8 byte va= lues and be done with it =B7 Add a statement to the effect: o The entirety or portion(s) of the block body data are canonicalized as= is. =D8 I agree about canonicalizing all SDNVs as 8-byte values. FWIW, I thin= k the canonicalization in bundle security protocol is a major pain in the n= eck. 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? [Page 23] 3.1.2.2 Payload Block Canonicalization When canonicalizing the payload block, 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" bit. The "last block" bit 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. Payload blocks are canonicalized as-is, with the exception that, in some instances, only a portion of the payload data is to be protected. In such a case, only those bytes are included in the canonical form, and additional cipher suite parameters are required to specify which part of the payload is protected, as discussed further below. =B7 The processing control flags are pulled out and masked so the P= ayload block can no longer be considered canonicalized "as-is". =B7 A Payload Block is the same underlying format as an Extension B= lock with the restriction that the 'block contains an EID-reference field' = is never set and it should follow the same canonicalization methodology as = that of the Extension Block o I propose a single "Non-Primary Block Canonicalization" section based = on the finalized version of the Extension Block Canonicalization =D8 Again I complain about canonicalization. [Page 26] 3.3.2 Receiving BCB Blocks If the relevant parts of an encrypted payload cannot be decrypted (i.e., the decryption key cannot be deduced or decryption fails), then the bundle MUST be discarded and processed no further; in this case, a bundle deletion status report (see [RFC5050]) indicating the decryption failure MAY be generated. =B7 Does a new deletion reason code need to be defined? =D8 Good idea. -----Original Message----- From: dtn-interest [mailto:dtn-interest-bounces@irtf.org] On Behalf Of Birr= ane, Edward J. Sent: Wednesday, May 28, 2014 8:40 AM To: dtn-interest@irtf.org; dtn-security@irtf.= org Subject: [dtn-interest] Updated SBSP Document Good morning. I've released a new version of the Streamlined Bundle Security Protocol (SB= SP) document (see information below). This change incorporates comments received to date, including: - Minor spelling/grammar changes and text cleanup. - Expanded discussion on extension block identification (Section 2.1) - Clarified that a BIB may not be added to sign an encrypted block. (Sectio= n 2.7) - Clarified block processing order in Section 2.7. - Clarified BIB processing (Section 3.3.3) - Simplified bundle fragmentation discussion (Section 3.4) - Clarified interaction of authentication and reactive fragmentation. - Updated policy considerations. I am cross-posting to dtn-interest and dtn-security as an announcement, but= would ask that technical discussion occur on dtn-security. -Ed A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Delay-Tolerant Networking Research Group W= orking Group of the IETF. Title : Streamlined Bundle Security Protocol Specificatio= n Author : Edward J. Birrane Filename : draft-irtf-dtnrg-sbsp-01.txt Pages : 34 Date : 2014-05-27 Abstract: This document defines a streamlined bundle security protocol, which provides data authentication, integrity, and confidentiality services for the Bundle Protocol. Capabilities are provided to protect the bundle payload, and additional data that may be included within the bundle, along a single path through a network. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-irtf-dtnrg-sbsp/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-irtf-dtnrg-sbsp-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-irtf-dtnrg-sbsp-01 --- Ed Birrane Principal Professional Staff, Space Department Johns Hopkins Applied Physic= s Laboratory (W) 443-778-7423 / (F) 443-228-3839 _______________________________________________ dtn-interest mailing list dtn-interest@irtf.org https://www.irtf.org/mailman/listinfo/dtn-interest --_000_A5BEAD028815CB40A32A5669CF737C3B423B369Eapembxsp40RESAD_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

A couple of remarks on= David’s comments, in-line below.

 

Scott

 

From: dtn-secu= rity [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<= /p>

 

Ed,

Good work - the SBSP spec continues to evolve nic= ely. 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>.

=B7         Per 3.4 Bundle= Fragmentation and Reassembly, bundle authentication may be applied to bund= le fragments as well as non-fragmented bundles.

=B7         If a bundle fr= agment 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 wa= s later fragmented by a non-security-aware BA.

o    I propose that= a <block type><occurrence number> of <0x00><payload f= rag length> indicate that the BAB applies to a bundle fragment

=B7         If such a bund= le fragment is further fragmented by a non-security-aware BA then the <p= ayload frag length> can be used to determine that the original fragmente= d bundle must be reassembled before authentication is checked because it will not match the length field in the payload block= .

o    Some discussio= n may be desirable in section 3.4 as well as 2.4 if accepted

=D8  When a BAB is = attached to a bundle that is a fragment, the bundle that it applies to is a= lways 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 origin= al un-fragmented bundle will never be carried forward in any fragments gene= rated 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.<= /p>

 

 

[Page 14] 2.6 Block Confidentiality Block

= The block processing control flags value can be set to whatever<= /span>

= 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.

=B7         The intent her= e is only if the target of the Lone BCB or First BCB is the payload block w= hich would need to be added if this is kept as a requirement.

=B7         I think this r= equirement should be removed or at least reduced to a "MAY"

1. &nbs= p;     It assumes tha= t the Lone or First BCB must be prior to the payload block which is not a s= pecific requirement and is not necessary in any case for SBSP

2. &nbs= p;     A BCB block co= uld be quite large and add a lot of bandwidth overhead if included in every= fragment

3. &nbs= p;     I do not see a= benefit gained by including the block in every fragment

  =             &nb= sp;            =             i.  = ;          Even the destination node likely = cannot decrypt any individual fragment except the first one and  it pr= obably would only decrypt a partial bundle as a last resort or forensic function if the entire bundle was not = received before expiration

  =             &nb= sp;            =           ii. &nbs= p;          Intermediate nodes shouldn't gen= erally be poking around in bundle payloads anyway and no need to provide ad= ditional clues as to whether a fragment payload is encrypted or a bunch of binary values – keep t= he bad guys guessing and wasting CPU cycles if possible

  =             &nb= sp;            =          iii. &nb= sp;          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?

=D8  I think this a= good point.  Since all decryption should only happen at the bundle de= stination, which is where all the fragments are going to have to end up, wh= y not forward all BCBs (for all blocks that have them) only with the fragment whose offset is zero?   <= /span>

 

 

[Page 24] 3.1.2.3 Extension Block Canonicalizatio= n

= Endpoint ID references in blocks are canonicalized using the de-=

= referenced text form in place of the reference pair.  The reference

= count is not included, nor is the length of the endpoint ID text.

= The EID reference is, therefore, canonicalized as <scheme>:<SSP>= ;,

= which includes the ":" character.

=B7         Need to includ= e a statement to the effect:

o    Artificial EID= s as defined in this document (ssp reference is 0x00) must be skipped and a= re not included in the canonicalization.=D8  Right, the AEI= D’s offsets don’t reference text in the dictionary.  Good = catch!

 

[Page 24] 3.1.2.3 Extension Block Canonicalizatio= n

= The block-length is canonicalized as its unpacked SDNV value.  If the<= o:p>

= 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.=

=B7         Section 3.1.2.= 1 (Primary Block Canonicalization) details the length fields as 4 byte valu= es and effectively reserves the term "unpacked SDNV value" to mea= n 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 wi= th it

=B7         Add a statemen= t to the effect:

o    The entirety o= r portion(s) of the block body data are canonicalized as is.

=D8  I agree about = canonicalizing all SDNVs as 8-byte values.  FWIW, I think the canonica= lization 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?

 

 

[Page 23] 3.1.2.2 Payload Block Canonicalization<= /b>

= When canonicalizing the payload block, the block processing control

= flags value used for canonicalization is the unpacked SDNV value with<= /o:p>

= reserved and mutable bits masked to zero.  The unpacked value is<= /o:p>

= ANDed with mask 0x0000 0000 0000 0077 to zero reserved bits and the

= "last block" bit.  The "last block" bit 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.

=  

= Payload blocks are canonicalized as-is, with the exception that, in

= some instances, only a portion of the payload data is to be

= protected.  In such a case, only those bytes are included in the<= /o:p>

= canonical form, and additional cipher suite parameters are required

= to specify which part of the payload is protected, as discussed<= /span>

= further below.

=B7         The processing= control flags are pulled out and masked so the Payload block can no longer= be considered canonicalized "as-is".

=B7         A Payload Bloc= k is the same underlying format as an Extension Block with the restriction = that the 'block contains an EID-reference field' is never set and it should= follow the same canonicalization methodology as that of the Extension Block

o    I propose a si= ngle "Non-Primary Block Canonicalization" section based on the fi= nalized version of the Extension Block Canonicalization

=D8  Again I compla= in about canonicalization.<= /span>

 

[Page 26] 3.3.2 Receiving BCB Blocks

= If the relevant parts of an encrypted payload cannot be decrypted

= (i.e., the decryption key cannot be deduced or decryption fails),

= then the bundle MUST be discarded and processed no further; in this

= case, a bundle deletion status report (see [RFC5050]) indicating the

= decryption failure MAY be generated.

=B7         Does a new del= etion reason code need to be defined?<= o:p>

=D8  Good idea.

=  

 

 

 

-----Original Message-----
From: dtn-interest [mailto= :dtn-interest-bounces@irtf.org] On Behalf Of Birrane, Edward J.
Sent: Wednesday, May 28, 2014 8:40 AM
To: dtn-interest@irtf.org; dtn-security@irtf.org
Subject: [dtn-interest] Updated SBSP Document

 

Good morning.

 

I've released a new version of the Streamlined Bu= ndle Security Protocol (SBSP) document (see information below).<= /p>

 

This change incorporates comments received to dat= e, including:

 

- Minor spelling/grammar changes and text cleanup= .

- Expanded discussion on extension block identifi= cation (Section 2.1)

- Clarified that a BIB may not be added to sign a= n encrypted block. (Section 2.7)

- Clarified block processing order in Section 2.7= .

- Clarified BIB processing (Section 3.3.3)

- Simplified bundle fragmentation discussion (Sec= tion 3.4)

- Clarified interaction of authentication and rea= ctive fragmentation.

- Updated policy considerations.

 

I am cross-posting to dtn-interest and dtn-securi= ty as an announcement, but would ask that technical discussion occur on dtn= -security.

 

-Ed

 

A New Internet-Draft is available from the on-lin= e Internet-Drafts directories.

This draft is a work item of the Delay-Tolerant N= etworking Research Group Working Group of the IETF.

 

        Title&= nbsp;          : Streamlined B= undle Security Protocol Specification

        Author=           : Edward J. Birrane<= o:p>

        Filena= me        : draft-irtf-dtnrg-sbsp-01.txt=

        Pages&= nbsp;          : 34=

        Date&n= bsp;           : 2014-05-= 27

 

Abstract:

   This document defines a streamlined = bundle security protocol, which

   provides data authentication, integr= ity, and confidentiality services

   for the Bundle Protocol.  Capab= ilities are provided to protect the

   bundle payload, and additional data = that may be included within the

   bundle, along a single path through = a network.

 

 

The IETF datatracker status page for this draft i= s:

ht= tps://datatracker.ietf.org/doc/draft-irtf-dtnrg-sbsp/=

 

There's also a htmlized version available at:

http:/= /tools.ietf.org/html/draft-irtf-dtnrg-sbsp-01

 

A diff from the previous version is available at:=

http://www.ietf.org/rfcdiff?url2=3Ddraft-irtf-dtnrg-sbsp-01

 

---

Ed Birrane

Principal Professional Staff, Space Department Jo= hns Hopkins Applied Physics Laboratory

(W) 443-778-7423 / (F) 443-228-3839

 

 

 

_______________________________________________

dtn-interest mailing list

dtn-interest@irtf.org<= /a>

https:/= /www.irtf.org/mailman/listinfo/dtn-interest

--_000_A5BEAD028815CB40A32A5669CF737C3B423B369Eapembxsp40RESAD_--