Re: [Atoca] Requirement for Originator Authentication?

Art Botterell <> Sun, 16 January 2011 23:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 00F6E3A6C41 for <>; Sun, 16 Jan 2011 15:49:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.203
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id EqdHfwIz0K8M for <>; Sun, 16 Jan 2011 15:49:46 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 1BA853A6BA5 for <>; Sun, 16 Jan 2011 15:49:46 -0800 (PST)
Received: by yia28 with SMTP id 28so2445447yia.15 for <>; Sun, 16 Jan 2011 15:52:18 -0800 (PST)
Received: by with SMTP id q4mr3568319ybm.156.1295221938431; Sun, 16 Jan 2011 15:52:18 -0800 (PST)
Received: from [] ([]) by with ESMTPS id u3sm1770862yba.4.2011. (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 16 Jan 2011 15:52:17 -0800 (PST)
References: <> <>
In-Reply-To: <>
Mime-Version: 1.0 (iPad Mail 8C148)
Content-Type: text/plain; charset=us-ascii
Message-Id: <>
Content-Transfer-Encoding: quoted-printable
X-Mailer: iPad Mail (8C148)
From: Art Botterell <>
Date: Sun, 16 Jan 2011 19:55:57 -0400
To: "Thomson, Martin" <>
X-Mailman-Approved-At: Sun, 16 Jan 2011 21:03:52 -0800
Cc: Igor Faynberg <>, "" <>
Subject: Re: [Atoca] Requirement for Originator Authentication?
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, 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.


- Art

On Jan 16, 2011, at 7:32 PM, "Thomson, Martin" <> 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