Re: [dispatch] draft-lawrence-sip-3rd-party-authorization-00

["Scott Lawrence" <[e-mail]>]

On Tue, 2009-05-26 at 08:32 +0800, fanyanping wrote:
> Hi Scott，
> 
> I spend some time reading your draft，there is one place i don’t
> understand clearly, could you please explain more detail, thanks.
> 
> “The requirement for adjacency interferes with a property of SIP that
> is otherwise one of its great strengths: that a proxy (or other
> well-behaved Intermediate) need not understand every aspect of the
> requests and responses it forwards. 。。。。。。。。“
> 
> I’m understanding that you imply a new feature needs the Intermediate
> entites which make the authorization decision to be upgraded.
> However，Is there something associated with adjacency?
> 
Clearly this point needs elaboration... I don't know if you saw my reply
last week to Alan on this same point [1] - the example I gave was:
        
        Suppose I have a wiz-bang new feature.  I figure out how to negotiate
        sessions that use it in SIP, and implement it in some spiffy new UAs.
        Given a good SIP fabric, the feature works.  But this feature has some
        characteristics that mean that I want it to be subject to an
        organizational security policy (using it has privacy implications, or it
        costs lots of money).  If I don't want to trust the endpoints to
        evaluate the policy (for reasons described elsewhere), then I need to
        have something else do so.  But the next-hop device those spiffy new UAs
        are attached to is my old-reliable edge intermediate; it's hard to get
        changes made to that, and it doesn't know anything about my new wiz-bang
        feature, so there's no way to get it to do any security policy
        evaluation for me on that feature.   If delivery implies authorization,
        then all an attacker needs to do is find a way to get the request to the
        next-hop old-reliable edge intermediate (probably not hard).
        
Authorization-by-delivery is weakened by each hop (including the last
one) by which the authorizing entity is separated from the protected
resource.  If the authorizing entity and the protected resource are
separated by only one hop, and if that hop is always TLS used so that
the protected resource can authenticate the authorizing entity, then
there is little opportunity for an attacker to exploit the separation;
but if there is more than one hop, then TLS cannot be used to
authenticate the authorizing entity and the authorization-by-delivery
model breaks down.  

> In addition, i agree that the issues described in your draft are
> really very important. But I don’t understand clearly how the
> requirement of “Authorizing Third Party” can solve them. I can’t get
> the requirements you proposed from these problems.

I guess I'd have to ask you what problem you think is not addressed.

> PS: 
> 
> there is one suggestion about the section 2.2, I think the following
> paragraphs could be in the section 2.2.1 and have a new title “User
> Agent Based Authorization”. Because all of them are describing the
> problems of “User Agent Based Authorization”.

That's a thought... 


[1] http://www.ietf.org/mail-archive/web/dispatch/current/msg00070.html