On Nov 22, 2004, at 8:28 PM, Peterson, Jon wrote:
Thanks, this is a useful and cogent description/context for figuring out what the options are.
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 theThis 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.
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.
Unless the retarget is explicitly delegated...
In this environment, it is impossible to makeImpossible is a bit too strong, but the general case of retargeting does have this problem.
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 isQuestionable only if it is not extended to allow SAML or some other explicit means of delegation.
questionable, since it isn't clear what impersonation threat might be met by
providing identity here.
Really, the only possible motivation for usingFor 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.
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 valueIt 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.
(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 theFrom header field, it MAY just proxy the request normally.
This seems simple and keep the identity service out of authz policy.
Given all of this, let me make a concrete proposal for sip-identity-04 whichI 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".
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 isWhy? If the auth service can authenticate the From in the request, why should it refuse to do so?
different from the party to which the local UA sent the request.
We keep theModulo 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.
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?
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.
Attachment:
PGP.sig
Description: This is a digitally signed message part
_______________________________________________ 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