An alternative argument has been made that the notion of an
unanticipated
'connected party' is inherently antithetical to security, because the
local
UA will be forced to accept a request from any party, as the potential
set
of valid connected parties in unbounded.
This is true only in the absence of explicit delegation.
Of course, and the only reason the text above does not say so is because I
was intentionally trying to phrase this in a way that is silent about the
whole 'connected party' issue.
As an aside, I think "explicit delegation" is a very good term for what we
need here, when we get around to addressing the 'connected party' problem.
At the risk of
skipping ahead of your well-done chain of logic here, I think that we
have in SIP a large number of scenarios (retargeting, REFER,
Third-party control) where in the absence of explicit delegation we
either (a) have no security, (b) force cooperating parties to use
impersonation, or (c) in some cases, can rely on transitivity
properties. Despite the complexity, we may be better off tackling the
delegation problem now rather than allowing half-assed things to
use/abuse the identity stuff because it solves a part of the problem
(albeit a large part), but not enough.
Well... that really depends on your value of "now". I think we can do
request identity, frankly, without solving the explicit delegation problem.
When explicit delegation is resolved, then we can describe its relevance to
identity. In the interim, we can just say that the Identity header isn't
supplied for requests in the backwards direction during a dialog when
retargeting has occurred. Perhaps I only think this language makes sense
because I believe that when we get through with the explicit delegation
problem, we won't be doing "retargeting" any more as such.
Given that RFC3261 permits UAS's to change the From header field value
(irregardless of whether or not the sip-identity mechanism is used), the
question here is how should an authentication service, as defined in
sip-identity, treat such requests? Should it add an Identity header,
proxy
them, discard them, etc? Should sip-identity recommend that the From
header
be changed in this manner when a request has been retargeted?
It would be nice if the identity service did not have to be context
aware and just signed identity headers for any request from a source it
was authoritative for. Unless I misunderstand you I think you are
contemplating the identity service being authz policy aware, and my
intuition tells me that's a bad idea.
At this point in the note, anyway, I'm just contemplating the sort of
questions that seem to have been asked in the thread, not endorsing any
solutions. I agree with you that ideally, the auth service should just sign
the requests that it can, and not sign the requests that it can't.
We add some text about dialogs, and about the use of the Identity header
during a dialog. Obviously, the use of identity for dialog-forming
requests
is a no-brainer (this is the standard 'caller-ID' assurance).
Futhermore,
point out that if the intended second party is actually the connected
party,
identity can be supplied normally in requests in the backwards
direction.
Stipulate that an auth service instantiated in a proxy MUST Record-Route
itself in a dialog-forming request, so that the auth service can
recognize a
mid-dialog request.
I think I understand what you mean here, but the words could be better.
I think you are saying that "if a sip server acts as an auth service
and proxies a request that it auth'ed itself, it MUST record route".
Yes.
The Identity header simply would not be provided if the connected party
is
different from the party to which the local UA sent the request.
Why? If the auth service can authenticate the From in the request, why
should it refuse to do so?
My language here is imprecise, yes, I mean something more like "the Identity
header simply would not be provided if the auth service is not responsible
for the domain of the From header field of the request." If we couple this
with the further notion that changing the From header field of requests in
the backwards direction within a dialog is NOT RECOMMENDED because it may
surprising to the originator of the dialog, I'm cool with that.
Anyone unhappy with that?
Modulo my one issue above, I'm ok with the identity part, but as I
mentioned, doing just this doesn't actually solve anything other than
getting identity done (which is laudable and necessary).
Right, my ambitions are no greater than that at the moment. Once we're all
on the same page here, we can start diving into the explicit delegation
issue in more detail as a prelude to tackling response identity.
I don't want
to slow identity down UNLESS there's reason to believe we will have
backward compatibility problems when we introduce delegation, OR we
think that identity will get abused or ignored because too many
real-world situations really need delegation.
I'm not sure there's much potential for abuse here, and as long as we don't
rule out any important use cases, it faces no more than the usual
probability of being ignored. The most essential problem that people want to
solve is the dialog-forming request identity problem - essentially, the
"caller-ID" problem. That has immediate pay-off in the marketplace. As long
as we can tackle this in a way that doesn't damage our prospects of doing
more work on corner cases in the future, I think we'll be okay.
Jon Peterson
NeuStar, Inc.
Dave.
David R. Oran
Cisco Fellow
Cisco Systems
7 Ladyslipper Lane
Acton, MA 01720 USA
Tel: +1 978 264 2048
Email: oran at cisco.com
Jon Peterson
NeuStar, Inc.
_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip