Re: My take on where we are with Identity

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