[jitsi-dev] SRTCP


#1

Hello

Some of you noticed that Asterisk shows messages like "ast_srtp_unprotect: SRTP unprotect: authentication failure" when an SDES secured call is made. This is due to unencrypted and unauthenticated RTCP packets and affects SDES as well as ZRTP. However, the transported media (audio/video) over RTP is still secure.

I'm planning to address this sometime in November and implement the SRTCP encryption. But someone with crypto know-how absolutely needs to review that; otherwise it will be nearly useless. Does someone have the time to do that? Werner?

Regards,
Ingo


#2

Ingo, all

I'm just looking into that topic and started to check how to implement
this. It's quite similar to SRTP, however some differences exist.

I'll keep you informed about the stuff.

Best regards,
Werner

···

Am 07.10.2011 15:15, schrieb Bauersachs Ingo:

Hello

Some of you noticed that Asterisk shows messages like "ast_srtp_unprotect: SRTP unprotect: authentication failure" when an SDES secured call is made. This is due to unencrypted and unauthenticated RTCP packets and affects SDES as well as ZRTP. However, the transported media (audio/video) over RTP is still secure.

I'm planning to address this sometime in November and implement the SRTCP encryption. But someone with crypto know-how absolutely needs to review that; otherwise it will be nearly useless. Does someone have the time to do that? Werner?

Regards,
Ingo


#3

Hey

Ok, cool, thanks!
Even though lots of the SRTP stuff can be reused, the CryptoContext is not really compatible.

Just FYI: I talked with Emil today about modifying RawPacket and moving all methods that only apply to RTP packet to a new class RtpPacket and introduce an RtcpPacket class as well. But nothing concrete yet.

Ingo

···

-----Original Message-----
From: Werner Dittmann [mailto:Werner.Dittmann@t-online.de]
Sent: Freitag, 7. Oktober 2011 17:32
To: dev@jitsi.java.net
Subject: [jitsi-dev] Re: SRTCP
Ingo, all

I'm just looking into that topic and started to check how to implement
this. It's quite similar to SRTP, however some differences exist.

I'll keep you informed about the stuff.

Best regards,
Werner

Am 07.10.2011 15:15, schrieb Bauersachs Ingo:

Hello

Some of you noticed that Asterisk shows messages like

"ast_srtp_unprotect: SRTP unprotect: authentication failure" when an SDES
secured call is made. This is due to unencrypted and unauthenticated RTCP
packets and affects SDES as well as ZRTP. However, the transported media
(audio/video) over RTP is still secure.

I'm planning to address this sometime in November and implement the

SRTCP encryption. But someone with crypto know-how absolutely needs to
review that; otherwise it will be nearly useless. Does someone have the
time to do that? Werner?

Regards,
Ingo


#4

Hi,

that's what I'm going to do:

- create a new CryptoContext class for RTCP. The differences are big
  enough to justify this. Also: never change a running code :slight_smile: .

- Having a new RTCP clas would be cool. Maybe we can structure the RTCP
  class as subclass to the existing RawPacket or have a packet base class
  and RawPacket and RTCP raw packet can inherit from it, or having an interfcae
  that bot classes implement. Need to check.

- Also I'll look into the stuff how to register the RTCP into the
  transformers (classes are available, but more or less "dummy"), also how
  to register/test the SRTCP transport with JMF (AFAIK that was never done
  and or tested).

- Nest is to populate the new SRTCP via ZRTP and SDES. IMHO that's the more
  easy part. ZRTP defines that the same key must be used for SRTP and SRTCP,
  thus this would be straight forward

- Testing: AFAIK Asterisk uses libsrtp (from David McGrew). Once upon a time
  I tested my implementation with a test application that uses this lib to
  check interoperability. I'll try to to this again with SRTCP, however I'm
  not quite sure how/if this works with JMF :slight_smile: . In addition, once we have it
  in Jtsi we can test it against your Asterisk stuff.

Ideas are welcome :slight_smile:

Best regards,
Werner

···

Am 07.10.2011 19:05, schrieb Bauersachs Ingo:

Hey

Ok, cool, thanks!
Even though lots of the SRTP stuff can be reused, the CryptoContext is not really compatible.

Just FYI: I talked with Emil today about modifying RawPacket and moving all methods that only apply to RTP packet to a new class RtpPacket and introduce an RtcpPacket class as well. But nothing concrete yet.

Ingo

-----Original Message-----
From: Werner Dittmann [mailto:Werner.Dittmann@t-online.de]
Sent: Freitag, 7. Oktober 2011 17:32
To: dev@jitsi.java.net
Subject: [jitsi-dev] Re: SRTCP
Ingo, all

I'm just looking into that topic and started to check how to implement
this. It's quite similar to SRTP, however some differences exist.

I'll keep you informed about the stuff.

Best regards,
Werner

Am 07.10.2011 15:15, schrieb Bauersachs Ingo:

Hello

Some of you noticed that Asterisk shows messages like

"ast_srtp_unprotect: SRTP unprotect: authentication failure" when an SDES
secured call is made. This is due to unencrypted and unauthenticated RTCP
packets and affects SDES as well as ZRTP. However, the transported media
(audio/video) over RTP is still secure.

I'm planning to address this sometime in November and implement the

SRTCP encryption. But someone with crypto know-how absolutely needs to
review that; otherwise it will be nearly useless. Does someone have the
time to do that? Werner?

Regards,
Ingo


#5

Hey

that's what I'm going to do:

- create a new CryptoContext class for RTCP. The differences are big
  enough to justify this. Also: never change a running code :slight_smile: .

I guess the ROC is not needed for SRTCP? Otherwise it might make sense to create an abstract CryptoContext and put the RTP/RTCP specific parts into child classes. I'd avoid having duplicate processPacketAESCM etc. if possible.

- Having a new RTCP clas would be cool. Maybe we can structure the RTCP
  class as subclass to the existing RawPacket or have a packet base
  class and RawPacket and RTCP raw packet can inherit from it, or having
  an interfcae that bot classes implement. Need to check.

That was my idea as well (RawPacket as an abstract base class, RtpPacket extends RawPacket; RtcpPacket extends RawPacket).

- Also I'll look into the stuff how to register the RTCP into the
  transformers (classes are available, but more or less "dummy"), also how
  to register/test the SRTCP transport with JMF (AFAIK that was never done
  and or tested).

No idea on JMF as well, but there are RTCP packets flowing through the TransformEngineChain, reaching the dummy SRTCPTransformer. The more difficult part I think is to populate the avg_rtcp_size and packet_size variables according to http://tools.ietf.org/html/rfc3711#section-3.4 (near the end of the section).

- Nest is to populate the new SRTCP via ZRTP and SDES. IMHO that's the
more
  easy part. ZRTP defines that the same key must be used for SRTP and
  SRTCP, thus this would be straight forward

See above, that should indeed be no problem.

- Testing: AFAIK Asterisk uses libsrtp (from David McGrew). Once upon a
time
  I tested my implementation with a test application that uses this lib
  to check interoperability. I'll try to to this again with SRTCP,
  however I'm not quite sure how/if this works with JMF :slight_smile: . In
  addition, once we have it in Jtsi we can test it against your Asterisk
  stuff.

Yes, Asterisk uses libsrtp. I needed to install libsrtp from CVS though; the latest available lib from the Ubuntu's repository (1.4.4) causes Asterisk to crash after two RTCP packages.
Maybe Secion 1.4 of http://srtp.sourceforge.net/libsrtp.pdf can help with testing.

Ideas are welcome :slight_smile:

RFC3711 contains test vectors in appendix B. Would be cool if we had unit tests that contain those. The SRTP stuff doesn't rely on other OSGi services, so there should be no need for lots of OSGi/Smack/OrWhateverItsCalled test handling.

If you need any help, just let me know what I can do :slight_smile:

Regards,
Ingo