Subject: RE: third alternative (was RE: [Sip] RE: Identity after reinvite)

From: "Peterson, Jon" <[email-masked]>
Date: Thu, 18 Nov 2004 15:46:30 -0500

> > Are we really going to tell end users of SIP that it's okay if such a
BYE
> > comes from an Edgar? What do I not understand here?
> 
> I will admit that this scenario seems pretty broken.
> 
> However, if the call to bob reached edgar, and he has done as you say, 
> it is futile for alice to reject the BYE. It is an indication that the 
> other party has hung up, and refusing it will not change that.

What I really meant here is that it makes no sense to provide Identity for a
request in the backwards direction from Edgar if he is not the intended
target of the call. Identity is useful only if it is going to factor into an
authorization decision regarding impersonation. If literally any identity in
the request must be accepted by Alice, rather than the unique identity of
Bob, then Identity is a null op and we should stop trying to engineer for
this case. This is the "fourth alternative" I alluded to in my last mail -
just say that request identity is not meaningful for any requests in a
dialog other than the dialog-forming request. I do think we can do better
than that, though, without creating serious problems for ourselves. If we
choose the fourth alternative, we will be allowing a certain security hole
to remain open, one that I believe we can close without too much trouble.

> If edgar is just a MITM trying to disrupt a valid call between alice and 
> bob, then maybe rejecting the BYE would accomplish something. But things 
> will still be messed up - for instance CSeq values will be wrong. 

By "reject" here I mean something more along the lines of "silently
discard". A spoofed request should not alter the dialog state in the
recipient.

> And if 
> edgar was in a position to do this with his own name, he could just as 
> easily have done it with bob's - aside from the issue of signing. Maybe
> it makes a little sense in that edgar may be able to get the BYE signed 
> with his own identity, though that will be tricky.

This is the rub. If Alice will accept only BYE requests from Bob, then
Identity adds value - Edgar cannot impersonate Bob because of Identity.
Identity only addresses threats of impersonation.

> I do agree it would be better if we could come up with some explicit way 
> to inform alice that the request has been delegated from bob to edgar. 
> Maybe it is just a matter of choosing among existing mechanisms, rather 
> than inventing something new. 

Totally agreed. sip-identity-02 suggested, albeit without sufficient
motivation and argument, that the requirements for such a mechanism are
satisfied by simple SIP redirection. I'm trying to keep that whole issue out
of the scope of sip-identity-03/04, and one way to do that, I think, is to
go along with something roughly like my "third alternative" proposal, which
basically works when it can, and is forward-compatible with a future
redirection-based responde identity model in which it would work all the
time.

> > Alice
> > sends a request to Bob. For some reason, Bob's domain thinks it is
> > appropriate to forward the request to, say, Carol. Why does Bob's domain
> > think that? Because someone, with some relevant permissions, provisioned
> > Bob's domain with a directive that requests for Bob should be forwarded
to
> > Carol. Of course, Carol personally does not possess Bob's credentials.
If
> > Bob is at Carol's station, though, then Bob will possess Bob's
credentials.
> > If the request arrives at Carol's station, and Bob fields the request,
then
> > Bob will be capable of providing his credentials to any auth service as
> > necessary. Carol will not. 
> 
> That of course assumes that Carol's phone is capable of prompting for 
> credentials, such as asking for Bob's password. Maybe someday most 
> phones will have that capability, but not today.
> 
> And what if bob just forwarded to carol because he is away?

In both of these cases, clearly, Identity should not be provided in the
backwards direction. If the responder isn't actually Bob, then it shouldn't
claim to be. But claiming to be someone else (Carol, or Edgar, or what have
you) doesn't help Alice to make any meaningful authorization decisions, I
think, unless Bob's domain has some way to communicate to Alice that the
request has been forwarded to that particular someone.

This isn't to say that there might not be some counterexamples to that last
principle - I mean, it's possible that the identity of the connected party
will make it clear how/why the request was retargeted, and that this will
seem reasonable from an authorization perspective to a caller with some
pre-knowledge of the callee - but the existence of such counterexamples does
not, I think, justify leaving this security hole wide open for those cases
where we cannot rely on human pre-association and presumption to fill in the
gaps of our protocol's authorization story. That is a non-deterministic
security environment.

Of course, if Bob's domain redirected rather than retargeting, the
underlying problem would be solved.

> 
> > If the user at Carol's station possesses Bob's credentials, then it is
> > reasonable for requests in the backwards direction to receive bear an
> > Identity header stating that this is from Bob; if not, then there
shouldn't
> > be an Identity header in the request. This seems very intuitive to me;
I'm
> > not sure why this is so radically implausible. I guess this begs the
> > question of why retargeting happens at all; if retargeting happens for
some
> > other reason than what I describe above, then it most likely violates
> > RFC3261 as I understand it.
> 
> In most scenarios I am aware of today, phone is either configured with 
> the credentials, or in a hotelling situation the phone requests 
> credentials to REGISTER somewhere. The hotelling situation is certainly 
> better from a security viewpoint, and it doesn't look like retargetting 
> at all to the caller.
> 
> But hotelling isn't always going to be possible. Perhaps bob is visiting 
> carol, and can configure his own AOR to retarget to carol, but can't 
> hotel on carol's phone and can't provide credentials for an incoming 
> call that was retargetted from bob to carol.
> 
> What does this violate in 3261?

Your two paragraphs above violate nothing about RFC3261. I was referring to
the motivations for legitimate retargeting (that is, that Bob's domain is
the only one that can retarget a request for Bob, and that Bob has an
association with his domain that allows him to control his contact list).

While I don't disagree with you that the case described above is possible,
I'm just saying that we shouldn't provide an Identity header in that case.

> One solution to this would be for for the biloxi.com server to act as a 
> b2bua, relaying the call to carol. Maybe that is a *model* to consider, 
> with hopes of finding a better implementation. That is also roughly the 
> model when a gateway is being used. We already know that in the gateway 
> case the connected party on the far side of the gateway can change, and 
> there are desires to convey that info.
> 

(weep)

Maybe we could at least consider redirection before we start suggesting that
this is a B2BUA problem.

I really think that the problem of mid-call changes in connected-party is a
very different case, and much more specialized than what we're concerned
with here. We're talking here about assuring the identity of the first and
second parties to a dialog at the time of dialog establishment. I'd like to
think that the ultimate solutions to the mid-call 'identity update' sort of
problems are more along the transfer/replaces line of thinking.

Jon Peterson
NeuStar, Inc.

> 	Paul

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 18 Nov 2004 17:08:41 -0500

Peterson, Jon wrote:
> this case.

Providing identity for edgar help with any *automatic* authorization 
decision by alice's UA. But knowing that it is really edgar may 
nevertheless be useful to alice. Maybe alice knows that edgar is an 
associate of Bob's. That would be sigificant compared to getting an 
unauthenticated identity.

You mention this later, but discount its value more than I do.

  This is the "fourth alternative" I alluded to in my last mail -
> dialog other than the dialog-forming request.

Well, it may be another step down the path to someplace better.

  I do think we can do better
> discard". A spoofed request should not alter the dialog state in the

But what if it was really a BYE from the other participant in my call? 
Just ignoring it isn't going to be a good thing. I think one would at 
least want to check it out - maybe send an update or reinvite to see if 
there is still a dialog up.

> Identity only addresses threats of impersonation.

But if the far end party really is Edgar rather than Bob (because of 
retargetting) then the end result of this strategy is that no signalling 
from Edgar will work. No putting on hold, etc. Essentially the call is 
broken. Not a great strategy.

> redirection-based responde identity model in which it would work all the

I think most of the things we are discussing are compatible with a 
future redirection based approach. What you propose is just a minimalist 
approach among those.

> claim to be.

I don't think anybody (except maybe you once in this thread) is 
suggesting that should be able to claim to be Bob and receive 
identification as Bob.

However, the current rules for dialogs to suggest that within the 
dialog, Carol or Edgar will have to claim to be Bob. One question is 
whether to have them do that, or instead change the To/From within the 
dialog. Unless we simply ban this case altogether (mandating redirect to 
avoid it), then we must at least answer this question.

  But claiming to be someone else (Carol, or Edgar, or what have
> gaps of our protocol's authorization story. That is a non-deterministic

I think it is better to have Carol say she is Carol than say she is Bob. 
And it is better yet for that assertion to be verifiably signed. Yes, it 
still leaves a security hole that we can work on filling.

> Maybe we could at least consider redirection before we start suggesting that

Yes, of course. But there are those people who feel in fact that it is 
important that Alice *not* know the call has been retargetted, or at 
least *where* it has been retargetted. Those folks won't go for 
redirection. Of course they also then don't want to report back the 
connected party id either, so maybe that is out of scope for this 
discussion.

Like most things, we probably need a toolbag of alternatives that can be 
used according to the policies of the players.

> problems are more along the transfer/replaces line of thinking.

Depending on your preference for mechanisms, it may or may not be useful 
to conflate these problems. I guess I agree with you that we can 
consider them separately.

	Paul

---

From: David R Oran <[email-masked]>
Date: Fri, 19 Nov 2004 09:30:08 -0500

> Maybe we could at least consider redirection before we start 
Redirection is generally cleaner than retargeting, but does not satisfy 
the "Monica property". It may be that a B2BUA is inescapable in those 
cases anyway.

> problems are more along the transfer/replaces line of thinking.
I tend to agree. It would be much cleaner if all 
identity/connected-party changes devolved to a flavor of transfer 
(except the Monica cases I mention above).

Dave.