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

Stephen Farrell <stephen.farrell@cs.tcd.ie> Tue, 07 August 2012 17:36 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
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 294FD21F86F0 for <dtn-security@ietfa.amsl.com>; Tue, 7 Aug 2012 10:36:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
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 mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k9i-9oJYqbik for <dtn-security@ietfa.amsl.com>; Tue, 7 Aug 2012 10:36:49 -0700 (PDT)
Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 5508621F86EE for <dtn-security@irtf.org>; Tue, 7 Aug 2012 10:36:49 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 6E243153657; Tue, 7 Aug 2012 18:36:48 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; 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=1344361007; bh=mwccSZ7x3ySCgd PKt72KwIMU83PGG5MpfsfeLT41IQ4=; b=gvoKV6Hi/McUXQSbAtFPD5IOc2DpGy 0/hm27iqD6ywboFST3hMeB5HsMddbrKHbhKK7C30pFg1eCNeRINcTdoAXRJ111LT +9QF0fOBP6Gjkp+CzENAFrCp4ATxLbqIleSEUKBaBgLN70mwFIDhNqOfxI/LI4Ja qEB20VDscURHkjdxEEKRfFrde9BPeA87GSHSuZHs8p8JtEJHSAKvD+sQaUdVG9/v u9SBnO+DWaIPZ/85/U7sb/2HiXvjGoKjZVxOPJm0wrMcW5MJ3pNw5oto3nVI7GBS 5qvijrxQ15or8p2dVopBzuR1lB9HdzbLW/eK6W59fz0tx3zqcraeNlfA==
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id SvecGFQ5vCJv; Tue, 7 Aug 2012 18:36:47 +0100 (IST)
Received: from [IPv6:2001:770:10:203:49b3:3973:5610:abc4] (unknown [IPv6:2001:770:10:203:49b3:3973:5610:abc4]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id C5ED1171509; Tue, 7 Aug 2012 18:36:43 +0100 (IST)
Message-ID: <5021522B.4000309@cs.tcd.ie>
Date: Tue, 07 Aug 2012 18:36:43 +0100
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0
MIME-Version: 1.0
To: "Birrane, Edward J." <Edward.Birrane@jhuapl.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> <20120807161303.1666733293@smtp.mail.me.com> <502141C6.8030804@cs.tcd.ie> <2E6CABBD-4D93-4829-B6ED-3720313439C0@mac.com> <329D879C76FDD04AAAE84BB1D89B39700689BEEF2B@aplesfreedom.dom1.jhuapl.edu>
In-Reply-To: <329D879C76FDD04AAAE84BB1D89B39700689BEEF2B@aplesfreedom.dom1.jhuapl.edu>
X-Enigmail-Version: 1.4.3
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: "ahennes1@math.umd.edu" <ahennes1@math.umd.edu>, "dtn-security@irtf.org" <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 17:36:51 -0000

Just in case it wasn't clear: I'd like if we had consensus
on the text of the erratum on this list before we post it
to the RFC editor site. If we have a huge row about that
first, then so be it, but I'd hope that won't be needed:-)

Anyway, if Pete/Angela can craft text we can thrash it
as needed.

S

On 08/07/2012 05:56 PM, Birrane, Edward J. wrote:
> All,
> 
>   If, when writing the errata list, a proposed solution for surgery on the EID list is proposed, I would ask that you consider the following.
> 
>   If the existing EID list from the encapsulated block *already* contains the security source, security destination, or both (but not at the front of the EID-list) then I recommend we not repeat the security source and/or destination in the encapsulating block by prepending them.
> 
>   I would recommend flags and EID-list indices in the ciphersuite parameters rather than repetition or EID-list re-ordering.
> 
> -Ed
> 
> 
> ---
> Ed Birrane
> Senior Professional Staff, Space Department
> Johns Hopkins Applied Physics Laboratory
> (W) 443-778-7423 / (F) 443-228-3839
>  
> 
>> -----Original Message-----
>> From: Peter Lovell [mailto:plovell@mac.com]
>> Sent: Tuesday, August 07, 2012 12:29 PM
>> To: Stephen Farrell
>> Cc: ahennes1@math.umd.edu; aloomis@sarn.org; Corbett, Cherita L.;
>> Birrane, Edward J.; Elwyn Davies; dtn-security@irtf.org
>> Subject: Re: [dtn-security] Issue implementing security source/destination
>> with ESB blocks
>>
>> 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
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
> 
> 
>