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
- [Atoca] Remarks on the security discussion today Hannes Tschofenig
- Re: [Atoca] Remarks on the security discussion to… Art Botterell
- Re: [Atoca] Remarks on the security discussion to… Thomson, Martin