Re: [Atoca] Requirement for Originator Authentication?

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: earlywarning-bounces@ietf.org <earlywarning-bounces@ietf.org>
> To: Hannes Tschofenig <hannes.tschofenig@gmx.net>; earlywarning@ietf.org <earlywarning@ietf.org>; Igor Faynberg <igor.faynberg@alcatel-lucent.com>
> 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@ietf.org
> https://www.ietf.org/mailman/listinfo/earlywarning
> _______________________________________________
> earlywarning mailing list
> earlywarning@ietf.org
> https://www.ietf.org/mailman/listinfo/earlywarning