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

Peter Lovell <plovell@mac.com> Tue, 07 August 2012 16:13 UTC

Return-Path: <plovell@mac.com>
X-Original-To: dtn-security@ietfa.amsl.com
Delivered-To: dtn-security@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 3739821F8734 for <dtn-security@ietfa.amsl.com>; Tue, 7 Aug 2012 09:13:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id uZO7gtrV4Eha for <dtn-security@ietfa.amsl.com>; Tue, 7 Aug 2012 09:13:07 -0700 (PDT)
Received: from st11p00mm-asmtpout003.mac.com (st11p00mm-asmtpout003.mac.com []) by ietfa.amsl.com (Postfix) with ESMTP id 30A6921F8652 for <dtn-security@irtf.org>; Tue, 7 Aug 2012 09:13:06 -0700 (PDT)
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: text/plain; CHARSET=US-ASCII
Received: from [] (static-96-244-17-67.bltmmd.fios.verizon.net []) by st11p00mm-asmtp003.mac.com (Oracle Communications Messaging Server 7u4-23.01( 64bit (built Aug 10 2011)) with ESMTPSA id <0M8E00ERW7PROK40@st11p00mm-asmtp003.mac.com> for dtn-security@irtf.org; Tue, 07 Aug 2012 16:13:06 +0000 (GMT)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.7.7855, 1.0.260, 0.0.0000 definitions=2012-08-07_04:2012-08-07, 2012-08-07, 1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=1 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1203120001 definitions=main-1208070153
From: Peter Lovell <plovell@mac.com>
To: ahennes1@math.umd.edu
Date: Tue, 07 Aug 2012 12:13:03 -0400
Message-id: <20120807161303.1666733293@smtp.mail.me.com>
In-reply-to: <a7078fb0d6bad00c68fe43ca5272a52b.squirrel@webmail.math.umd.edu>
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> <a7078fb0d6bad00c68fe43ca5272a52b.squirrel@webmail.math.umd.edu>
X-Mailer: CTM PowerMail version 6.1.3 build 4650 English (intel) <http://www.ctmdev.com>
Cc: dtn-security@irtf.org
Subject: [dtn-security] Re(4): 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: Tue, 07 Aug 2012 16:13:08 -0000

Hi Angela,

you're correct in that item 2 doesn't apply to PC3.

However it might be too strong to say that it doesn't apply to any, as-yet-undesigned, PC ciphersuite. Right now, the only EIDs defined are for sec-src and sec-dest but I can imagine ciphersuites that might have additional ones.

I think that the description for PC3 should be quite specific, but that the general description for PI and PC ciphersuites should be permissive.


On Tue, Aug 13, 2013, ahennes1@math.umd.edu <ahennes1@math.umd.edu> wrote:

>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.
>> 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:
>>>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
>>>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).