Subject: [Sip] My take on where we are with Identity

From: "Elwell, John" <[email-masked]>
Date: Fri, 03 Apr 2009 15:20:36 +0100

>From discussions during and since IETF 74, I see that the problem space
might be divided up as follows.

Problem 1. Securing a call and its media. I need to know where a call
and its secure media have come from or where they have gone to, i.e.,
the party I am talking to, the party I am exchange session-based IM or
files with. I need to know the domain of that other party, and perhaps
also the identity of the party itself. For some cases, I might just need
to know that the other party is an agent of a particular enterprise,
whereas in other cases I need to know the particular user. I want the
assertion of identity to come from an entity I trust to be able to make
that assertion, which in many situations rules out intermediate domains
that happen to be on the path of the call.

RFC 4474, in conjunction with DTLS-SRTP for real-time media and
equivalents for other media, solves that problem, except where there are
intermediate domains that modify signed parts of the SIP request, in
particular the SDP port/address. We have NAT traversal, media steering,
topology hiding, etc. as reasons the SDP gets modified. We have a
divergence of opinion on which are these happen in practice, which of
these are legitimate and whether we can somehow induce the proponents of
these practices to clean up their act. I would say a majority of people
accept that such changes do take place in practice, and some of those
people accept that, whether or not these changes are legitimate, we will
not be able to persuade people to stop. I think people accept that, if
the media is secured (e.g., by SRTP), the signing of the IP address and
port in SDP adds no security value.

Proposals from Dan Wing and Kai Fischer both seem to solve this
particular problem.

2. As above, but with unsecured media. We have a divergence of opinion
whether there is value in RFC 4474 signing the IP address and port for
media, when the media itself is not secured. I subscribe to the view
that it adds very little value, for reasons Hadriel has stated several
times. Therefore I don't think the practice of intermediaries changing
the IP address and port is a problem worth solving.

3. Delivery of SIP messages with content not related to calls (e.g.,
MESSAGE, SUBSCRIBE, NOTIFY and PUBLISH requests). I just need to be sure
where the content comes from. RFC 4474 provides a solution to this,
although again it won't work through intermediaries that change signed
parts of the request. However, such requests (unless they happen to be
call-related requests that also deliver other content) do not contain
SDP and are often not passed through intermediate domains in the same
way that call-related requests (such as INVITE) are, so RFC 4474 might
be a sufficient solution as it stands.

Therefore do we need two separate solutions: one for securing signalling
to the extent necessary to authenticate the certs used for media
security (with a reasonable level of replay protection); and RFC 4474 as
it stands for protecting a substantial part of a request? The two
solutions could be used together where appropriate.

John

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 3 Apr 2009 10:26:13 -0700

Good summary.  Thanks.

-d

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Elwell, John
> Sent: Friday, April 03, 2009 7:21 AM
> To: SIP List
> Subject: [Sip] My take on where we are with Identity
> 
> _______________________________________________
> Sip mailing list  https://www.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