Re: [Atoca] Requirement for Originator Authentication?

"DALY, BRIAN K (ATTCINW)" <> Mon, 17 January 2011 06:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 310733A6E7E for <>; Sun, 16 Jan 2011 22:31:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -106.077
X-Spam-Status: No, score=-106.077 tagged_above=-999 required=5 tests=[AWL=0.522, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id OgUyeJuIUQKL for <>; Sun, 16 Jan 2011 22:31:52 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 047E33A6E7B for <>; Sun, 16 Jan 2011 22:31:51 -0800 (PST)
X-VirusChecked: Checked
X-StarScan-Version: 6.2.9; banners=-,-,-
X-Originating-IP: []
Received: (qmail 32576 invoked from network); 17 Jan 2011 06:34:24 -0000
Received: from (HELO ( by with DHE-RSA-AES256-SHA encrypted SMTP; 17 Jan 2011 06:34:24 -0000
Received: from (localhost.localdomain []) by (8.14.4/8.14.4) with ESMTP id p0H6YNis021917; Mon, 17 Jan 2011 00:34:23 -0600
Received: from td03xsmtp007.US.Cingular.Net ( []) by (8.14.4/8.14.4) with ESMTP id p0H6YJiY021864; Mon, 17 Jan 2011 00:34:19 -0600
Received: from BD01XSMTP003.US.Cingular.Net ([]) by td03xsmtp007.US.Cingular.Net with Microsoft SMTPSVC(6.0.3790.4675); Mon, 17 Jan 2011 00:34:19 -0600
Received: from BD01MSXMB016.US.Cingular.Net ([]) by BD01XSMTP003.US.Cingular.Net with Microsoft SMTPSVC(6.0.3790.4675); Sun, 16 Jan 2011 22:34:18 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: base64
Date: Sun, 16 Jan 2011 22:34:18 -0800
Message-ID: <FDFC6E6B2064844FBEB9045DF1E3FBBC024A1E58@BD01MSXMB016.US.Cingular.Net>
Thread-Topic: [Atoca] Requirement for Originator Authentication?
Thread-Index: Acu06rVOLwvhgOa0T5WSS8cq4sczfAA5M37gABBDhy0=
To: <>, <>, <>, <>
X-OriginalArrivalTime: 17 Jan 2011 06:34:18.0934 (UTC) FILETIME=[91A39560:01CBB610]
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: Mon, 17 Jan 2011 06:31:57 -0000

Authorization to initiate alerts  should be provided by the entity that is initiating the alerts and not ATOCA. ATOCA should authenticate the receipt of the alerts is from a trusted source.
Brian K. Daly
   Sent to you by AT&T... 
   America's Fastest Mobile Broadband
       Network.  Rethink Possible.
Sent from my Blackberry

----- Original Message -----
From: <>
To: Hannes Tschofenig <>et>; <>rg>; Igor Faynberg <>
Sent: Sun Jan 16 15:32:09 2011
Subject: Re: [Atoca] Requirement for Originator Authentication?

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?

earlywarning mailing list