[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Security for RTP connections - some thoughts




> > Your authentication service can be run by yourself (RFC4474
> > allows this, if you own your own domain name) or -- more 
> > typically -- by whoever is performing your user authentication
> > (that is, whoever receives your REGISTER message).
> 
> Having an own domain is not a real solution for most (>95%) users.

Agreed.  I would say it's even above 95% that would be using 
someone else's domain.

> > If you don't trust the entity that handles your own REGISTER
> > message, or don't trust the entity of your remote peer that 
> > handles their REGISTER message and generated their RFC4474 
> > signature, that's fine -- you could ignore it.  You would
> > want to verify identity in some other way.  ZRTP has its
> > Short Authentication String and DTLS-SRTP has its SAS (section 
> > 8.6 of draft-fischl-sipping-media-dtls-02).
> 
> I (and propably many others as well) don't trust an operator or SIP
> service provider (the entity that receives the REGISTER) when it comes
> to confidentiality and integrity of media connections. 

DTLS-SRTP doesn't expect you to, and does not.  The confidentiality
(encryption) and integrity of the DTLS exchange, and of the SRTP, is
only between the two endpoints, not with whoever is running the
REGISTER.

You are, however, relying on that operator for identity of the 
endpoint, if you use RFC4474.  Which you're relying on anyway to 
route the call to the correct endpoint.  Much like you rely on 
ISPs to route 1.2.3.4 to the correct place, and you rely 
on telephone companies to route +1-408-123-4567 to the right 
place, and you rely on the postal system to route packages 
to the correct meat-space address.

> It is quite
> normal and well-founded not to trust an operator in this case (most
> security problems/attacks stem from inside an organisation).

If that is the level of security you want, you can ignore all of
the RFC4474 signatures.  DTLS-SRTP provides a mechanism to read 
authentication strings to each other, too, much like ZRTP.  See
http://tools.ietf.org/html/draft-fischl-sipping-media-dtls-02#section-8.5

DTLS-SRTP also encourages endpoints to cache each others 
certificates, as Alan pointed out earlier.  This allows one to
avoid re-validating authentication strings for subsequent calls.  See
http://tools.ietf.org/html/draft-fischl-sipping-media-dtls-02#section-8.5

With those two sections, you can completely ignore RFC4474 signatures
and do it all manually with humans.

> A DTLS-SRTP solution that relies on the operators' authentication
> services is sort of "snake oil". It gives most end users the feeling
> that they use secure media connections. Operators of the
> authentication service can easily break the security in a way that
> neither the A party nor the B party can recognize it.

If anyone is worried about that attack, they would need the ability
to display ZRTP (or DTLS-SRTP) authentication strings, read them
to each other.  Ideally, they'll want to store information from
that human-validated call for to avoid having to do that step
for a subsequent call.  For ZRTP, that information is the remote
party's ZID and the ZRTP hash information; for DTLS-SRTP it is
the remote party's SIP AOR and certificate fingerprint.

> If trust either does not exist or is very limited it all boils
> down to "SAS".
> 
> ZRTP mandates SAS, DTLS-SRTP does not. The mentioned draft says:
>    DTLS does not natively support this mode, however it would be
>    straightforward to add one as a TLS extension [RFC3546].
> 
> If only SAS gives true "trust" in the security then I don't see why to
> use DTLS-SRTP and its complex envrionment at all. ZRTP does the same
> job much better, with less complixity and without the necessity to
> introduce a new SIP service (authentication), use additional SIP codes
> and header fields, certificates,  etc.

-d

> Regards,
> Werner
> 
> > 
> > -d
> > 
> > 
> >> Thus I personally don't treat such a service as kryptograpically
> >> secure and don't really trust it to protect data used for
> >> key exchange.
> >>
> >> (Real CAs return back the certificate they signed and I can
> >> check if the content was untouched, the CA's signature is
> >> ok)
> >>
> >>
> >> Regards,
> >> Werner
> >>
> >> Francois Audet wrote:
> >>> I mean the do-it-in-the-media-stream, not signalling. 
> >>>
> >>>> -----Original Message-----
> >>>> From: owner-ietf-rtpsec@xxxxxxxxxxxx 
> >>>> [mailto:owner-ietf-rtpsec@xxxxxxxxxxxx] On Behalf Of 
> >> Werner Dittmann
> >>>> Sent: Monday, March 12, 2007 12:17
> >>>> To: Audet, Francois (SC100:3055)
> >>>> Cc: Dan Wing; EKR; ietf-rtpsec@xxxxxxxxxxxx
> >>>> Subject: Re: Security for RTP connections - some thoughts
> >>>>
> >>>>
> >>>> To which one of the many conclusions do you refer, Francois :-) ?
> >>>>
> >>>> If you mean: Keep it simple - then this was always my 
> >> conclusion :-)
> >>>> Regards,
> >>>> Werner
> >>>>
> >>>>
> >>>> Francois Audet wrote:
> >>>>> Basically, Werner seems to be reaching exactly the same 
> >> conclusion 
> >>>>> that group has.
> >>>>>
> >>>>> This is good. :^)
> >>>>>
> >>>>>> -----Original Message-----
> >>>>>> From: owner-ietf-rtpsec@xxxxxxxxxxxx 
> >>>>>> [mailto:owner-ietf-rtpsec@xxxxxxxxxxxx] On Behalf Of Dan Wing
> >>>>>> Sent: Sunday, March 11, 2007 11:24
> >>>>>> To: 'Werner Dittmann'
> >>>>>> Cc: 'EKR'; ietf-rtpsec@xxxxxxxxxxxx
> >>>>>> Subject: RE: Security for RTP connections - some thoughts
> >>>>>>
> >>>>>>
> >>>>>> Your message below seems to say that using the media 
> path is the 
> >>>>>> better place to perform key exchange to protect the media.  
> >>>>>> DTLS-SRTP, ZRTP, and MIKEYv2, (and EKT, which we aren't 
> >> currently 
> >>>>>> discussing) all perform the key exchange in the media 
> >> path.  Those 
> >>>>>> are the three protocols this RTPSEC group is 
> concentrating on to 
> >>>>>> solve the unicast point-to-point key exchange.
> >>>>>>
> >>>>>> -d
> >>>>>>  
> >>>>>>
> >