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

Stephen Farrell <> Tue, 07 August 2012 16:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B766A11E8087 for <>; Tue, 7 Aug 2012 09:26:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id KQV+eErJ2WyQ for <>; Tue, 7 Aug 2012 09:26:54 -0700 (PDT)
Received: from ( [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by (Postfix) with ESMTP id 19B5311E8072 for <>; Tue, 7 Aug 2012 09:26:54 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7C75B17150A; Tue, 7 Aug 2012 17:26:53 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; 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=1344356813; bh=btVhjLe5mL7p0y yGY1vgNet7nex+2t24sJ0FX/z43d8=; b=lvFBuhK/NbVvXjTc/nWQTrzC/GGOZf QvsG40nSu9cNWvk4/AiP8Befoh+HKc8hcsVv4wP/fTLnxFSa80hpKRw96HjtLYaF ETW0CLgslL++24GJHKd59y5ojW9uk7AQPo7alsgakDooFT0YFBBZg4BApdWsYAps 5MUQ93ZOnQ3vk/p38TlzaNgLrPiIheKy0Zff0JBdhH+Qn2UrzXpmYLXz3wWo5lTz JQrEbGEIqjBo5Ew9jzV1bMf03ySldXOAXKN/qCMZ3eJYXefyIg1CdlUNZiywomhZ Qvx7Zrh9bYVJUF+osr7elEJ17fGXEH2TRqRMHqiWqZCTQnCkhrY4mLRQ==
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10027) with ESMTP id U5NJKpCMAbsI; Tue, 7 Aug 2012 17:26:53 +0100 (IST)
Received: from [IPv6:2001:770:10:203:49b3:3973:5610:abc4] (unknown [IPv6:2001:770:10:203:49b3:3973:5610:abc4]) by (Postfix) with ESMTPSA id CF255171509; Tue, 7 Aug 2012 17:26:46 +0100 (IST)
Message-ID: <>
Date: Tue, 07 Aug 2012 17:26:46 +0100
From: Stephen Farrell <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0
MIME-Version: 1.0
To: Peter Lovell <>
References: <> <> <> <> <> <> <> <>
In-Reply-To: <>
X-Enigmail-Version: 1.4.3
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [dtn-security] Issue implementing security source/destination with ESB blocks
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, 07 Aug 2012 16:26:55 -0000


Sorry I've not been reading this since I was running around
madly IETFing last week;-)

I'd say best is if maybe Pete and Angela could draft an
erratum and post that here. We can stick into the system
once folks have had a few days to consider it. Probably also
worth a mention on dtn-interest at that point too since
that list has more people on it than this.

Once approved, it'll show up on the tools page for the RFC.
The RG chairs can approve errata like this.


On 08/07/2012 05:13 PM, Peter Lovell wrote:
> 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.
> Regards.....Peter
> On Tue, Aug 13, 2013, <> 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.
>> 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, <> 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