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

From: "Peterson, Jon" <[email-masked]>
Date: Thu, 18 Nov 2004 02:04:14 -0500

> > 3) Change nothing in To/From. Requests in the backwards direction in a
> > dialog may go through the authentication service of the domain indicated
in
> > the host portion of the From header of the request. If that is not
possible,
> > do not supply request identity for such messages.
> 
> This is pretty close to what I had just suggested in a mail I wrote a 
> few minutes ago. I should have read the whole thread before responding I 
> suppose ;)

I'm glad we're on the same page (or at least the same chapter), but from the
remainder below, it sounds like we're on the same page for very different
reasons.

> The difference between this and what I had proposed is that I think a UA 
> should be *allowed* to change the From in its outbound request.

Well, we can't stop the callee UA from changing the From header field value
in its backwards-direction requests, yes, but I certainly think that the
caller UA should discard such requests. 

For me, this comes down to a very, very simple case: Alice sends a call to
Bob, and then in the middle of the call, she gets a BYE request from Edgar.
Does Alice accept the BYE or not? This is perhaps the simplest authorization
decision we could ask a client to make, and what I keep hearing people say
is that it's okay if the BYE comes from Edgar instead of Bob. I'm really not
sure how this could possibly be okay - this is unrelated to whether SIPS is
used or any other transitive security is used (see the end of this message);
this is the fundamental question of who should be authorized to terminate a
call.  If that set of authorized parties isn't identical to the first and
second parties in the call, then I think we're creating a non-deterministic
security environment. 

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?

> > In cases where the user contacted
> > at chicago does not possess credentials to authenticate themselves to
> > biloxi, I think it would be fair to say that requests in the backwards
> > direction should not get an Identity header. 
> 
> I think that it will almost never have such credentials. If it did, this 
> wouldn't be retargeting.

Again, there's something fundamental I don't understand here, then. 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. 

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.

> > I've gotten a
> > lot of feedback (from Paul, Kumiko and others) that we should try to
weaken
> > the requirement for direct TLS, and I intend to add some text to the
next
> > version about some specific ways in which it is still acceptable to
provide
> > identity even if a direct TLS connection cannot be formed. Certain forms
of
> > weakness there could be beneficial to this approach.
> 
> I think that having non-direct connections is a reasonable thing; 
> generally my view has been that it should be possible to disaggregate a 
> monolithic proxy into components in the same network, each of which is a 
> SIP proxy performing parts of the overall processing in a domain. As 
> long as appropriate security and trust relationships are maintained 
> between these component proxies in a domain, I think equivalent security 
> is afforded.

I'm largely sympathetic to this argument, yes, and thus I agree that the
text should be amended. What I think should replace the strong requirement
for TLS is something to the effect that the UA must have an association with
an auth service that has a certain set of qualities - qualities that would
be satisfied by a direct TLS connection, but which hypothetically might be
derived through some other means.

> As a follow up to my previous note, I tihnk part of the difficulty here 
> is a difference in view about the problem being solved by asserted 
> identities in the reverse direction. In my view, the sips mechanism 
> provides an assurance ot the caller that the call got to the eventual 
> target as a result of authorized forwarding at each hop along the way. 

The sufficiency of SIPS for this purpose must depend on the practical
efficacy of the mechanism, not its theoretically efficacy. My own
reservations about the hops beyond the target administrative domain of a
SIPS request, coupled with Dean's valid concern that SIPS is not verifiable
by the endpoints, cast considerable doubt on the assurance that SIPS
provides. SIPS provides no assurance to the caller whatsoever - SIPS is
merely heaved over the wall at the network, and the caller can only hope
that the directive is obeyed. Even if the SIPS directive is strictly obeyed
by all intermediaries, given the laxity surrouding last-hop delivery,
potentials for eavesdropping arise. Eavesdropping alone is sufficient for an
attacker to construct a forged BYE request with a valid Identity header. 

That much said, I do think there would be some value in having an identity
mechanism that prevents trivial initial-request impersonation without
addressing eavesdropping. But if we so reduce the scope, that would argue
for a fourth alternative: something like "in the context of a dialog,
request identity is only used for the dialog-forming request". Identity
isn't adding any appreciable value to any subsequent requests.

> Thus, the identity of requests in the reverse direction is not used to 
> *authorize* whether or not the request should be processed. Rather, it 
> serves merely as a reliable identification mechanism, as authorization 
> is provided by sips.

If you trust SIPS far enough to authorize backwards-direction requests and
responses reliably, then surely Identity would be superfluous. What
additional properties would Identity convey beyond those that can be assumed
from SIPS?

This may be the crux of our disagreement. I don't believe that SIPS is
strong enough to substantiate an authorization decision on the part of the
caller. Moreover, I'd like to believe that sip-identity can be used in the
absence of SIPS; that is, I don't think that every potential callee must
publish a SIPS URI in order for a caller to make reasonable authorization
decisions the source of requests in the backwards direction in a dialog. In
the long term, when we want to provide a mandatory-to-implement mechanism
for ascertaining identity, I don't think this can require SIPS as it is
written now, anyway.

The authorization decision made by the caller should be based on a
cryptographic end-to-end assertion stating that the intended domain vouches
for the callee; it should not merely be inferred from a speculation that a
directive like SIPS was universally obeyed by an unfathomable set of unknown
intermediaries.

In summary, this is the ultimate distinction between the "trusted networks"
of RFC3325 and the aptly-named "long term cryptographic identity solution"
we envisioned years ago. If something like SIPS is genuinely sufficient,
then I'd argue that P-Asserted-Identity provided by the first-hop proxy in
the request path would be all we'd need, regardless of whether we're talking
about dialog-forming requests or requests in the backwards direction in a
dialog.

Jon Peterson
NeuStar, Inc.

> -JOnathan R.
> 
> 
> -- 
> Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
> Director, Service Provider VoIP Architecture   Parsippany, NJ 
> 07054-2711
> Cisco Systems
> [email-masked]                              FAX:   (973) 952-5050
> http://www.jdrosen.net                         PHONE: (973) 952-5000
> http://www.cisco.com
> 

_______________________________________________
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 14:42:56 -0500

Trimming the discussion...

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

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

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.

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

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

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.

	Paul