Good summary. Thanks. -d
> -----Original Message----- > From: [email protected] [mailto:[email protected]] 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 > > 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 > > > _______________________________________________ > 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 _______________________________________________ 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
