[Atoca] Summary of "Requirement for Originator Authentication?" Discussion

Hannes Tschofenig <hannes.tschofenig@gmx.net> Sun, 27 February 2011 09:20 UTC

Return-Path: <hannes.tschofenig@gmx.net>
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 <earlywarning@core3.amsl.com>; 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 <earlywarning@core3.amsl.com>; 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 <earlywarning@ietf.org>; 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 <hannes.tschofenig@gmx.net>
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." <earlywarning.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Sun, 27 Feb 2011 09:20:03 -0000

Hi all, 

thank you for your feedback on the topic of originator authentication. 

From the responses I see three aspects emerging: 

1) Deployment choice vs. technological capability 

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. 

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. 

Other more sophisticated approaches (from a technology point of view) are trait-based authorization mechanisms. 

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? 

2)  Hop-by-hop vs. end-to-end authentication 

I got the impression that we need to allow both building blocks to be used rather than to focus on either one of them. 

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. 

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