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

From: Alan Hawrylyshen <[email-masked]>
Date: Mon, 18 May 2009 11:24:40 -0700

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.

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.

§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?

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

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.

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

§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?

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

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.

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.

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

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

Thanks,

Alan Hawrylyshen

---

From: "Scott Lawrence" <[email-masked]>
Date: Wed, 20 May 2009 22:03:09 +0000

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

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

> this. However the sentence as written reads oddly. Can we find another

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.

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

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

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

> Last paragraph on weak auth -- can you expand on this slightly to make

Yes, an example or two here would probably help.

> authorization indication in requests.

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

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

> REFER UAC authorized the action. This is unclear in the text and

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.

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

> impacts many areas. I look forward to seeing this document develop.

Thanks.

---

From: "Dale Worley" <[email-masked]>
Date: Tue, 26 May 2009 15:26:47 -0400

> use' indications being a great example of the two extremes.

I'm not sure that this is a problem in quite the way you write it.

All that is needed, I think, is for Bob to determine the information
which Alice is authorized to see.  From that information, Alice can
determine if that is enough information to satisfy her interests.

This approach avoids Alice having to be able to declare her interests,
and Bob having to interpret the declaration.

What makes the problem messy is if the question of what Alice is
authorized to know is variable or duration-sensitive.

Dale