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

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

On Mon, 2009-05-18 at 11:24 -0700, Alan Hawrylyshen wrote:
> Scott;
> 
> I spend some time over the weekend reading your draft. I think it is a  
> great start on an important problem. This situation can pop up in many  
> places where the operations or administrative domain wants to  
> centralize decision making around authorization.
> 
> Here are some comments that I made while reading the draft, please let  
> me know if you want any sort of clarification:
> 
> 
> §2.1 - very clear and concise intro! Too bad everyone doesn't take the
> time to lay out the problem and motivation this clearly.

I'll be honest - the ID-nits tool had to remind me to write it :-)
Thank you for the endorsement of its utility to human readers.

> p.5 § 2.2 par 10
> 
> This hints at a much larger problem in SIP.
> Can Bob determine from Alice's subscription requests the (minimum)
> degree of disclosure required to satisfy Alice's interests? How can
> Bob know the application of the information requested. As you indicate
> later in the draft, this remains a significant challenge, although it
> is quite likely outside the scope of your draft. The JOIN vs 'line in
> use' indications being a great example of the two extremes.

Yes - in SIP we spend quite a bit of time and effort creating protocol
mechanisms that can be used in support of multiple end-user
"features" (so much so that we've had to create a whole working group to
describe which is the preferred way to do the features). This is, I
think, mostly a good thing, but it does lead to exactly this ambiguity -
we don't have a way to 'label' a request as being for a particular
purpose.  I had not thought of trying to include solving that 'problem'
with a solution to third party authentication, but it's something worth
noting and perhaps watching for opportunities to address.

> §2.2.1 - on list disclosure
> You said "decreases the security of the list".
> I'm fairly certain that you are asserting that broad disclosure
> somehow impacts the security of the system as a whole -- I agree with
> this. However the sentence as written reads oddly. Can we find another
> way to word this?

You mean this:

        ... Even if the problem is just one of storing the appropriate
        access control lists, it is not reasonable to replicate the
        lists into all UAs (and perhaps not desirable from a security
        perspective, since this decreases the security of the lists
        themselves).

Yes, that's what I meant: if every phone in the company knows which
identities have the most privilege, then it's probably not hard for an
attacker to pick the identity to go after.  I agree that this could be
made more clear.
        

> §2.2.2 use of IP
> 
> I don't think spoofing is the fatal problem here - I think tying L3
> and L4 together with an ACL is the fatal move in this approach. You
> are essentially throwing DNS in the trash and removing the scalability
> and mobility aspects that it brings in order to 'fool yourself' into
> thinking that an IP ACL is security in some form. Moreover (and
> related) I think that tying your UA to specific IP addresses
> complicates the delivery of highly available and reliable services,
> once again, bypassing the benefits of DNS.

Agreed.  There are so many things wrong with using IP addresses as
authenticators that I debated whether or not to make this an even
shorter paragraph.  Alas, it is incredibly common in practice.

> TLS Peers
> "signalling" vs "signaling" your call, I'm not sure which way is
> preferred but I get teased for the double-l all the time.

I am always willing to accept spelling advice from anyone - in this, at
least, I know my limits.

> @ the end of §2.2.2 on the rollout of new features and the adjacency  
> problem ...
> Can you restate this more clearly? I'm understanding that you imply
> there is a new feature that requires authorization in a central place
> and that the mutual TLS condition only permits authorization by
> receipt for a single hop. This part, I understand clearly. What I do
> not understand is how a 'new feature' impacts this problem. I see this
> as a problem no matter what. In another light, is this any different
> that "last hop" authorization? I think I need some concrete example of
> the unique aspect of a new feature in the TLS model. I certainly
> understand that there can be no intermediary in order to successfully
> apply the TLS as authorization paradigm. At least not without signing
> the message contents -- something that you discuss further on
> (indirectly) in the requirements section.

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

The great thing about proxies or other well-behaved intermediates is
that many new endpoint features work through them with no changes.
Using delivery as an enforcement mechanism breaks that very nice
quality.

> §2.3.1
> I see you share the concern that I have around minimal disclosure.
> Last paragraph on weak auth -- can you expand on this slightly to make
> it more clear?

Yes, an example or two here would probably help.

> §2.3.3
> s/therefor/therefore/g
> 
> §3
> Consider explaining "Enforcing UAS" in the terms section, it might
> make the diagrams supremely obvious instead of merely clear.
> I presume that these are UAS'es that are tasked with honoring the
> authorization indication in requests.

oops  - that definition may end up being even more hand-wavy than the
others, but it's clearly needed.

> Figure 2
> Redirect based generation of authorization indications  could be
> problematic, but I see that you explicitly require that auth. inds. be
> something that can be copied from one request to another. I feel that
> this requirement MAY create some tension with a general security
> review and I look forward to exploring how to solve this problem and
> the relevant security implications this property may bring.

Yes, I think this one is going to be a challenge, and it may well be
that not all third party authorizations will have the same degree of
'security strength'.  I think that this is acceptable in practice, but I
recognize that others may differ.  I include this as a goal so that it
can get attention because it's a problem I've frequently encountered in
my own product (and for which I have a crude solution), but reasonable
people may differ on this.  I look forward to lively discussions...

> Figure 4
> It seems to met hat the regerred UAC is placing an auth ind into 'ar'.
> Did that auth ind originate in the inbound REFER or did it generate it
> locally? Is this relevant? I presume that it originates with the REFER
> UAC since the point is to indicate to the ultimate target that the
> REFER UAC authorized the action. This is unclear in the text and
> diagram to me.

Yes, my intent was that the REFER 'carries' an authorization that is
incorporated into the request that the referred party creates.

Example - I send you a REFER that instructs you to make a call that I
have the authority to make but that you do not.  By including an
auth-indication in my REFER that you can use in your INVITE, I enable
you to make the call on my authority.

> R10 - "determine the identity"
> This is a strong concept. Did you mean "determine the identity" or
> merely "note that this is not the same party" or that "this is a URI
> for the party in question". Where on the identity sliding scale does
> this requirement fall? (Purely from an identity point of view).

I'm not sure how to answer that.  Informally, I should be able to tell
who provided the authorization as distinct from who originated the
request.  I suspect that this gets us back to 'what is identity really'
again...

> Overall; great draft and in my opinion, this is important work that
> impacts many areas. I look forward to seeing this document develop.

Thanks.