Dean,
Thanks for taking the lead here on trying to get a handle on what
needs to be done.
Reading your message, what strikes me is that these issues are bigger
than just RFC 4474 - although in some cases changes to RFC 4474 may be
part of the solution. So, I'd like to see the WG focus on is
getting a crisp definition of the problem and how to solve it,
rather than asking what changes to 4474 are required just yet.
On Apr 12, 2008, at 1:26 AM, Dean Willis wrote:
We've had a lot of recent discussions about issues relating to the
use of RFC 4474, and I've had a bunch of side conversations with
people this week on the same topic.
Here's where I think we're at:
RFC 4474 is pretty good. Since it was published, we've learned more
about the problem space. In the largest part, we've learned that the
authors of RFC 4474 and the working group did an excellent job of
analyzing the fundamental requirements for attaching forward
authentication (as opposed to challenge-response) to SIP. We've also
learned that the real world has some nastiness that isn't quite
covered by RFC 4474, but it appears that very small adjustments to
the specification could cover most or all of the cases we've
discovered.
I'd therefore like to propose that the working group consider the
task of narrowly revising RFC 4474 to account for four specific
points:
1) Revising the "what gets signed" aspect to allow modification of
the SDP by the SBCs we seem to keep encountering. While it is
important to verify the SDP, we now have the DTLS-SRTP framework to
vouch for the authenticity of the media channel. I suggest that
there not be any optionality to "what gets signed", but that the
fixed set of items be revised so as to allow SBC operations, and to
note the dependency on DTLS-SRTP for media authentication.
Based on the discussion I've seen so far, the primary use case for
this modification is to allow the SBC to do media steering so it can
steer the RTP through a path that provides better QoS. As you say,
this could be achieved by modifying the SDP and changing RFC 4474 to
allow that, but there are probably some other approaches we should be
considering as well, including ones that may need to be done outside
of SIP. If there's consensus that this is the problem
that needs solving, then I'll get with the SIP, SIPPING, and MMUSIC
chairs and figure out a process for how to evaluate the various
options and get this moving forward. If this isn't
the primary use case, then I think we probably need some more
discussion to get a clearer idea of what the problem is.
2) RFC 4474 did not consider the requirements of calls transiting
gateways and the issues related to expressing identities that
originate outside the Internet, specifically phone numbers delivered
via caller ID. While RFC 4474 can say nothing authoritative about
the phone number, it seems that it could quite reasonably say
something authoritative about the gateway. We've seen several
proposals for doing this using conventions for the expression of
"phone" identities in the From header field. I believe that a
revised RFC 4474 is the place to document such a convention and any
needed extension parameters.
It seems to me that there are actually two issues here:
- To have a way for the gateway to say: 'this URI corresponds to
a phone number'
- To have a way for receiver of the above assertion to determine
whether to trust it.
These are actually separable. The first function may be useful as an
indicator even if we don't have a technical mechanism for enforcing
it. In fact, based on the discussion in Philadelphia, there seemed to
be some feeling that 'user=phone' already performed this function.
So, I would encourage the WG to figure out whether that's so or
not and if not, and if it is not, and we decide we need a way to do
this,
clearly the some WG could go construct something that did indicate this
(a "userpart=e164" sip uri tag for example).
The second function sees substantially more complicate, and while it
might involve modifying 4474, it might be something completely
external to RFC 4474 (e.g., enum, Dan's return routability draft).
This seems like a much more complicated problem than a simple indicator,
and I'd like to see the WG study the solution space some before
trying to close on a single approach
3) There seems to be a valid model for what I call "stacked"
Identity header fields that express transitive assertions. Consider
authentication domains A, B, and C, where B is a transit domain
between A and C. B would be likely to trust assertions made by A,
and might not know whether C is or is not equipped to evaluate
assertions made by A. However,, it might be reasonable to expect
that C would be able to validate assertions made by B. B might
therefore choose to validate the Identity header inserted by A, and
then (assuming the header authenticates) add another Identity header
using its own credentials, saying in effect "B validated A's
identity header and found it good". If C can validate A's Identity
header directly, it would do so. If not, it could choose to rely on
B's assertion.
This transitive trust seems to be something that is used in real
deployments and it would be good to have some discussions around it.
That said, while there's been a fair bit of mailing list discussion,
I'm not sure the requirements are. For example if C is willing go
trust B, but B wants to lie, can B just remove A assertion forcing C
to rely on B's assertion? How much information does C need to
include about its evaluation policies? I would be looking for
more consensus and understanding about what the problem
before charting some work on a solution.
4) There are cases, including authentication services in the UAS and
authentication services in a proxy having an "outbound" relationship
(pre-authenticated persistent TLS) with the UAS where, in the
absence of retargeting, an Identity header field could reasonably be
included in a response as an alternative to using the more
cumbersome connected-identity approach with UPDATE. I expect this
to be very useful in P2PSIP, but it has broader utility. So I would
like to see RFC 4474 extended to allow its use in responses where
it would work.
I like this idea. Once outbound is done, as you point out, it opens up
some
ways for a proxy to authenticate both requests and responses coming
from a UA which in turn might allow Identity like assertions in
response. I be keen on drafts that extended 4474 and outbound
to do this, provided that outbound does not get blocked on these
changes.
--
Dean
So, while all four of these points seem to be coupled with areas where
we need discussion and work, I think it's a bit premature to decide
that what's needed is an update to RFC 4474. Rather, I'd like to see
the WG (and other WGs as required) figure out what the best technical
approach is for each of these points, and if that requires changing
4474 or 3261 or anything else, we can do that.
Cullen <with my AD hat on>
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
