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

[fanyanping <[e-mail]>]

 

-----邮件原件-----
发件人: Scott Lawrence [mailto:[e-mail]] 
发送时间: 2009年5月26日 22:43
收件人: fanyanping
抄送: [e-mail]
主题: Re: [dispatch] draft-lawrence-sip-3rd-party-authorization-00

> 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. 

it's very clear, thanks :) 

    > > 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.

the section 3  in your draft describe the problem that  authorizing entity
doesn't know the service which the request is being used to implement , so
it  can not  make the authorization decision  appropriately. is it right?
I don’t understand clearly how the requirement of “Authorizing Third
Party” can solve the problem.

 


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