From hannes.tschofenig@gmx.net Sun Feb 27 01:20:03 2011 Return-Path: X-Original-To: earlywarning@core3.amsl.com Delivered-To: earlywarning@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6FC7B3A69D9 for ; Sun, 27 Feb 2011 01:20:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.648 X-Spam-Level: X-Spam-Status: No, score=-102.648 tagged_above=-999 required=5 tests=[AWL=-0.049, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nL1XbhBEzL-D for ; Sun, 27 Feb 2011 01:20:02 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by core3.amsl.com (Postfix) with SMTP id A00073A69D0 for ; Sun, 27 Feb 2011 01:20:01 -0800 (PST) Received: (qmail invoked by alias); 27 Feb 2011 09:20:56 -0000 Received: from a88-115-222-204.elisa-laajakaista.fi (EHLO [192.168.1.3]) [88.115.222.204] by mail.gmx.net (mp064) with SMTP; 27 Feb 2011 10:20:56 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/atSECt9/awSc15FjPt5NIzGT3dYZaq3F+KnMOuw EQEO8Vi5djZw7S From: Hannes Tschofenig Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sun, 27 Feb 2011 11:20:54 +0200 Message-Id: <68CCF53C-2170-4059-A475-415E48D9BC7D@gmx.net> To: earlywarning@ietf.org Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) X-Y-GMX-Trusted: 0 Subject: [Atoca] Summary of "Requirement for Originator Authentication?" Discussion X-BeenThere: earlywarning@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert \(atoca\) working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Feb 2011 09:20:03 -0000 Hi all,=20 thank you for your feedback on the topic of originator authentication.=20= =46rom the responses I see three aspects emerging:=20 1) Deployment choice vs. technological capability=20 How authorization policies would look like and what specific information = is used to determine who is authorized and who isn't is a deployment = decision.=20 However, there needs to be technology available to actually provide this = information. Identity-based authorization was mentioned (as a low = hanging fruit) and the technical solution is to offer identity = information about the entity that distributes the alert message.=20 Other more sophisticated approaches (from a technology point of view) = are trait-based authorization mechanisms.=20 Your feedback raised the question whether we can re-use these security = mechanisms from the underlying communication infrastructure? E.g. for = example from SIP and XMPP?=20 2) Hop-by-hop vs. end-to-end authentication=20 I got the impression that we need to allow both building blocks to be = used rather than to focus on either one of them.=20 Btw, CAP payloads are not end-to-end protected with S/MIME but rather = with XML DSig. Not that either one of them is simpler but what would be = appropriate to use in our context? 3) Identity scheme If we have an identity based authorization then there is obviously the = question about the types of identities one needs to deal with. CAP is = very relaxed on this issue and does not provide a lot of constraints. = So, I suspect the constraints to rather come from the underlying = communication infrastructure.=20 In the area of SIP we had lots of discussions around SIP Identity and a = discussion of the different identities can be found in = http://tools.ietf.org/html/rfc5025#section-3.1.1 (based on the = discussions around Common Policy). Is it too far fetched to assume that the underlying communication = infrastructure provides the identities for us? Ciao Hannes= From hannes.tschofenig@gmx.net Sun Feb 27 02:10:14 2011 Return-Path: X-Original-To: earlywarning@core3.amsl.com Delivered-To: earlywarning@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B3853A69E4 for ; Sun, 27 Feb 2011 02:10:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.646 X-Spam-Level: X-Spam-Status: No, score=-102.646 tagged_above=-999 required=5 tests=[AWL=-0.047, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nqW55QlmE4hh for ; Sun, 27 Feb 2011 02:10:13 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by core3.amsl.com (Postfix) with SMTP id E02713A69DF for ; Sun, 27 Feb 2011 02:10:12 -0800 (PST) Received: (qmail invoked by alias); 27 Feb 2011 10:11:08 -0000 Received: from a88-115-222-204.elisa-laajakaista.fi (EHLO [192.168.1.3]) [88.115.222.204] by mail.gmx.net (mp069) with SMTP; 27 Feb 2011 11:11:08 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX187OVYVSyE7iR4veYiXDB3hHcVTA82FtwG7wrqOPf NQJJHvnAU3B7fS From: Hannes Tschofenig Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sun, 27 Feb 2011 12:11:07 +0200 Message-Id: <31689DE4-E825-4B0B-96D0-EEA85A08E227@gmx.net> To: earlywarning@ietf.org Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) X-Y-GMX-Trusted: 0 Subject: [Atoca] Summary of "Requirement D2: Large Audience" Discussion X-BeenThere: earlywarning@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert \(atoca\) working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Feb 2011 10:10:14 -0000 Hi all,=20 thank you for your feedback on the long thread regarding the large = audience requirement.=20 Your feedback went in various directions, some of them were not related = to the initial question.=20 The initial question was about the refinement of the currently provided = text that does not further specify a **number** for large audience.=20 Two suggestions were made to deal with this issue:=20 1) Talk about broadcast 2) Segment the numbers into groups depending on the likely number of = recipients.=20 Both approaches sound fine to me but I believe the former might be more = appropriate because it points to the different architectural variants = currently described in the document.=20 I believe that this would be a good discussion topic for the upcoming = IETF meeting. In particular, it would be interesting to discuss what = tools we have in SIP to deal with the fulfillment of some of these = requirements. =20 The discussion then went on and lot of focus was spent on the = "acknowledgment" messages that a receiver may sent as a confirmation of = an alert delivery.=20 There, a number of issues were raised, such as=20 * At what layer does the ack happen? (e.g., SIP 200 OK, transport layer, = application layer ack) * Is the ack useful for cases were the alert message it targeted to a = specific set of receivers rather than broadcasted?=20 * Are we bound to the capabilities of the underlying communication = infrastructure?=20 * What are the scalability constraints?=20 * Is an aggregation mechanism for acks useful?=20 Ciao Hannes From hannes.tschofenig@gmx.net Sun Feb 27 02:21:22 2011 Return-Path: X-Original-To: earlywarning@core3.amsl.com Delivered-To: earlywarning@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B8B1D3A6844 for ; Sun, 27 Feb 2011 02:21:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.645 X-Spam-Level: X-Spam-Status: No, score=-102.645 tagged_above=-999 required=5 tests=[AWL=-0.046, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dkzyqpJTXyNH for ; Sun, 27 Feb 2011 02:21:21 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by core3.amsl.com (Postfix) with SMTP id 35ADB3A68EC for ; Sun, 27 Feb 2011 02:21:20 -0800 (PST) Received: (qmail invoked by alias); 27 Feb 2011 10:22:17 -0000 Received: from a88-115-222-204.elisa-laajakaista.fi (EHLO [192.168.1.3]) [88.115.222.204] by mail.gmx.net (mp067) with SMTP; 27 Feb 2011 11:22:17 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/R8QFJTEbRURToXvfxsjB38Q6hmYeOWZg0BIeSuq 1tcghqMV5letdS From: Hannes Tschofenig Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sun, 27 Feb 2011 12:22:13 +0200 Message-Id: <0D026F7A-8471-485B-B54E-8A0FEC293771@gmx.net> To: earlywarning@ietf.org Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) X-Y-GMX-Trusted: 0 Subject: [Atoca] Summary of "Language and Media Type" Discussion X-BeenThere: earlywarning@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert \(atoca\) working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Feb 2011 10:21:22 -0000 Hi all,=20 in the discussion around the language and media type your feedback = focused on the language part; the media type aspect wasn't really = touched.=20 In any case, I again think we need to differentiate two aspects here:=20 1) Policy For certain types of alerts governments may decide in what languages are = supported in alerts. In other cases the alert message author may make = that decision.=20 2) Technology=20 It would be important to have some mechanism to actually allow the = potential recipient to indicate what languages he or she prefers. Martin = suggested a Accept-Language header concept and Richard refined it.=20 The language tag in the CAP encoded alert, as raised by Art, would then = indicate in what language the specific alert is using. To address this issue in the document two modifications are needed:=20 a) In http://tools.ietf.org/html/draft-ietf-atoca-requirements-01 I = believe it is useful to clarify that we are talking about (2) and that = (1) may decide what is being used.=20 b) In http://tools.ietf.org/html/draft-rosen-atoca-cap-01 the text = Richard and Martin proposed would be added.=20 Ciao Hannes