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

[Alan Hawrylyshen <[e-mail]>]

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