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

From: fanyanping <[email-masked]>
Date: Tue, 26 May 2009 08:32:19 +0800

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?

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.

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

Specific paragraphs as below:

from

“   Most specifications of SIP mechanisms expect that a request will be

    subjected to an authorization decision by the receiving User Agent

    Server.  If the Alice's UA sends a request to Bob's UA, it is Bob's

    UA that decides (presumably after authenticating that the request is

    really from Alice) whether or not Alice should be allowed whatever

    access the request requires.  This model is the correct one in many

    cases, especially those in which the actual authorization decision

to

      The request might be such that the user either could not

      understand the question or be such that the user cannot reasonably

      be expected to understand why permission should be granted.  If

      Bob were asked whether or not Alice should be allowed to receive

      dialog event notices regarding the call he is on now, he would

      probably not understand the question and be annoyed at the

      interruption of his call; he could not tell whether this was in

      support of a future request to Join the call, a future request

      that Alice be able to call him when he becomes available, or just

      in support of lighting the Busy Lamp for his line on Alice's

      phone.”

If there is any problem, please correct me. thanks :)

Best Regards.

nancy

*******************************************************************
This email and its attachments contain confidential information from HUAWEI,
which is intended only for the person or entity whose address is listed
above.
Any use of the information contained herein in any way (including,
but not limited to, total or partial disclosure, reproduction, or
dissemination) by persons
other than the intended recipient(s) is prohibited. If you receive this
e-mail in error,
please notify the sender by phone or email immediately and delete it!
*******************************************************************

---

From: "Scott Lawrence" <[email-masked]>
Date: Tue, 26 May 2009 14:42:56 +0000

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

> 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

---

From: fanyanping <[email-masked]>
Date: Wed, 27 May 2009 13:38:52 +0800

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

   
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 :) 

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

---

From: "Scott Lawrence" <[email-masked]>
Date: Wed, 27 May 2009 10:30:15 -0400

> Party” can solve the problem.

If I have a new capability that needs new security evaluation
capability, with third party authorization I can add the ability to do
that evaluation anywhere in my network, but use the Authorization
Indication to carry that to the appropriate point of enforcement.  The
enforcement point does not need to understand general security policies,
or characteristics of new services - it only needs to understand how to
validate an Authorization Indication.  This separation of
responsibilities allows me to incrementally deploy new features while
maintaining enforcement of my security policies.