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

Peter Lovell <plovell@mac.com> Mon, 06 August 2012 16:20 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 [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7016E21F8615 for <dtn-security@ietfa.amsl.com>; Mon, 6 Aug 2012 09:20:13 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1qlknkPPNsY4 for <dtn-security@ietfa.amsl.com>; Mon, 6 Aug 2012 09:20:12 -0700 (PDT)
Received: from st11p00mm-asmtpout002.mac.com (st11p00mm-asmtp002.mac.com [17.172.81.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E96921F860B for <dtn-security@irtf.org>; Mon, 6 Aug 2012 09:20:12 -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-asmtp002.mac.com (Oracle Communications Messaging Exchange Server 7u4-22.01 64bit (built Apr 21 2011)) with ESMTPSA id <0M8C00ESWDDKRP40@st11p00mm-asmtp002.mac.com> for dtn-security@irtf.org; Mon, 06 Aug 2012 16:20:11 +0000 (GMT)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.7.7855, 1.0.260, 0.0.0000 definitions=2012-08-06_04:2012-08-06, 2012-08-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-1208060161
From: Peter Lovell <plovell@mac.com>
To: ahennes1@math.umd.edu, aloomis@sarn.org, cherita.corbett@jhuapl.edu, Stephen Farrell <stephen.farrell@cs.tcd.ie>
Date: Mon, 06 Aug 2012 12:20:08 -0400
Message-id: <20120806162008.1123881582@smtp.mail.me.com>
In-reply-to: <e5f316d31c243f6f6758ffc0a81303ca.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>
X-Mailer: CTM PowerMail version 6.1.1 build 4649 English (intel) <http://www.ctmdev.com>
Cc: dtn-security@irtf.org
Subject: [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 16:20:13 -0000

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
>