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

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

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 sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip