Re: [Atoca] Requirement for Originator Authentication?

Brian Rosen <> Mon, 17 January 2011 16:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DFA643A6F45 for <>; Mon, 17 Jan 2011 08:07:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -103.357
X-Spam-Status: No, score=-103.357 tagged_above=-999 required=5 tests=[AWL=0.242, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id kkmZ7x10q263 for <>; Mon, 17 Jan 2011 08:07:46 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 262A93A6F42 for <>; Mon, 17 Jan 2011 08:07:46 -0800 (PST)
X-ASG-Debug-ID: 1295279882-0f8330540007-3cgWCS
Received: from ( []) by with ESMTP id cQl04iGHlfrm4Oyb; Mon, 17 Jan 2011 07:58:10 -0800 (PST)
Received: from ([] by with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from <>) id 1Per4x-0001kM-Sg; Mon, 17 Jan 2011 07:33:16 -0800
Mime-Version: 1.0 (Apple Message framework v1082)
X-ASG-Orig-Subj: Re: [Atoca] Requirement for Originator Authentication?
Content-Type: text/plain; charset=us-ascii
From: Brian Rosen <>
In-Reply-To: <>
Date: Mon, 17 Jan 2011 10:33:07 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <FDFC6E6B2064844FBEB9045DF1E3FBBC024A1E58@BD01MSXMB016.US.Cingular.Net> <>
To: Richard L. Barnes <>
X-Mailer: Apple Mail (2.1082)
X-Barracuda-Start-Time: 1295279889
X-Barracuda-Spam-Score: 0.00
X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.5 tests=BSF_SC5_SA210e
X-Barracuda-Spam-Report: Code version 3.2, rules version Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 BSF_SC5_SA210e Custom Rule SA210e
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 16:07:48 -0000


Our experience is that it's hard to get S/MIME implementations, but maybe we could do it for this one.

In nearly every case, we don't want encryption.  We want authentication and probably integrity protection.  So implementing S/MIME gets you that, but you can ignore it if you want to.  Might work.

I do think hop by hop works also.


On Jan 17, 2011, at 10:25 AM, Richard L. Barnes wrote:

> To say this differently: The authentication and authorization applied in a given deployed system is decided by the entities operating that deployment.  The ATOCA framework should allow for strong authentication and authorization, and provide appropriate mechanisms, but not require any particular mechanism to be used.
> With regard to "end-to-end" vs. "hop-by-hop": Clearly hop-by-hop authentication/authorization is critical -- especially on the first hop, where the message is introduced.  But it's also trivial: Just use TLS with client authentication.  
> End-to-end is nice to have, but much harder in any sort of global context because of the problems with establishing trust anchors.  (Does my phone have to have a TA for every emergency authority in the world?)  In this case, I think the optimal solution might be more of an "end-to-middle" solution.  The originators and relays are part of a semi-closed system, at least to the degree that you could expect them to coordinate on trust anchors.  So you could enable every entity down to the last gateway to validate the authorization for a message, even if the client can't.
> That said, I think the required technology is probably the same as for true end-to-end.  The obvious answer, IMO, is simply to pass CAP in S/MIME.
> --Richard
> On Jan 17, 2011, at 1:34 AM, DALY, BRIAN K (ATTCINW) wrote:
>> 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.
>>  +1.425.580.6873
>> -------
>> 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?
>> --Martin
>> _______________________________________________
>> earlywarning mailing list
>> _______________________________________________
>> earlywarning mailing list
> _______________________________________________
> earlywarning mailing list