Re: [Atoca] Remarks on the security discussion today

"Thomson, Martin" <Martin.Thomson@commscope.com> Wed, 13 April 2011 02:05 UTC

Return-Path: <Martin.Thomson@commscope.com>
X-Original-To: earlywarning@ietfc.amsl.com
Delivered-To: earlywarning@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id F2AD0E06F4 for <earlywarning@ietfc.amsl.com>; Tue, 12 Apr 2011 19:05:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aEDdqUvFX5rg for <earlywarning@ietfc.amsl.com>; Tue, 12 Apr 2011 19:05:49 -0700 (PDT)
Received: from cdcsmgw02.commscope.com (fw.commscope.com [198.135.207.129]) by ietfc.amsl.com (Postfix) with ESMTP id 46BBDE06EA for <earlywarning@ietf.org>; Tue, 12 Apr 2011 19:05:46 -0700 (PDT)
X-AuditID: 0a0404e9-b7c0fae000001e9f-af-4da504f9cd6f
Received: from ACDCE7HC2.commscope.com ( [10.86.20.103]) by cdcsmgw02.commscope.com (Symantec Brightmail Gateway) with SMTP id E2.B2.07839.9F405AD4; Tue, 12 Apr 2011 21:05:45 -0500 (CDT)
Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.3.137.0; Tue, 12 Apr 2011 21:05:45 -0500
Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Wed, 13 Apr 2011 10:05:39 +0800
From: "Thomson, Martin" <Martin.Thomson@commscope.com>
To: Hannes Tschofenig <Hannes.Tschofenig@gmx.net>, "earlywarning@ietf.org" <earlywarning@ietf.org>
Date: Wed, 13 Apr 2011 10:05:36 +0800
Thread-Topic: [Atoca] Remarks on the security discussion today
Thread-Index: Acvv2t7HMDnUQz4xSdOfgZ7arpealQJpDo9w
Message-ID: <8B0A9FCBB9832F43971E38010638454F040295909F@SISPE7MB1.commscope.com>
References: <AB512223-EEE5-4105-99C9-305603FEE080@gmx.net>
In-Reply-To: <AB512223-EEE5-4105-99C9-305603FEE080@gmx.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAA==
Subject: Re: [Atoca] Remarks on the security discussion today
X-BeenThere: earlywarning@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Discussion list for the IETF Authority-to-Citizen Alert \(atoca\) working group." <earlywarning.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/earlywarning>, <mailto:earlywarning-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/earlywarning>
List-Post: <mailto:earlywarning@ietf.org>
List-Help: <mailto:earlywarning-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/earlywarning>, <mailto:earlywarning-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 13 Apr 2011 02:05:50 -0000

Hi Hannes,

Thanks for putting this together.  It's a pretty good summary of the discussion.

--Martin

On 2011-04-01 at 06:35:48, Hannes Tschofenig wrote:
> Hi all,
> 
> in the discussions today a few interesting remarks were raised. I 
> wanted to share them with you. Richard, Martin and Cullen listed two 
> aspects that need to be described in the requirements/architecture 
> document, namely
> 
> (1) How does the recipient/receiver learn which author/originator to 
> trust?
> 
> In this case Richard distinguished two scenarios:
> 
> a) Tsunami warning
> 
> Here the warning may be provided to the recipient/receiver by some 
> local entity. How does the author/originator know when it receives an 
> alert that can indeed be trusted? It could be sent by anyone. It is 
> not very likely that the author of the message is known.
> 
> For this specific case Richard suggested to build on the work in 
> draft- rosen-ecrit-lost-early-warning-01.txt. The basic idea is that 
> the receiver uses LoST to discovers organizations issuing alerts for 
> specific geographical regions. When an alert is received then the 
> author and/or originator fields are checked against the info 
> previously obtained via LoST.
> 
> b) School closed warning
> 
> Here, the recipient will have a prior relationship with the author 
> (the school). A prior "registration" step is likely going to be required.
> 
> (2) Transitive Trust vs. End-to-End Security
> 
> In order to ensure that the comparison between the identity 
> information can be processed by the recipient/receiver there is a need 
> for cryptographic assurance. During the meeting we had discussed the 
> possibility to use transitive trust (I know my service provider and I 
> assume that he will only accept and forward alerts it got from other 
> trusted sources) and end-to-end security.
> 
> In the area of end-to-end security it was noticed that the deployment 
> reality of SIP (and XMPP) with regard to e2e security is rather weak.
> Security at the alert level was seen as OK but XMLDSIG was not 
> acceptable.
> 
> I hope my writeup makes sense (even though I am tired already).
> 
> Ciao
> Hannes
> 
> _______________________________________________
> earlywarning mailing list
> earlywarning@ietf.org
> https://www.ietf.org/mailman/listinfo/earlywarning