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

From: "Peterson, Jon" <[email-masked]>
Date: Mon, 22 Nov 2004 20:28:52 -0500

In the interests of trying to get this thread strictly onto the problems
with request identity, let me try to articulate the major point of
contention here, and make a concrete proposal that attempts to incorporate
the discussion to date.

The argument has been put forward that when a request travels in the
backwards direction in a dialog, it should be permissable for the remote UA
to change the addr-spec element (and potentially anything other than the
tag) in the From header field such that the new From header will not
correspond with the To header of the dialog-forming request. This seems like
an intuitive approach when a request has been retargeted, and consequently
the entity identified in the To header field of the dialog-forming request
is not the entity sending requests in the backwards direction (the From
header field of such requests provides, in this case, the 'connected
party'). RFC3261 allows the contents of the To and From headers to be
altered by the parties to a dialog, with the caveat that this practice is
known not to be compatible with RFC2543. 

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.

Clearly, there are a number of possible ways to attack the connected party
problem, and not all of them have any impact on the sip-identity solution.
The main benefit of changing the From header is that in cases of
retargeting, the remote UA can thereby use the From header to provide
'connected party' information (rather than defining some new header or
something). The main downside is that the local UA will receive a request
within the dialog from a party other than the party to which the
dialog-forming request was sent, and that accordingly, attackers can easily
gain control of the dialog. In this environment, it is impossible to make
any automatic authorization decision about the validity of the request, and
the user of the local UA may or may not have some other means to think that
the request should be authorized, based on who the connected-party is.
Accordingly, the value of providing an Identity header for such requests is
questionable, since it isn't clear what impersonation threat might be met by
providing identity here. Really, the only possible motivation for using
sip-identity in this threat model is a case where a fourth party, Eve,
impersonates Edgar, anticipating that Alice knows that Edgar is an associate
of Bob, and that thus, when Alice calls Bob, it would be unsurprising if
Edgar answered. That begins to make my head hurt.

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?

Currently, sip-identity-03 is silent about dialogs and their impact, if any,
on signing requests. It does say that an auth service MUST NOT provide an
Identity header for the request if it is not responsible for the domain
provided in the From header field of the request. Furthermore, the text
suggests that if the auth service is not responsible for the domain in the
>From header field, it MAY just proxy the request normally.

Given all of this, let me make a concrete proposal for sip-identity-04 which
attempts, for the most part, to dodge the issue of how we solve
connected-party:

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.

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. We keep the
MUST NOT for providing the Identity header in cases where the auth service
is not responsible for the domain in the From header field, but upgrade the
normative strength of the proxying MAY to STRONGLY RECOMMENDED (if the auth
service does not proxy in this instance, failures of basic SIP operations
can occur). This way, if an auth service in the request path sees a
backwards-direction request, and knows that it is mid-dialog, it can just
proxy the request normally if it is not responsible for the domain in
question.

Provide no recommendation that the From header field should be changed to
reflect the 'connected party' when the Identity mechanism is used; in fact,
RECOMMEND against doing so. Provide a reference to future work on this
'connected-party' problem.

Anyone unhappy with that?

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 [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: David R Oran <[email-masked]>
Date: Tue, 23 Nov 2004 10:45:10 -0500

> contention here, and make a concrete proposal that attempts to 
Thanks, this is a useful and cogent description/context for figuring 
out what the options are.

> of valid connected parties in unbounded.
This is true only in the absence of explicit delegation. 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.

> gain control of the dialog.
Unless the retarget is explicitly delegated...

> In this environment, it is impossible to make
Impossible is a bit too strong, but the general case of retargeting 
does have this problem.

> providing identity here.
Questionable only if it is not extended to allow SAML or some other 
explicit means of delegation.

> Really, the only possible motivation for using
For the 1-degree transitive closure of buddy-lists this does not make 
my head hurt and in fact might be quite natural in many IM and 
push-to-talk style-applications. For arbitrary n-degrees-of-separation 
scenarios I agree with you completely.

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

>> From header field, it MAY just proxy the request normally.
This seems simple and keep the identity service out of authz policy.

> itself in a dialog-forming request, so that the auth service can 
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".

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

> We keep the
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). 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.

Dave.

David R. Oran
Cisco Fellow
Cisco Systems
7 Ladyslipper Lane
Acton, MA 01720 USA
Tel: +1 978 264 2048
Email: [email-masked]

---

From: Dean Willis <[email-masked]>
Date: Tue, 23 Nov 2004 12:06:28 -0600

I try to keep a running list of things  that turned out to be a royal 
pain that needs (or needed) fixing. Some of these things sounded cool at 
first, and I championed them.  Others I never did like. Some of these 
things I'm not allowed to suggest deprecating anymore -- we took a hum 
on forking a few meetings back. One of these days I'm going to get this 
list better organized and  post it someplace more persistent in the hope 
that it may assist in avoiding repeptition of mistakes. And someday, 
perhaps we can do something about some of these quirks.

To-date, I believe the Evil List includes:

1) Replacing the Request-URI at each hop while routing was Evil. We 
fixed this with Loose Routing mode, which is still slightly Evil.

2) Abusing To and From to indicate branches is Evil. We should have left 
these as real endpoint identifiers.

3) Forking is Evil.

4)  Allowing (and requiring)  responses to carry a payload with more 
meaning than "I acknowledge having received that request" is Evil. Since 
we can't reject a response, we can't deal with big responses and can't 
negotiate what they carry. Acknowledgement and response are different 
beasties -- one is transport, the other is application, and we need to 
understand the difference.

5) The three-message INVITE transaction model and its dependence on 
payload in the response is Evil.

6) The two-message non-INVITE transaction model and its interaction with 
retransmission and hop-by-hop cascade (See Sparks'  non-invite analysis) 
is Evil.

7) Building transport state and reliability into the application state 
and requiring a transport protocol extension for every new application 
semantic is Evil.

8) Using z9hG4bK on via fields rather than a negotiated mechanism (like 
maybe a version) is Evil.

9) Jon argues that not requiring SIPS to be end-to-end is Evil. I think 
the jury is still out on this one, but we're still deliberating.

10) Provisional responses, as currently constructed, whether reliable or 
non-relaible, are Evil. This may be redundant with the NIT discussion.

11)  I believe I'm coming to believe that "retargeting",  i.e. changing 
a request in a proxy such that the entity to which it is delivered  has 
a different assertable identity than the identity to which the request 
was originally addressed,  is Evil. Perhaps it could be mitigated by a 
assertion of transitivity: "I, the proxy identified herein, do assert 
that I have altered the target of this request according to local 
policy, and you can either deal with it or go away." Oh wait, that's the 
302 response . . . Perhaps this is redundant with "Forking is evil" as 
forking is just a special case of retargeting. Or perhaps forking and 
retargeting are both special cases of "exploders" and could both be 
dealt with using the consent framework . . .

Sometimes I wonder if  the use of UDP was fundamentally Evil.

If I've missed something blatantly Evil, please comment back, and I may 
add it to the list I hope to post someplace.

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 23 Nov 2004 15:54:26 -0500

I generally agree with Jon and Dave. I've snipped to something I want to 
comment on.

	Paul

David R Oran wrote:
> 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".

In the general case the two ends of the call are in different domains, 
and so there need to be two auth servers. The initial call setup (from 
Alice to Bob) presumably transits Alice's auth server so that it can be 
signed. Jon's requirement above would require *it* to record route. That 
might be a good thing, so that subsequent requests from Alice can also 
be signed. But that does nothing for requests from Bob to Alice.

There is no guarantee that Bob's auth server is in the path for incoming 
requests from Alict to Bob. Based on the needs of Identity-03 there is 
no need for it to be. If it happened to be, then the requirement that it 
record-route might be helpful in giving it the opportunity to sign 
future outbound requests in the dialog.

If it wasn't in the path initially, then Bob will have to add a Route 
header, in addition to what is received in Record-Route, to involve it 
when sending subsequent requests within the dialog.

It seems to me that depending on how the network components are 
constructed, either the auth server will be collocated with a component 
that is naturally on the path, or else each end will have to manipulate 
the Route headers to ensure it is. (It would naturally be on the path if 
  it was collocated with teh proxy managing the user's AOR and the user 
uses a GRUU managed by the same proxy for contacts.)

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 23 Nov 2004 16:34:31 -0500

Dean,

Rather that the "list of Evil SIP Ideas", I propose this be called the 
"axis of Evil SIP Ideas".

	Paul

---

From: David R Oran <[email-masked]>
Date: Tue, 23 Nov 2004 17:28:34 -0500

Boy do you guys ever have axis to grind!

On Nov 23, 2004, at 4:34 PM, Paul Kyzivat wrote:

>> pain that needs (or needed) fixing. Some of these things sounded cool 
>> at first, and I championed them.  Others I never did like. Some of 
>> these things I'm not allowed to suggest deprecating anymore -- we 
>> took a hum on forking a few meetings back. One of these days I'm 
>> going to get this list better organized and  post it someplace more 
>> persistent in the hope that it may assist in avoiding repeptition of 
>> mistakes. And someday, perhaps we can do something about some of 
>> these quirks.
>> 2) Abusing To and From to indicate branches is Evil. We should have 
>> left these as real endpoint identifiers.
>> 3) Forking is Evil.
>> meaning than "I acknowledge having received that request" is Evil. 
>> Since we can't reject a response, we can't deal with big responses 
>> and can't negotiate what they carry. Acknowledgement and response are 
>> different beasties -- one is transport, the other is application, and 
>> we need to understand the difference.
>> 6) The two-message non-INVITE transaction model and its interaction 
>> with retransmission and hop-by-hop cascade (See Sparks'  non-invite 
>> analysis) is Evil.
>> 7) Building transport state and reliability into the application 
>> state and requiring a transport protocol extension for every new 
>> application semantic is Evil.
>> 8) Using z9hG4bK on via fields rather than a negotiated mechanism 
>> (like maybe a version) is Evil.
>> 9) Jon argues that not requiring SIPS to be end-to-end is Evil. I 
>> think the jury is still out on this one, but we're still 
>> deliberating.
>> 10) Provisional responses, as currently constructed, whether reliable 
>> or non-relaible, are Evil. This may be redundant with the NIT 
>> discussion.
>> 11)  I believe I'm coming to believe that "retargeting",  i.e. 
>> changing a request in a proxy such that the entity to which it is 
>> delivered  has a different assertable identity than the identity to 
>> which the request was originally addressed,  is Evil. Perhaps it 
>> could be mitigated by a assertion of transitivity: "I, the proxy 
>> identified herein, do assert that I have altered the target of this 
>> request according to local policy, and you can either deal with it or 
>> go away." Oh wait, that's the 302 response . . . Perhaps this is 
>> redundant with "Forking is evil" as forking is just a special case of 
>> retargeting. Or perhaps forking and retargeting are both special 
>> cases of "exploders" and could both be dealt with using the consent 
>> framework . . .
>> If I've missed something blatantly Evil, please comment back, and I 
>> may add it to the list I hope to post someplace.
David R. Oran
Cisco Fellow
Cisco Systems
7 Ladyslipper Lane
Acton, MA 01720 USA
Tel: +1 978 264 2048
Email: [email-masked]

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 24 Nov 2004 03:02:30 -0500

Actually, Dean's list of evils is sufficiently large, and covers enough 
of sip itself, that I think he has more or less concluded that "sip is 
evil"? :)

-Jonathan R

Paul Kyzivat wrote:

>> these things I'm not allowed to suggest deprecating anymore -- we took 
>> a hum on forking a few meetings back. One of these days I'm going to 
>> get this list better organized and  post it someplace more persistent 
>> in the hope that it may assist in avoiding repeptition of mistakes. 
>> And someday, perhaps we can do something about some of these quirks.
>>
>> Since we can't reject a response, we can't deal with big responses and 
>> can't negotiate what they carry. Acknowledgement and response are 
>> think the jury is still out on this one, but we're still deliberating.
>>
>> or non-relaible, are Evil. This may be redundant with the NIT discussion.
>>
>> which the request was originally addressed,  is Evil. Perhaps it could 
>> be mitigated by a assertion of transitivity: "I, the proxy identified 
>> herein, do assert that I have altered the target of this request 
>> according to local policy, and you can either deal with it or go 
>> away." Oh wait, that's the 302 response . . . Perhaps this is 
>> retargeting. Or perhaps forking and retargeting are both special cases 
>> of "exploders" and could both be dealt with using the consent 
>> framework . . .
>>

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