RE: concrete proposal (was RE: third alternative (was RE: [Sip] R E: I dentity after reinvite))

["Peterson, Jon" <jon.peterson at neustar.biz>]

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