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

ahennes1@math.umd.edu Mon, 06 August 2012 20:12 UTC

Return-Path: <ahennes1@math.umd.edu>
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 1ECE721E8048 for <dtn-security@ietfa.amsl.com>; Mon, 6 Aug 2012 13:12:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.166
X-Spam-Level:
X-Spam-Status: No, score=-6.166 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21gqFa3CxEDO for <dtn-security@ietfa.amsl.com>; Mon, 6 Aug 2012 13:12: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 2B95C11E808A for <dtn-security@irtf.org>; Mon, 6 Aug 2012 13:12:43 -0700 (PDT)
X-ASG-Debug-ID: 1344283961-04739d104c3ff300001-NoPDhg
Received: from svr4.math.umd.edu ([129.2.56.14]) by mailfilter.ece.umd.edu with ESMTP id PxUR2DCMZwEWTiuX; Mon, 06 Aug 2012 16:12: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 557816FC83; Mon, 6 Aug 2012 16:12:41 -0400 (EDT)
Received: from 65.127.220.136 by webmail.math.umd.edu with HTTP; Mon, 6 Aug 2012 16:12:41 -0400
Message-ID: <a7078fb0d6bad00c68fe43ca5272a52b.squirrel@webmail.math.umd.edu>
In-Reply-To: <20120806162008.1123881582@smtp.mail.me.com>
References: <20120802214016.1861780438@smtp.mail.me.com> <501B3B2F.5090508@folly.org.uk> <329D879C76FDD04AAAE84BB1D89B397006842FE3A0@aplesfreedom.dom1.jhuapl.edu> <20120803221701.223057816@smtp.mail.me.com> <e5f316d31c243f6f6758ffc0a81303ca.squirrel@webmail.math.umd.edu> <20120806162008.1123881582@smtp.mail.me.com>
Date: Mon, 6 Aug 2012 16:12:41 -0400
From: ahennes1@math.umd.edu
X-ASG-Orig-Subj: Re: Re(2): [dtn-security] Issue implementing security source/destination with ESB blocks
To: "Peter Lovell" <plovell@mac.com>
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: 1344283961
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.104881 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] Re(2): Issue implementing security source/destination with ESB blocks
X-BeenThere: dtn-security@irtf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Security." <dtn-security.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/dtn-security>, <mailto:dtn-security-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/dtn-security>
List-Post: <mailto:dtn-security@irtf.org>
List-Help: <mailto:dtn-security-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/dtn-security>, <mailto:dtn-security-request@irtf.org?subject=subscribe>
X-List-Received-Date: Mon, 06 Aug 2012 20:12:44 -0000

Hi Peter,

I don't think that item 2 applies to PCB. In ESB, there is a one-to-one
replacement of extension blocks with ESB blocks. In PCB, there's a "first"
PCB that contains the ciphersuite ID, parameters and the security src/dest
(if present):

   Put another way: when confidentiality will generate multiple blocks,
   it MUST create a "first" PCB with the required ciphersuite ID,
   parameters, etc., as specified above.  Typically, this PCB will
   appear early in the bundle.  This "first" PCB contains the parameters
   that apply to the payload and also to the other correlated PCBs.  The
   correlated PCBs follow the "first" PCB and MUST NOT repeat the
   ciphersuite-parameters, security-source, or security-destination
   fields from the first PCB.

Then this correlated PCB that encapsulates a PIB or PCB will copy the
eid-list from the encapsulated block. I think the eid-list from the PIB or
PCB will only contain the security src/dest of that block, so the new
encapsulating PCB will also have at most 2 eid-refs.


Thanks,
Angela




> Hi Angela,
>
> Item 1 is fine
>
> For item 2, the exception applies to both ESB and PCB. A PCB that
> encapsulates a block that already has an EID-list, such as PIB or PCB, may
> have a long list, just as ESB may. Your comments on items 3 and 4 also
> need revisiting in this light - I think that their treatment will be the
> same.
>
> I can draft some language for item 3 if you like. I would probably
> describe it as copying the EID-list to the new block and then prepending
> sec-src and sec-dest if necessary.
>
> Regards.....Peter
>
>
> On Mon, Aug 6, 2012, ahennes1@math.umd.edu <ahennes1@math.umd.edu> wrote:
>
>>All,
>>
>>I'm trying to summarize the issues with RFC6257 for an errata list. How
>>does this sound:
>>
>>1. In Section 2.1, in the description of the EID-references, it should
>>mention that the EID-refs are preceded by a count field.
>>
>>2. Also in Section 2.1, it states that there can be at most 2 eid refs in
>>an Abstract Security Block. An exception should be added for ESB, which
>>can have an arbitrary number of eid refs based on the number in the
>>original extension block and how many times it has been encapsulated.
>>
>>3. In Section 2.5, in the discussion of ESB, there needs to be some
>>language describing how the eid-ref list in the encapsulated block is
>>appended to the (optional) security src/dest of the encapsulating ESB. As
>>a result, the eid-ref list in the ESB may be of arbitrary length. Also in
>>Section 2.5, the statement that eid list entries should be handled
>>analogously to PCB should be removed (along with the reference to Section
>>2.4).
>>
>>4. In Section 4.4, in the description of ESB-RSA-AES128-EXT, the
>> statement
>>that eid list entries should be handled analogously to PCB should be
>>removed (along with the reference to Section 2.4).
>>
>>
>>Thanks,
>>Angela
>>
>
>