Re: francois' comments and why RFC4474 not used in the field

 

> -----Original Message-----
> From: Dan Wing [mailto:[email protected]] 
> Sent: Friday, April 03, 2009 14:10
> To: Audet, Francois (SC100:3055); 'Dean Willis'; 'Jiri Kuthan'
> Cc: 'SIP List'; 'Uzelac,Adam'
> Subject: RE: [Sip] francois' comments and why RFC4474 not 
> used in the field
> 
> The public key challange/response, described in 
> draft-wing-sip-identity-media-02, provides better identity 
> assurance than signing IP address and UDP port (as done by 
> RFC4474).  Obviously the media is still un-encrypted, though, 
> and encrypted media is better than un-encrypted media.

I don't understand this. If there is a media transcoder,
then what does this identity assurance mean??? The media
is not protected. Am I missing something?

> > If we need transcoding, then we might want instead to have 
> a security 
> > mechanism with the transcoder instead.
> >
> > For example, we could use DTLS-SRTP where Alice is using 
> the 4474-like 
> > mechanism, but the transcoder is using it's own cert (instead of a 
> > self-signed one). That cert's credentials would already be 
> provisioned 
> > in Alice's device. That would seem like a simple way to do this.
> 
> Ignoring SRTP for a moment, the complexities involved there 
> are asounding.  For example call forwarding and call 
> transfers might need to invoke, or remove, a translator, in a 
> far-removed service provider or enterprise (e.g., forwarding 
> your work calls to your house).

Well, no, not at all.

The model there would be a model where you would HAVE to anchor the
media at the service provider (probably the first SBC). The encryption
would be between Alice and that.

PS: Don't get me wrong, I'm not saying I like this. I a firm non-believer
in all this transcoding stuff. I'd rather have the end-to-end DTLS-SRTP instead.
_______________________________________________
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