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

Peter Lovell <plovell@mac.com> Tue, 07 August 2012 16:28 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 5E0B311E809A for <dtn-security@ietfa.amsl.com>; Tue, 7 Aug 2012 09:28:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.099
X-Spam-Level:
X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[AWL=1.500, 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 1CMjyqTXMgJm for <dtn-security@ietfa.amsl.com>; Tue, 7 Aug 2012 09:28:43 -0700 (PDT)
Received: from nk11p99mm-asmtpout007.mac.com (nk11p99mm-asmtpout007.mac.com [17.158.233.228]) by ietfa.amsl.com (Postfix) with ESMTP id 460A711E8087 for <dtn-security@irtf.org>; Tue, 7 Aug 2012 09:28:43 -0700 (PDT)
MIME-version: 1.0
Content-type: text/plain; charset=windows-1252
Received: from [192.168.76.196] (static-96-244-17-67.bltmmd.fios.verizon.net [96.244.17.67]) by nk11p03mm-asmtp997.mac.com (Oracle Communications Messaging Server 7u4-24.01(7.0.4.24.0) 64bit (built Jan 3 2012)) with ESMTPSA id <0M8E00JCT8FSHWA0@nk11p03mm-asmtp997.mac.com> for dtn-security@irtf.org; Tue, 07 Aug 2012 16:28:42 +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=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1203120001 definitions=main-1208070157
From: Peter Lovell <plovell@mac.com>
In-reply-to: <502141C6.8030804@cs.tcd.ie>
Date: Tue, 07 Aug 2012 12:28:39 -0400
Content-transfer-encoding: quoted-printable
Message-id: <2E6CABBD-4D93-4829-B6ED-3720313439C0@mac.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> <a7078fb0d6bad00c68fe43ca5272a52b.squirrel@webmail.math.umd.edu> <20120807161303.1666733293@smtp.mail.me.com> <502141C6.8030804@cs.tcd.ie>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
X-Mailer: Apple Mail (2.1485)
Cc: ahennes1@math.umd.edu, dtn-security@irtf.org
Subject: Re: [dtn-security] 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:28:44 -0000

Sounds like a plan …

Cheers…..Peter

On Aug 7, 2012, at 12:26 PM, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:

> 
> Hi,
> 
> 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.
> 
> Cheers,
> S.
> 
> 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, 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.
>>> 
>>> 
>>> 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
>>>>> 
>>>> 
>>>> 
>>> 
>> 
>> 
>> 
>>