Re: [Atoca] Requirement for Originator Authentication?

Art Botterell <art.botterell@west.cmu.edu> Sun, 16 January 2011 23:49 UTC

Return-Path: <art.botterell@west.cmu.edu>
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 00F6E3A6C41 for <earlywarning@core3.amsl.com>; Sun, 16 Jan 2011 15:49:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.203
X-Spam-Level:
X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1]
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 EqdHfwIz0K8M for <earlywarning@core3.amsl.com>; Sun, 16 Jan 2011 15:49:46 -0800 (PST)
Received: from mail-yi0-f42.google.com (mail-yi0-f42.google.com [209.85.218.42]) by core3.amsl.com (Postfix) with ESMTP id 1BA853A6BA5 for <earlywarning@ietf.org>; Sun, 16 Jan 2011 15:49:46 -0800 (PST)
Received: by yia28 with SMTP id 28so2445447yia.15 for <earlywarning@ietf.org>; Sun, 16 Jan 2011 15:52:18 -0800 (PST)
Received: by 10.151.113.4 with SMTP id q4mr3568319ybm.156.1295221938431; Sun, 16 Jan 2011 15:52:18 -0800 (PST)
Received: from [10.10.1.90] ([200.6.58.236]) by mx.google.com with ESMTPS id u3sm1770862yba.4.2011.01.16.15.52.15 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 16 Jan 2011 15:52:17 -0800 (PST)
References: <D15CC605-98D7-4959-9CA3-7B1ADED306D6@gmx.net> <8B0A9FCBB9832F43971E38010638454F03F52595D6@SISPE7MB1.commscope.com>
In-Reply-To: <8B0A9FCBB9832F43971E38010638454F03F52595D6@SISPE7MB1.commscope.com>
Mime-Version: 1.0 (iPad Mail 8C148)
Content-Type: text/plain; charset=us-ascii
Message-Id: <915FDCF5-7C3E-4758-B6EB-38F0BDF09A84@west.cmu.edu>
Content-Transfer-Encoding: quoted-printable
X-Mailer: iPad Mail (8C148)
From: Art Botterell <art.botterell@west.cmu.edu>
Date: Sun, 16 Jan 2011 19:55:57 -0400
To: "Thomson, Martin" <Martin.Thomson@andrew.com>
X-Mailman-Approved-At: Sun, 16 Jan 2011 21:03:52 -0800
Cc: Igor Faynberg <igor.faynberg@alcatel-lucent.com>, "earlywarning@ietf.org" <earlywarning@ietf.org>
Subject: Re: [Atoca] Requirement for Originator Authentication?
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, 16 Jan 2011 23:54:21 -0000

I suspect we'll find that different carriers/gateways will insist on being able to apply their own authorization rules, and thus that end of things will be distributed perforce.  By the same token, I don't foresee a single global identification/credentialling scheme.  The best we can hope for, I suspect, is a reasonable degree of reciprocity among authorities.

The first question, I think, is whether there's a use case for anonymity in authority-to-public alerting; not sure what that would be.

The next question is how far it makes sense to go in specifying the form of an identification scheme.

Thanks!

- Art

On Jan 16, 2011, at 7:32 PM, "Thomson, Martin" <Martin.Thomson@andrew.com> wrote:

> On 2011-01-16 at 06:30:33, Hannes Tschofenig wrote:
>> Igor raised an interesting question during the meeting in context of
>> the security threats, namely:
>> 
>> " Do we have the requirement to authenticate the originator? "
> 
> The question that I heard was not so much related to authentication as it was to authorization.  There was also a question about whether authentication was identity-based or on some other property, like some asserted trait.
> 
> What statements can we make about how recipients (and relays) authorize the receipt (and sending) of alert messages?
> 
>> I couldn't provide him an answer during the meeting because I was not
>> quite sure whether he was asking the question in the style of
>> 
>> "Do we need end-to-end security or is a hop-by-hop security solution
>> good enough?"
> 
> In the context of this interpretation, I think that there's a real need to delegate alert distribution.  The scale of distribution makes intermediaries a valuable addition.  Relying on the integrity of relays makes the authorization question more difficult to resolve.
> 
> For something concrete, the relay case is probably the simplest.  I might trust my signalling peer to a certain extent.  I certainly don't trust them enough to generate the massive packet storm requested by an alert message.  They might say the alert comes from the government, but I might require better proof than their say-so alone.  Distributing an alert will cost me money and I want proof.
> 
> That's one argument.  The other argument says that peering relationships require a degree of trust that would not be broken without serious ramifications - enough to discourage its abuse.
> 
> The recipient case might have some interesting quirks.  Particularly in wholesale/reseller arrangements.  A recipient that relies on hop-by-hop might receive an alert from the network operator: an entity with whom they have no direct relationship.  For instance, no fewer than two different operators are involved in getting packets to my house, neither of which I have a business relationship with.  How would someone - ignorant of the convoluted business arrangements that underpin their Internet service - decide to authorize an alert that is relayed by either party?
> 
> --Martin
> _______________________________________________
> earlywarning mailing list
> earlywarning@ietf.org
> https://www.ietf.org/mailman/listinfo/earlywarning