[jitsi-dev] SRTCP integration


#1

Emil, Ingo, dear security people,

I'm ready to check-in some new stuff:

- support of SRTCP, partly inter-op tested with libsrtp results,
  may need full test with Asterisk and others that need SRTCP

- support of PBX feature as defined by RFC 6189, chapter 7.3
  This feature enables Jitsi to act as an "not enrolled" client to
  a trusted MitM (PBX). No changes in GUI or other parts of Jitsi
  are necessary.

  To enable the enrollement procdure in Jitsi we need an enhancement
  of the GUI: a notification window where the user can accept or
  deny an enrollement to a trusted MitM (PBX).
  One part of the GUI is already available in the expert security
  configuration. Only if a user enables the trusted MitM ZRTP4J accepts
  the enrollement flags and starts the enrollment procedure.

If I don't get any "stop" signal I'll check-in the stuff this evening :slight_smile: .

Best regards,
Werner


#2

Hey Werner,

На 15.10.11 13:48, Werner Dittmann написа:

Emil, Ingo, dear security people,

I'm ready to check-in some new stuff:

- support of SRTCP, partly inter-op tested with libsrtp results,
  may need full test with Asterisk and others that need SRTCP

- support of PBX feature as defined by RFC 6189, chapter 7.3
  This feature enables Jitsi to act as an "not enrolled" client to
  a trusted MitM (PBX). No changes in GUI or other parts of Jitsi
  are necessary.

  To enable the enrollement procdure in Jitsi we need an enhancement
  of the GUI: a notification window where the user can accept or
  deny an enrollement to a trusted MitM (PBX).
  One part of the GUI is already available in the expert security
  configuration. Only if a user enables the trusted MitM ZRTP4J accepts
  the enrollement flags and starts the enrollment procedure.

If I don't get any "stop" signal I'll check-in the stuff this evening :slight_smile: .

Sounds great! Thanks a lot for taking care of that!

Two quick questions.

1. Have you tested interop with current Jitsi versions? Especially the
latest stable? Do you expect any trouble?

2. Are you planning on checking in the change in RawPacket? I haven't
had the chance to look at it yet and I would really like to before you
do. So if that's a necessary part of your commit, could you please hold
a bit?

Thanks,
Emil


#3

Hey

Thanks for the effort!

- support of SRTCP, partly inter-op tested with libsrtp results,
  may need full test with Asterisk and others that need SRTCP

If you send me the patchset beforehand, I can check it with a simple Asterisk setup.

- support of PBX feature as defined by RFC 6189, chapter 7.3
  This feature enables Jitsi to act as an "not enrolled" client to
  a trusted MitM (PBX). No changes in GUI or other parts of Jitsi
  are necessary.

  To enable the enrollement procdure in Jitsi we need an enhancement
  of the GUI: a notification window where the user can accept or
  deny an enrollement to a trusted MitM (PBX).
  One part of the GUI is already available in the expert security
  configuration. Only if a user enables the trusted MitM ZRTP4J accepts
  the enrollement flags and starts the enrollment procedure.

Have you already created that new notification UI? If not, what modifications are necessary to bubble the event from the ZrtpControl to the UI?
I guess changes to the lcrypto-stuff were not necessary?

Regards,
Ingo


#4

Hi,

I can do the fix for RawPacket, no problem :slight_smile: .

Hey Werner,

На 15.10.11 13:48, Werner Dittmann написа:

Emil, Ingo, dear security people,

I'm ready to check-in some new stuff:

- support of SRTCP, partly inter-op tested with libsrtp results,
  may need full test with Asterisk and others that need SRTCP

- support of PBX feature as defined by RFC 6189, chapter 7.3
  This feature enables Jitsi to act as an "not enrolled" client to
  a trusted MitM (PBX). No changes in GUI or other parts of Jitsi
  are necessary.

  To enable the enrollement procdure in Jitsi we need an enhancement
  of the GUI: a notification window where the user can accept or
  deny an enrollement to a trusted MitM (PBX).
  One part of the GUI is already available in the expert security
  configuration. Only if a user enables the trusted MitM ZRTP4J accepts
  the enrollement flags and starts the enrollment procedure.

If I don't get any "stop" signal I'll check-in the stuff this evening :slight_smile: .

Sounds great! Thanks a lot for taking care of that!

Two quick questions.

1. Have you tested interop with current Jitsi versions? Especially the
latest stable? Do you expect any trouble?

Tested with current Jitsi and I don't expect trouble :wink: . The changes do
not modify the normal ZRTP handling, only in case a Jisti user calls another
peer that is connected to a PBX and that PBX supports this special trusted MitM
feature. Not many PBXes that support this feature out in the wild, if any.

2. Are you planning on checking in the change in RawPacket? I haven't
had the chance to look at it yet and I would really like to before you
do. So if that's a necessary part of your commit, could you please hold
a bit?

I can do the fix for RawPacket, no problem :slight_smile: .

Best regards,
Werner

···

Am 15.10.2011 14:30, schrieb Emil Ivov:

Thanks,
Emil


#5

Hey

Thanks for the effort!

- support of SRTCP, partly inter-op tested with libsrtp results,
  may need full test with Asterisk and others that need SRTCP

If you send me the patchset beforehand, I can check it with a simple Asterisk setup.

Can you deal with GIT patches?

- support of PBX feature as defined by RFC 6189, chapter 7.3
  This feature enables Jitsi to act as an "not enrolled" client to
  a trusted MitM (PBX). No changes in GUI or other parts of Jitsi
  are necessary.

  To enable the enrollement procdure in Jitsi we need an enhancement
  of the GUI: a notification window where the user can accept or
  deny an enrollement to a trusted MitM (PBX).
  One part of the GUI is already available in the expert security
  configuration. Only if a user enables the trusted MitM ZRTP4J accepts
  the enrollement flags and starts the enrollment procedure.

Have you already created that new notification UI? If not, what modifications are necessary to bubble the event from the ZrtpControl to the UI?
I guess changes to the lcrypto-stuff were not necessary?

No, I haven't done anything for the notification UI.
The actions are the same as usual: ZRTP performs a callback in case it detects
an enrollment request. The GUI shall then display, asynchronously in an other thread,
the notification and ask the user. During the display of the notification the session perists
and the user may hear some announcements from the PBX enrollement service. If the
user accepts or denies the enrollment the notification GUI send the appropriate info
to ZRTP, very similar to the "verify SAS" handling. If the user accepts the ZRTP
stores all necessary information in the ZRTP ZID file.

lcrypto was not touched, all necessary algorithms are already on board.

Best regards,
Werner

···

Am 15.10.2011 14:35, schrieb Bauersachs Ingo:

Regards,
Ingo


#6

Hi Emil,

just to make sure with regard to SRTCP:
  the current stable Jitsi does not support SRTCP.

The new SRTCP feature switches from RTCP to SRTCP at the same time as
it switches from RTP to SRTP. If a stable Jitsi relase client communicates
with a current "unstable" release it will thus receive SRTCP where it
expects RTCP packets, and vice versa.

Usually this is not a big problem because, AFAIK, Jitsi does not deal with
RTCP packets and closes the (S)RTP sessions based on signaling protocols
(SIP, XMPP) and not the the RTCP BYE packet.

I have seen an option in SIP/SDP to switch off SRTCP and use RTCP instead
even if the media path uses SRTP (need to check where I saw this).

It is obviously possible to build-in an additional ZRTP configuration
parameter to _not enable_ SRTCP even if we switch to SRTP. From ZRTP point
of view that would be not so complicated, however it needs some more analysis
when to set such a configuration parameter, which part sets it, etc.

Best regards,
Werner

···

Am 15.10.2011 16:32, schrieb Werner Dittmann:

Hi,

I can do the fix for RawPacket, no problem :slight_smile: .

Am 15.10.2011 14:30, schrieb Emil Ivov:

Hey Werner,

На 15.10.11 13:48, Werner Dittmann написа:

Emil, Ingo, dear security people,

I'm ready to check-in some new stuff:

- support of SRTCP, partly inter-op tested with libsrtp results,
  may need full test with Asterisk and others that need SRTCP

- support of PBX feature as defined by RFC 6189, chapter 7.3
  This feature enables Jitsi to act as an "not enrolled" client to
  a trusted MitM (PBX). No changes in GUI or other parts of Jitsi
  are necessary.

  To enable the enrollement procdure in Jitsi we need an enhancement
  of the GUI: a notification window where the user can accept or
  deny an enrollement to a trusted MitM (PBX).
  One part of the GUI is already available in the expert security
  configuration. Only if a user enables the trusted MitM ZRTP4J accepts
  the enrollement flags and starts the enrollment procedure.

If I don't get any "stop" signal I'll check-in the stuff this evening :slight_smile: .

Sounds great! Thanks a lot for taking care of that!

Two quick questions.

1. Have you tested interop with current Jitsi versions? Especially the
latest stable? Do you expect any trouble?

Tested with current Jitsi and I don't expect trouble :wink: . The changes do
not modify the normal ZRTP handling, only in case a Jisti user calls another
peer that is connected to a PBX and that PBX supports this special trusted MitM
feature. Not many PBXes that support this feature out in the wild, if any.

2. Are you planning on checking in the change in RawPacket? I haven't
had the chance to look at it yet and I would really like to before you
do. So if that's a necessary part of your commit, could you please hold
a bit?

I can do the fix for RawPacket, no problem :slight_smile: .

Best regards,
Werner

Thanks,
Emil


#7

Can you deal with GIT patches?

Yepp.

[...] The actions are the
same as usual: ZRTP performs a callback in case it detects an enrollment
request. The GUI shall then display, asynchronously in an other thread,
the notification and ask the user. During the display of the
notification the session perists and the user may hear some
announcements from the PBX enrollement service. If the user accepts or
denies the enrollment the notification GUI send the appropriate info to
ZRTP, very similar to the "verify SAS" handling. If the user accepts the
ZRTP stores all necessary information in the ZRTP ZID file.

It might be reasonable or even necessary to change the SrtpListener interface for that. Instead of providing three methods (on, off, text-message) we could modify it to provide one generic callback (securityMessageReceived(SecurityEvent e)). The event object would contain the controller, a field that indicates the type of the event object (on, off, protocol-specific). The security controllers could then send subclassed SecurityEvent objects.
This way the ZrtpSecurityPanel in the UI could handle the protocol-specific event to bring up a second dialog - or show it inline instead of the usual clickable padlock.

WDYT?

Ingo


#8

The new SRTCP feature switches from RTCP to SRTCP at the same time as
it switches from RTP to SRTP. If a stable Jitsi relase client communicates
with a current "unstable" release it will thus receive SRTCP where it
expects RTCP packets, and vice versa.

Receiving plain packets when we expect SRTCP would be possible, but insecure.

I have seen an option in SIP/SDP to switch off SRTCP and use RTCP instead
even if the media path uses SRTP (need to check where I saw this).

That would be preferable over simply sending RTCP.

It is obviously possible to build-in an additional ZRTP configuration
parameter to _not enable_ SRTCP even if we switch to SRTP. From ZRTP
point of view that would be not so complicated, however it needs some
more analysis when to set such a configuration parameter, which part
sets it, etc.

If necessary at all, I'd prefer a common setting that applies to whatever key-exchange is in effect. For SIP, this would easily fit in the (new) Security tab of the account wizard. IMHO the default should be to enable SRTCP.

Ingo


#9

I haven't looked at the GUI and security event stuff in detail,
thus I have no real oppinion here - however, it should work :slight_smile: .

Important: in case of an enrollement callback the GUI should
just start the notification info display and the return to the
ZRTP - similar to all other GUI related callbacks. This is important
to avoid timeouts at the protocol level.

The enrollment procedure starts after ZRTP switched to secure mode,
thus announcement from a PBX is already secured. A trusted PBX usually
performs one enrollment per client only, thus it is a "one shot" action
and the user must dial a specific enrollment service at the PBX.

Best regards,
Werner

···

Am 15.10.2011 17:15, schrieb Emil Ivov:

Fine by me either way.

Emil

--sent from my mobile

On 15 oct. 2011, at 17:05, Bauersachs Ingo <ingo.bauersachs@fhnw.ch> wrote:

Can you deal with GIT patches?

Yepp.

[...] The actions are the
same as usual: ZRTP performs a callback in case it detects an enrollment
request. The GUI shall then display, asynchronously in an other thread,
the notification and ask the user. During the display of the
notification the session perists and the user may hear some
announcements from the PBX enrollement service. If the user accepts or
denies the enrollment the notification GUI send the appropriate info to
ZRTP, very similar to the "verify SAS" handling. If the user accepts the
ZRTP stores all necessary information in the ZRTP ZID file.

It might be reasonable or even necessary to change the SrtpListener interface for that. Instead of providing three methods (on, off, text-message) we could modify it to provide one generic callback (securityMessageReceived(SecurityEvent e)). The event object would contain the controller, a field that indicates the type of the event object (on, off, protocol-specific). The security controllers could then send subclassed SecurityEvent objects.
This way the ZrtpSecurityPanel in the UI could handle the protocol-specific event to bring up a second dialog - or show it inline instead of the usual clickable padlock.

WDYT?

Ingo


#10

Hey Werner,

Hi Emil,

...

Usually this is not a big problem because, AFAIK, Jitsi does not deal with
RTCP packets and closes the (S)RTP sessions based on signaling protocols
(SIP, XMPP) and not the the RTCP BYE packet.

Well actually it does. We do take byes into account (e.g. this is what causes removal of the video component from the GUI) and we may also request video key frames through RTCP or respond to such requests.

Never checked the video stuff so far - good to know. That means that an
"old" Jitsi and a "new" one with SRTCP support and security enabled would not work
together with video because they are unable to detect RTCP BYE packets.

We also have auto-adaptive behaviour planned for the future but that's not currently in Jitsi so it's not related.

I have seen an option in SIP/SDP to switch off SRTCP and use RTCP instead
even if the media path uses SRTP (need to check where I saw this).

This could be helpful but only if lack of that option indicates use of RTCP rather than SRTCP.

IIRC the option must be set to disable use of SRTCP - thus it wouldn't help IMHO .

It is obviously possible to build-in an additional ZRTP configuration
parameter to _not enable_ SRTCP even if we switch to SRTP. From ZRTP point
of view that would be not so complicated, however it needs some more analysis
when to set such a configuration parameter, which part sets it, etc.

Don't bother with this. Ideally we'd strive for a seamless transition. Relying on a non-automatic option for this would only postpone problems.

Can you think of an easy way to only enable SRTCP in cases where the remote party also has it?

Not really. That would be sort of a heuristic approach. Approaches could be:

1)
Analyse the packet to check if it makes "sense", for example scanning the
compound parts. At Jitsi's receiving end try to verfiy the length field, check
if the compound parts contain valid PT codes in the headers, check the overall
computed length (sum of all length fields of the cpmpund parts) matches the
received length, etc. This however would require the we introduce "length" checks
to determine if a length value "makes sense".

2)
If we receive a packet on the RTCP port try to verify/decrypt it (replay check, authentication)
and if this fails treat it as RTCP packet and also set a internal configuration
flag to disable the SRTCP when sending RTCP.

IMHO both approaches could be a security problem: some bad guy could try to feed in normal
RTCP packets and try to force to switch off SRTCP this way. RTCP traffic is _much_ lower than RTP
and thus such a traffic data based detection (or false detection) is not really an option.

Werner

--sent from my PC :wink:

···

Am 15.10.2011 17:31, schrieb Emil Ivov:

On 15 oct. 2011, at 17:05, Werner Dittmann <Werner.Dittmann@t-online.de> wrote:

Emil

--sent from my mobile


#11

Well actually it does. We do take byes into account (e.g. this is what
causes removal of the video component from the GUI) and we may also
request video key frames through RTCP or respond to such requests.

Never checked the video stuff so far - good to know. That means that an
"old" Jitsi and a "new" one with SRTCP support and security enabled would
not work
together with video because they are unable to detect RTCP BYE packets.

Emil, is this for XMPP only? AFAIK SIP sends an update offer to enable/disable video? What happens with two clients whose RTCP streams aren't able to "talk" to each other at all?

Can you think of an easy way to only enable SRTCP in cases where the

remote party also has it?

Not really. [...]
IMHO both approaches could be a security problem: some bad guy could try
to feed in normal
RTCP packets and try to force to switch off SRTCP this way. RTCP traffic
is _much_ lower than RTP
and thus such a traffic data based detection (or false detection) is not
really an option.

Both approaches ARE a security problem, as is the current situation (well not from a privacy point of view, but security is not only privacy but attack resiliency as well).

While I can't quote an RFC, I think it was/is an error to ever send RTCP packets when SRTP is in use. At least SRTCP mandates the use of authentication - because of the sensitive BYE packets.

Ingo

--sent from my Notebook :wink:

···

Werner

--sent from my PC :wink:

Emil

--sent from my mobile


#12

While I can't quote an RFC, I think it was/is an error to ever send RTCP
packets when SRTP is in use. At least SRTCP mandates the use of
authentication - because of the sensitive BYE packets.

I peeked into libjingle: If their SRTP "filter" is active, packets are expected to be either SRTP or SRTCP. Any RTCP packets would be discarded.

Ingo


#13

It's RTP so it's both XMPP and SIP. Both XMPP and SIP can disable video
through signalling but the thing is that an RTP stream could also be ended
independantly of the signaling session.

We rely on those BYEs to fire the events that cause the video component to
be removed.

So if a video session is terminated through signaling but a BYE is never received, the video component stays alive?

What happens with two clients whose RTCP streams aren't able to "talk"
to each other at all?

I suppose it would worsen user experience to some extent. It wouldn't
completely break video tho.

Both approaches ARE a security problem, as is the current situation
(well not from a privacy point of view, but security is not only privacy
but attack resiliency as well).

While I can't quote an RFC, I think it was/is an error to ever send RTCP
packets when SRTP is in use. At least SRTCP mandates the use of
authentication - because of the sensitive BYE packets.

This doesn't mean we shouldn't look for ways to smoothen user transition
if we can.

Of course not :slight_smile:

Depending on your answer to my question above: If the video component is also removed through signaling it's probably not too much of an issue. If it is not removed, then we should fix that - a BYE can get lost anyway.

SRTCP has a mode where the packet content is only authenticated, not encrypted. We could set that option in the hope that older clients ignore the SRTCP appendix of each packet. We would of course loose the confidentiality, it should therefore at least be possible to enable it again (and by default enabled after some period of time).

At this point we could probably commit this to unstable and try to better
evaluate how both versions work together.

Sure.

Ingo


#14

> It's RTP so it's both XMPP and SIP. Both XMPP and SIP can disable video
> through signalling but the thing is that an RTP stream could also be

ended

> independantly of the signaling session.
>
> We rely on those BYEs to fire the events that cause the video component

to

> be removed.

So if a video session is terminated through signaling but a BYE is never

received, the video component stays alive?

If a session is entirely terminated, everything is destroyed. If it's only
downgraded fom AV to A, then yes, the video component would remain there
until a new video stream appears or the call goes down.

This is what happens with asterisk's av echo for example ... and it's
probably not such a big deal.

>> What happens with two clients whose RTCP streams aren't able to "talk"
>> to each other at all?
>
> I suppose it would worsen user experience to some extent. It wouldn't
> completely break video tho.

>> Both approaches ARE a security problem, as is the current situation
>> (well not from a privacy point of view, but security is not only

privacy

>> but attack resiliency as well).
>>
>> While I can't quote an RFC, I think it was/is an error to ever send

RTCP

>> packets when SRTP is in use. At least SRTCP mandates the use of
>> authentication - because of the sensitive BYE packets.
>
> This doesn't mean we shouldn't look for ways to smoothen user transition
> if we can.

Of course not :slight_smile:

Depending on your answer to my question above:

If the video component is also removed through signaling it's probably not
too much of an issue. If it is not removed, then we should fix that - a BYE
can get lost anyway.

We could. I remember we actually had that on our todo list but then didn't
get around to it. Not sure if it turned out to be tricky or if we simply got
drawn away by other issues.

Also, fixing bye-s would still leave keyframe requests unattended. I dont
think theres an easy way around that which is why I think we should commit
and see exactly how annoying these problems are.

Emil

-- sent from my mobile

SRTCP has a mode where the packet content is only authenticated, not

encrypted. We could set that option in the hope that older clients ignore
the SRTCP appendix of each packet. We would of course loose the
confidentiality, it should therefore at least be possible to enable it again
(and by default enabled after some period of time).

> At this point we could probably commit this to unstable and try to

better

···

On Oct 15, 2011 7:44 PM, "Bauersachs Ingo" <ingo.bauersachs@fhnw.ch> wrote:

> evaluate how both versions work together.

Sure.

Ingo


#15

Ok so far. Now that we are all aware about this stuff I'm going to
commit it, including the small fix in RawPacket :slight_smile: .

...

SRTCP has a mode where the packet content is only authenticated, not

encrypted. We could set that option in the hope that older clients ignore
the SRTCP appendix of each packet. We would of course loose the
confidentiality, it should therefore at least be possible to enable it again
(and by default enabled after some period of time).

Yes, may work. However I haven't build in such a function yet, albeit it could
be done with not too much effort.

As usual we need to check:
- which part of the code during session setup sets or resets this specific mode
  for SRTP/SRTCP and for ZRTP because ZRTP controls the setup of SRTP/SRTCP.

- in any case we need the full key material _and_ the encryption algorithms and
  have to initialize SRTP/SRTCP contexts and only after this initialization the
  client can set the SrtpPolicy to "NULL_ENCRYPTION". This full initialization
  is necessary because of the key derivation functions. To perform authentication
  SRTP/SRTCP both require an authentication key.

At this point we could probably commit this to unstable and try to

better

evaluate how both versions work together.

Ok - lets go.

Best regards
Werner

···

Am 15.10.2011 20:02, schrieb Emil Ivov:

On Oct 15, 2011 7:44 PM, "Bauersachs Ingo" <ingo.bauersachs@fhnw.ch> wrote:

Sure.

Ingo