Thread: [Opalvoip-devel] H.235.8 - SRTP over H.323
Brought to you by:
csoutheren,
rjongbloed
From: Robert J. <ro...@vo...> - 2013-07-10 08:44:31
|
Does anyone know of an endpoint that does SRTP over H.323, aka H.235.8? -- *Robert Jongbloed* /OPAL/OpenH323/PTLib Architect and Co-founder./ Commercial support at http://www.voxlucida.com.au |
From: Simon H. <s....@pa...> - 2013-07-10 12:10:54
|
Robert Nope. The universally agreed method in H.323 is H.235.6 (with AES128,256) and this is what is deployed. While it was agreed, as I understand, at the time that SRTP/H.235.8 for better interwork with SIP was going to be the "way" of the future it just never happened. BTW: We agreed at the last ITU meeting to revise H.235.6 to add 8k and 16k DH key length and more importantly to remove the restrictive word "voice" out of the title to indicate it is currently being deployed for both audio and video. Simon From: Robert Jongbloed [mailto:ro...@vo...] Sent: 10 July 2013 18:44 To: Opa...@li... Subject: [Opalvoip-devel] H.235.8 - SRTP over H.323 Does anyone know of an endpoint that does SRTP over H.323, aka H.235.8? -- Robert Jongbloed OPAL/OpenH323/PTLib Architect and Co-founder. Commercial support at http://www.voxlucida.com.au |
From: Robert J. <ro...@vo...> - 2013-07-10 23:04:40
|
So, you are saying the H.323 does not use SRTP at all? *Robert Jongbloed* /OPAL/OpenH323/PTLib Architect and Co-founder./ Commercial support at http://www.voxlucida.com.au On 10/07/2013 9:29 PM, Simon Horne wrote: > > Robert > > Nope. The universally agreed method in H.323 is H.235.6 (with > AES128,256) and this is what is deployed. > > While it was agreed, as I understand, at the time that SRTP/H.235.8 > for better interwork with SIP was going to be the "way" of the future > it just never happened. > > BTW: We agreed at the last ITU meeting to revise H.235.6 to add 8k and > 16k DH key length and more importantly to remove the restrictive word > "voice" out of the title to indicate it is currently being deployed > for both audio and video. > > Simon > > *From:*Robert Jongbloed [mailto:ro...@vo...] > *Sent:* 10 July 2013 18:44 > *To:* Opa...@li... > *Subject:* [Opalvoip-devel] H.235.8 - SRTP over H.323 > > Does anyone know of an endpoint that does SRTP over H.323, aka H.235.8? > > -- > > *Robert Jongbloed* > /OPAL/OpenH323/PTLib Architect and Co-founder./ > Commercial support at http://www.voxlucida.com.au > |
From: Simon H. <s....@pa...> - 2013-07-11 00:06:48
|
Robert Yes that is correct. While H.235.8 is defined there is NO SRTP deployed in H.323. H.235.6 is "native" and stenographic meaning it uses standard RTP and only encrypts the payload and pads/truncates the encrypted payload (multiple of key length) so it appears to wireshark etc as being just plain regular RTP. You will need to committed to adding encryption in H.323 as implementing H.235.6 is absolutely no simple undertaking and there is no possible interworking function with SIP other than proxy decrypt and re-encrypt. For instance we implemented in GnuGk the H.323 side H.235.6 encrypt/decrypt function so it could sit in front of the H.323/SIP border controller. Simon From: Robert Jongbloed [mailto:ro...@vo...] Sent: 11 July 2013 09:04 To: Opa...@li... Subject: Re: [Opalvoip-devel] H.235.8 - SRTP over H.323 So, you are saying the H.323 does not use SRTP at all? Robert Jongbloed OPAL/OpenH323/PTLib Architect and Co-founder. Commercial support at http://www.voxlucida.com.au On 10/07/2013 9:29 PM, Simon Horne wrote: Robert Nope. The universally agreed method in H.323 is H.235.6 (with AES128,256) and this is what is deployed. While it was agreed, as I understand, at the time that SRTP/H.235.8 for better interwork with SIP was going to be the "way" of the future it just never happened. BTW: We agreed at the last ITU meeting to revise H.235.6 to add 8k and 16k DH key length and more importantly to remove the restrictive word "voice" out of the title to indicate it is currently being deployed for both audio and video. Simon From: Robert Jongbloed [mailto:ro...@vo...] Sent: 10 July 2013 18:44 To: Opa...@li... Subject: [Opalvoip-devel] H.235.8 - SRTP over H.323 Does anyone know of an endpoint that does SRTP over H.323, aka H.235.8? -- Robert Jongbloed OPAL/OpenH323/PTLib Architect and Co-founder. Commercial support at http://www.voxlucida.com.au |
From: Robert J. <ro...@vo...> - 2013-07-11 00:12:11
|
Well, I am committed to doing what my customer pays me to do! :-) They said they wanted SRTP for H.323, but I will check if that is really the case. *Robert Jongbloed* /OPAL/OpenH323/PTLib Architect and Co-founder./ Commercial support at http://www.voxlucida.com.au On 11/07/2013 10:06 AM, Simon Horne wrote: > > Robert > > Yes that is correct. While H.235.8 is defined there is NO SRTP > deployed in H.323. H.235.6 is "native" and stenographic meaning it > uses standard RTP and only encrypts the payload and pads/truncates the > encrypted payload (multiple of key length) so it appears to wireshark > etc as being just plain regular RTP. > > You will need to committed to adding encryption in H.323 as > implementing H.235.6 is absolutely no simple undertaking and there is > no possible interworking function with SIP other than proxy decrypt > and re-encrypt. For instance we implemented in GnuGk the H.323 side > H.235.6 encrypt/decrypt function so it could sit in front of the > H.323/SIP border controller. > > Simon > > *From:*Robert Jongbloed [mailto:ro...@vo...] > *Sent:* 11 July 2013 09:04 > *To:* Opa...@li... > *Subject:* Re: [Opalvoip-devel] H.235.8 - SRTP over H.323 > > So, you are saying the H.323 does not use SRTP at all? > > *Robert Jongbloed* > /OPAL/OpenH323/PTLib Architect and Co-founder./ > Commercial support at http://www.voxlucida.com.au > > On 10/07/2013 9:29 PM, Simon Horne wrote: > > Robert > > Nope. The universally agreed method in H.323 is H.235.6 (with > AES128,256) and this is what is deployed. > > While it was agreed, as I understand, at the time that > SRTP/H.235.8 for better interwork with SIP was going to be the > "way" of the future it just never happened. > > BTW: We agreed at the last ITU meeting to revise H.235.6 to add 8k > and 16k DH key length and more importantly to remove the > restrictive word "voice" out of the title to indicate it is > currently being deployed for both audio and video. > > Simon > > *From:*Robert Jongbloed [mailto:ro...@vo...] > *Sent:* 10 July 2013 18:44 > *To:* Opa...@li... > <mailto:Opa...@li...> > *Subject:* [Opalvoip-devel] H.235.8 - SRTP over H.323 > > Does anyone know of an endpoint that does SRTP over H.323, aka > H.235.8? > > > -- > > *Robert Jongbloed* > /OPAL/OpenH323/PTLib Architect and Co-founder./ > Commercial support at http://www.voxlucida.com.au > |
From: Simon H. <s....@pa...> - 2013-07-11 02:32:43
|
Robert Just to clarify in H.323 the agreed industry standard is H.235.6 with 1024 DH Key and AES128 cipher. You can save your employer some money by grabbing the core RTP H.235.6 encryption logic (using OpenSSL) straight out of h323plus. J But honestly implementing the H.323 signaling side of media encryption (H.235.x) is still going to be a nightmare as it touches everything. H.225, H.245 (TCS and OLC) . There is DH Key matching/merging in H.225, Cipher matching/merging in the H.245 TCS (on every capability!) and that is just to generate the actual session key encrypted in the OLC/OLCack which is of course different for each RTP/RTCP media stream. Simon From: Robert Jongbloed [mailto:ro...@vo...] Sent: 11 July 2013 10:12 To: Opa...@li... Subject: Re: [Opalvoip-devel] H.235.8 - SRTP over H.323 Well, I am committed to doing what my customer pays me to do! :-) They said they wanted SRTP for H.323, but I will check if that is really the case. Robert Jongbloed OPAL/OpenH323/PTLib Architect and Co-founder. Commercial support at http://www.voxlucida.com.au On 11/07/2013 10:06 AM, Simon Horne wrote: Robert Yes that is correct. While H.235.8 is defined there is NO SRTP deployed in H.323. H.235.6 is "native" and stenographic meaning it uses standard RTP and only encrypts the payload and pads/truncates the encrypted payload (multiple of key length) so it appears to wireshark etc as being just plain regular RTP. You will need to committed to adding encryption in H.323 as implementing H.235.6 is absolutely no simple undertaking and there is no possible interworking function with SIP other than proxy decrypt and re-encrypt. For instance we implemented in GnuGk the H.323 side H.235.6 encrypt/decrypt function so it could sit in front of the H.323/SIP border controller. Simon From: Robert Jongbloed [mailto:ro...@vo...] Sent: 11 July 2013 09:04 To: Opa...@li... Subject: Re: [Opalvoip-devel] H.235.8 - SRTP over H.323 So, you are saying the H.323 does not use SRTP at all? Robert Jongbloed OPAL/OpenH323/PTLib Architect and Co-founder. Commercial support at http://www.voxlucida.com.au On 10/07/2013 9:29 PM, Simon Horne wrote: Robert Nope. The universally agreed method in H.323 is H.235.6 (with AES128,256) and this is what is deployed. While it was agreed, as I understand, at the time that SRTP/H.235.8 for better interwork with SIP was going to be the "way" of the future it just never happened. BTW: We agreed at the last ITU meeting to revise H.235.6 to add 8k and 16k DH key length and more importantly to remove the restrictive word "voice" out of the title to indicate it is currently being deployed for both audio and video. Simon From: Robert Jongbloed [mailto:ro...@vo...] Sent: 10 July 2013 18:44 To: Opa...@li... Subject: [Opalvoip-devel] H.235.8 - SRTP over H.323 Does anyone know of an endpoint that does SRTP over H.323, aka H.235.8? -- Robert Jongbloed OPAL/OpenH323/PTLib Architect and Co-founder. Commercial support at http://www.voxlucida.com.au |
From: Robert J. <ro...@vo...> - 2013-08-14 07:01:54
|
Hi Simon, while I could not use the actual code, OPAL and H323plus have diverged too far over the years, it was very instructive looking at the code. Thanks for doing the hard slog understanding the spec! Anyway, I /almost/ have it working. I have a question though, regarding RTP padding. The spec I have clearly states: [RTP], section 5.1 describes a method of padding in which the payload shall be padded to a multiple of blocks. The last octet shall be set to the number of padding octets (including the last), and the P bit set in the RTP header. The value of the pad should be determined by the normal convention of the cipher algorithm. however, the system I am testing against (Codian MSE4510) equally clearly does not do this! Is there some implementation note or late revision that states that this is an exception to RFC 3550 padding rules? And if so, how do you determine how many pad bytes are on the end? The reason I ask is because the OPAL code has the RFC 3550 padding support needed for some other random system. Temporarily disabling that code makes it work, but with numerous decode errors on both sides, presumably because of the padding. Note, audio is perfect because a 20ms G.711 packet is exactly divisible by the cipher block size. So, no padding occurs. *Robert Jongbloed* /OPAL/OpenH323/PTLib Architect and Co-founder./ Commercial support at http://www.voxlucida.com.au On 11/07/2013 12:32 PM, Simon Horne wrote: > > Robert > > Just to clarify in H.323 the agreed industry standard is H.235.6 with > 1024 DH Key and AES128 cipher. > > You can save your employer some money by grabbing the core RTP H.235.6 > encryption logic (using OpenSSL) straight out of h323plus. J > > But honestly implementing the H.323 signaling side of media encryption > (H.235.x) is still going to be a nightmare as it touches everything. > H.225, H.245 (TCS and OLC) . There is DH Key matching/merging in > H.225, Cipher matching/merging in the H.245 TCS (on every capability!) > and that is just to generate the actual session key encrypted in the > OLC/OLCack which is of course different for each RTP/RTCP media stream. > > Simon > > *From:*Robert Jongbloed [mailto:ro...@vo...] > *Sent:* 11 July 2013 10:12 > *To:* Opa...@li... > *Subject:* Re: [Opalvoip-devel] H.235.8 - SRTP over H.323 > > Well, I am committed to doing what my customer pays me to do! :-) > > They said they wanted SRTP for H.323, but I will check if that is > really the case. > > *Robert Jongbloed* > /OPAL/OpenH323/PTLib Architect and Co-founder./ > Commercial support at http://www.voxlucida.com.au > > On 11/07/2013 10:06 AM, Simon Horne wrote: > > Robert > > Yes that is correct. While H.235.8 is defined there is NO SRTP > deployed in H.323. H.235.6 is "native" and stenographic meaning it > uses standard RTP and only encrypts the payload and pads/truncates > the encrypted payload (multiple of key length) so it appears to > wireshark etc as being just plain regular RTP. > > You will need to committed to adding encryption in H.323 as > implementing H.235.6 is absolutely no simple undertaking and there > is no possible interworking function with SIP other than proxy > decrypt and re-encrypt. For instance we implemented in GnuGk the > H.323 side H.235.6 encrypt/decrypt function so it could sit in > front of the H.323/SIP border controller. > > Simon > > *From:*Robert Jongbloed [mailto:ro...@vo...] > *Sent:* 11 July 2013 09:04 > *To:* Opa...@li... > <mailto:Opa...@li...> > *Subject:* Re: [Opalvoip-devel] H.235.8 - SRTP over H.323 > > So, you are saying the H.323 does not use SRTP at all? > > *Robert Jongbloed* > /OPAL/OpenH323/PTLib Architect and Co-founder./ > Commercial support at http://www.voxlucida.com.au > > On 10/07/2013 9:29 PM, Simon Horne wrote: > > Robert > > Nope. The universally agreed method in H.323 is H.235.6 (with > AES128,256) and this is what is deployed. > > While it was agreed, as I understand, at the time that > SRTP/H.235.8 for better interwork with SIP was going to be the > "way" of the future it just never happened. > > BTW: We agreed at the last ITU meeting to revise H.235.6 to > add 8k and 16k DH key length and more importantly to remove > the restrictive word "voice" out of the title to indicate it > is currently being deployed for both audio and video. > > Simon > > *From:*Robert Jongbloed [mailto:ro...@vo...] > *Sent:* 10 July 2013 18:44 > *To:* Opa...@li... > <mailto:Opa...@li...> > *Subject:* [Opalvoip-devel] H.235.8 - SRTP over H.323 > > Does anyone know of an endpoint that does SRTP over H.323, aka > H.235.8? > > > > -- > > *Robert Jongbloed* > /OPAL/OpenH323/PTLib Architect and Co-founder./ > Commercial support at http://www.voxlucida.com.au > |
From: Simon H. <s....@pa...> - 2013-08-14 13:02:21
|
Robert The h323plus H.235.6 Implementation has been widely tested and the fix Jan added seems to work pretty much everywhere. Another thing you might do is grab the H.235 ASN.1 CVS code from h323plus too. There is a bug in the current spec H.235v4 that limits the DH size to 2048 bits (dhset field) but the H.235.6 spec says it can support 4096 bits. There is a fix in the ITU pipeline which adds a new dhextset field but that will take a while. I pushed that fix in the ASN.1 code. Simon -----Original Message----- From: Jan Willamowius [mailto:ja...@wi...] Sent: 14 August 2013 17:18 To: ro...@vo... Cc: Simon Horne; Opa...@li... Subject: Re: [Opalvoip-devel] H.235.8 - SRTP over H.323 Hi Robert, I wrote the low-level crypto for H323Plus and I found similar padding issues with Polycom endpoints. I don't think this is documented in the H.235 specs, at least I couldn't find anything, but it seems rather wide spread. Due to the differing padding conventions, you can't use OpenSSL's EVP_DecryptFinal() for an interoperable decode function. I put a substitute with relaxed padding checking into src/h235/h235crypto.cxx. Regards, Jan Robert Jongbloed wrote: > Hi Simon, > while I could not use the actual code, OPAL and H323plus have > diverged too far over the years, it was very instructive looking at > the code. Thanks for doing the hard slog understanding the spec! > > Anyway, I /almost/ have it working. > > I have a question though, regarding RTP padding. The spec I have > clearly > states: > > [RTP], section 5.1 describes a method of padding in which the > payload shall be padded to a > multiple of blocks. The last octet shall be set to the number of > padding octets (including the last), > and the P bit set in the RTP header. The value of the pad should be > determined by the normal > convention of the cipher algorithm. > > however, the system I am testing against (Codian MSE4510) equally > clearly does not do this! > > Is there some implementation note or late revision that states that > this is an exception to RFC 3550 padding rules? And if so, how do you > determine how many pad bytes are on the end? > > The reason I ask is because the OPAL code has the RFC 3550 padding > support needed for some other random system. Temporarily disabling > that code makes it work, but with numerous decode errors on both > sides, presumably because of the padding. > > Note, audio is perfect because a 20ms G.711 packet is exactly > divisible by the cipher block size. So, no padding occurs. > > *Robert Jongbloed* > /OPAL/OpenH323/PTLib Architect and Co-founder./ Commercial support at > http://www.voxlucida.com.au > > On 11/07/2013 12:32 PM, Simon Horne wrote: > > > > Robert > > > > Just to clarify in H.323 the agreed industry standard is H.235.6 > > with > > 1024 DH Key and AES128 cipher. > > > > You can save your employer some money by grabbing the core RTP > > H.235.6 encryption logic (using OpenSSL) straight out of h323plus. J > > > > But honestly implementing the H.323 signaling side of media > > encryption > > (H.235.x) is still going to be a nightmare as it touches everything. > > H.225, H.245 (TCS and OLC) . There is DH Key matching/merging in > > H.225, Cipher matching/merging in the H.245 TCS (on every > > capability!) and that is just to generate the actual session key > > encrypted in the OLC/OLCack which is of course different for each RTP/RTCP media stream. > > > > Simon > > > > *From:*Robert Jongbloed [mailto:ro...@vo...] > > *Sent:* 11 July 2013 10:12 > > *To:* Opa...@li... > > *Subject:* Re: [Opalvoip-devel] H.235.8 - SRTP over H.323 > > > > Well, I am committed to doing what my customer pays me to do! :-) > > > > They said they wanted SRTP for H.323, but I will check if that is > > really the case. > > > > *Robert Jongbloed* > > /OPAL/OpenH323/PTLib Architect and Co-founder./ Commercial support > > at http://www.voxlucida.com.au > > > > On 11/07/2013 10:06 AM, Simon Horne wrote: > > > > Robert > > > > Yes that is correct. While H.235.8 is defined there is NO SRTP > > deployed in H.323. H.235.6 is "native" and stenographic meaning it > > uses standard RTP and only encrypts the payload and pads/truncates > > the encrypted payload (multiple of key length) so it appears to > > wireshark etc as being just plain regular RTP. > > > > You will need to committed to adding encryption in H.323 as > > implementing H.235.6 is absolutely no simple undertaking and there > > is no possible interworking function with SIP other than proxy > > decrypt and re-encrypt. For instance we implemented in GnuGk the > > H.323 side H.235.6 encrypt/decrypt function so it could sit in > > front of the H.323/SIP border controller. > > > > Simon > > > > *From:*Robert Jongbloed [mailto:ro...@vo...] > > *Sent:* 11 July 2013 09:04 > > *To:* Opa...@li... > > <mailto:Opa...@li...> > > *Subject:* Re: [Opalvoip-devel] H.235.8 - SRTP over H.323 > > > > So, you are saying the H.323 does not use SRTP at all? > > > > *Robert Jongbloed* > > /OPAL/OpenH323/PTLib Architect and Co-founder./ > > Commercial support at http://www.voxlucida.com.au > > > > On 10/07/2013 9:29 PM, Simon Horne wrote: > > > > Robert > > > > Nope. The universally agreed method in H.323 is H.235.6 (with > > AES128,256) and this is what is deployed. > > > > While it was agreed, as I understand, at the time that > > SRTP/H.235.8 for better interwork with SIP was going to be the > > "way" of the future it just never happened. > > > > BTW: We agreed at the last ITU meeting to revise H.235.6 to > > add 8k and 16k DH key length and more importantly to remove > > the restrictive word "voice" out of the title to indicate it > > is currently being deployed for both audio and video. > > > > Simon > > > > *From:*Robert Jongbloed [mailto:ro...@vo...] > > *Sent:* 10 July 2013 18:44 > > *To:* Opa...@li... > > <mailto:Opa...@li...> > > *Subject:* [Opalvoip-devel] H.235.8 - SRTP over H.323 > > > > Does anyone know of an endpoint that does SRTP over H.323, aka > > H.235.8? > > > > > > > > -- > > > > *Robert Jongbloed* > > /OPAL/OpenH323/PTLib Architect and Co-founder./ > > Commercial support at http://www.voxlucida.com.au > > > -- Jan Willamowius, ja...@wi..., http://www.gnugk.org/ |
From: Robert J. <ro...@vo...> - 2013-08-15 00:34:43
|
I have no doubt that h323plus is highly interoperable, I would imagine you guys sweated blood over working out how to get around some big companies broken implementation, that they have so widely deployed it cannot be ignored. 14 years on in this game, and nothing has changed. Thanks for the tip on DHset. *Robert Jongbloed* /OPAL/OpenH323/PTLib Architect and Co-founder./ Commercial support at http://www.voxlucida.com.au On 14/08/2013 11:02 PM, Simon Horne wrote: > Robert > > The h323plus H.235.6 Implementation has been widely tested and the fix Jan > added seems to work pretty much everywhere. > > Another thing you might do is grab the H.235 ASN.1 CVS code from h323plus > too. There is a bug in the current spec H.235v4 that limits the DH size to > 2048 bits (dhset field) but the H.235.6 spec says it can support 4096 bits. > There is a fix in the ITU pipeline which adds a new dhextset field but that > will take a while. I pushed that fix in the ASN.1 code. > > Simon > > -----Original Message----- > From: Jan Willamowius [mailto:ja...@wi...] > Sent: 14 August 2013 17:18 > To: ro...@vo... > Cc: Simon Horne; Opa...@li... > Subject: Re: [Opalvoip-devel] H.235.8 - SRTP over H.323 > > Hi Robert, > > I wrote the low-level crypto for H323Plus and I found similar padding issues > with Polycom endpoints. I don't think this is documented in the > H.235 specs, at least I couldn't find anything, but it seems rather wide > spread. > > Due to the differing padding conventions, you can't use OpenSSL's > EVP_DecryptFinal() for an interoperable decode function. I put a substitute > with relaxed padding checking into src/h235/h235crypto.cxx. > > Regards, > Jan > > Robert Jongbloed wrote: >> Hi Simon, >> while I could not use the actual code, OPAL and H323plus have >> diverged too far over the years, it was very instructive looking at >> the code. Thanks for doing the hard slog understanding the spec! >> >> Anyway, I /almost/ have it working. >> >> I have a question though, regarding RTP padding. The spec I have >> clearly >> states: >> >> [RTP], section 5.1 describes a method of padding in which the >> payload shall be padded to a >> multiple of blocks. The last octet shall be set to the number of >> padding octets (including the last), >> and the P bit set in the RTP header. The value of the pad should be >> determined by the normal >> convention of the cipher algorithm. >> >> however, the system I am testing against (Codian MSE4510) equally >> clearly does not do this! >> >> Is there some implementation note or late revision that states that >> this is an exception to RFC 3550 padding rules? And if so, how do you >> determine how many pad bytes are on the end? >> >> The reason I ask is because the OPAL code has the RFC 3550 padding >> support needed for some other random system. Temporarily disabling >> that code makes it work, but with numerous decode errors on both >> sides, presumably because of the padding. >> >> Note, audio is perfect because a 20ms G.711 packet is exactly >> divisible by the cipher block size. So, no padding occurs. >> >> *Robert Jongbloed* >> /OPAL/OpenH323/PTLib Architect and Co-founder./ Commercial support at >> http://www.voxlucida.com.au >> >> On 11/07/2013 12:32 PM, Simon Horne wrote: >>> Robert >>> >>> Just to clarify in H.323 the agreed industry standard is H.235.6 >>> with >>> 1024 DH Key and AES128 cipher. >>> >>> You can save your employer some money by grabbing the core RTP >>> H.235.6 encryption logic (using OpenSSL) straight out of h323plus. J >>> >>> But honestly implementing the H.323 signaling side of media >>> encryption >>> (H.235.x) is still going to be a nightmare as it touches everything. >>> H.225, H.245 (TCS and OLC) . There is DH Key matching/merging in >>> H.225, Cipher matching/merging in the H.245 TCS (on every >>> capability!) and that is just to generate the actual session key >>> encrypted in the OLC/OLCack which is of course different for each > RTP/RTCP media stream. >>> Simon >>> >>> *From:*Robert Jongbloed [mailto:ro...@vo...] >>> *Sent:* 11 July 2013 10:12 >>> *To:* Opa...@li... >>> *Subject:* Re: [Opalvoip-devel] H.235.8 - SRTP over H.323 >>> >>> Well, I am committed to doing what my customer pays me to do! :-) >>> >>> They said they wanted SRTP for H.323, but I will check if that is >>> really the case. >>> >>> *Robert Jongbloed* >>> /OPAL/OpenH323/PTLib Architect and Co-founder./ Commercial support >>> at http://www.voxlucida.com.au >>> >>> On 11/07/2013 10:06 AM, Simon Horne wrote: >>> >>> Robert >>> >>> Yes that is correct. While H.235.8 is defined there is NO SRTP >>> deployed in H.323. H.235.6 is "native" and stenographic meaning it >>> uses standard RTP and only encrypts the payload and pads/truncates >>> the encrypted payload (multiple of key length) so it appears to >>> wireshark etc as being just plain regular RTP. >>> >>> You will need to committed to adding encryption in H.323 as >>> implementing H.235.6 is absolutely no simple undertaking and there >>> is no possible interworking function with SIP other than proxy >>> decrypt and re-encrypt. For instance we implemented in GnuGk the >>> H.323 side H.235.6 encrypt/decrypt function so it could sit in >>> front of the H.323/SIP border controller. >>> >>> Simon >>> >>> *From:*Robert Jongbloed [mailto:ro...@vo...] >>> *Sent:* 11 July 2013 09:04 >>> *To:* Opa...@li... >>> <mailto:Opa...@li...> >>> *Subject:* Re: [Opalvoip-devel] H.235.8 - SRTP over H.323 >>> >>> So, you are saying the H.323 does not use SRTP at all? >>> >>> *Robert Jongbloed* >>> /OPAL/OpenH323/PTLib Architect and Co-founder./ >>> Commercial support at http://www.voxlucida.com.au >>> >>> On 10/07/2013 9:29 PM, Simon Horne wrote: >>> >>> Robert >>> >>> Nope. The universally agreed method in H.323 is H.235.6 (with >>> AES128,256) and this is what is deployed. >>> >>> While it was agreed, as I understand, at the time that >>> SRTP/H.235.8 for better interwork with SIP was going to be the >>> "way" of the future it just never happened. >>> >>> BTW: We agreed at the last ITU meeting to revise H.235.6 to >>> add 8k and 16k DH key length and more importantly to remove >>> the restrictive word "voice" out of the title to indicate it >>> is currently being deployed for both audio and video. >>> >>> Simon >>> >>> *From:*Robert Jongbloed [mailto:ro...@vo...] >>> *Sent:* 10 July 2013 18:44 >>> *To:* Opa...@li... >>> <mailto:Opa...@li...> >>> *Subject:* [Opalvoip-devel] H.235.8 - SRTP over H.323 >>> >>> Does anyone know of an endpoint that does SRTP over H.323, aka >>> H.235.8? >>> >>> >>> >>> -- >>> >>> *Robert Jongbloed* >>> /OPAL/OpenH323/PTLib Architect and Co-founder./ >>> Commercial support at http://www.voxlucida.com.au >>> > > -- > Jan Willamowius, ja...@wi..., http://www.gnugk.org/ > |
From: Robert J. <ro...@vo...> - 2013-08-15 08:12:42
|
OPAL is now working against my one Codian test system. More testing to happen, but I'd call that a win for now! Just out of curiosity, are there plans to update H.235.6 to reflect the reality of the RTP padding bit handling? As far as I can tell, the way it is actually done, is inconsistent with the specification. The H.235.6 document I have, implies it is to be conformant with RFC 3550, with both the quote I made earlier and table I.7 indicating a length byte at the end. But that is not what actually happens, and I cannot see how to make a system work in both ways. It's not one of the common cases of "be strict with what you send and forgiving in what you receive". We have to send the data "incorrectly" as well. I presume everyone does it that way now, or nothing would work. *Robert Jongbloed* /OPAL/OpenH323/PTLib Architect and Co-founder./ Commercial support at http://www.voxlucida.com.au On 14/08/2013 11:02 PM, Simon Horne wrote: > Robert > > The h323plus H.235.6 Implementation has been widely tested and the fix Jan > added seems to work pretty much everywhere. > > Another thing you might do is grab the H.235 ASN.1 CVS code from h323plus > too. There is a bug in the current spec H.235v4 that limits the DH size to > 2048 bits (dhset field) but the H.235.6 spec says it can support 4096 bits. > There is a fix in the ITU pipeline which adds a new dhextset field but that > will take a while. I pushed that fix in the ASN.1 code. > > Simon > > -----Original Message----- > From: Jan Willamowius [mailto:ja...@wi...] > Sent: 14 August 2013 17:18 > To: ro...@vo... > Cc: Simon Horne; Opa...@li... > Subject: Re: [Opalvoip-devel] H.235.8 - SRTP over H.323 > > Hi Robert, > > I wrote the low-level crypto for H323Plus and I found similar padding issues > with Polycom endpoints. I don't think this is documented in the > H.235 specs, at least I couldn't find anything, but it seems rather wide > spread. > > Due to the differing padding conventions, you can't use OpenSSL's > EVP_DecryptFinal() for an interoperable decode function. I put a substitute > with relaxed padding checking into src/h235/h235crypto.cxx. > > Regards, > Jan > > Robert Jongbloed wrote: >> Hi Simon, >> while I could not use the actual code, OPAL and H323plus have >> diverged too far over the years, it was very instructive looking at >> the code. Thanks for doing the hard slog understanding the spec! >> >> Anyway, I /almost/ have it working. >> >> I have a question though, regarding RTP padding. The spec I have >> clearly >> states: >> >> [RTP], section 5.1 describes a method of padding in which the >> payload shall be padded to a >> multiple of blocks. The last octet shall be set to the number of >> padding octets (including the last), >> and the P bit set in the RTP header. The value of the pad should be >> determined by the normal >> convention of the cipher algorithm. >> >> however, the system I am testing against (Codian MSE4510) equally >> clearly does not do this! >> >> Is there some implementation note or late revision that states that >> this is an exception to RFC 3550 padding rules? And if so, how do you >> determine how many pad bytes are on the end? >> >> The reason I ask is because the OPAL code has the RFC 3550 padding >> support needed for some other random system. Temporarily disabling >> that code makes it work, but with numerous decode errors on both >> sides, presumably because of the padding. >> >> Note, audio is perfect because a 20ms G.711 packet is exactly >> divisible by the cipher block size. So, no padding occurs. >> >> *Robert Jongbloed* >> /OPAL/OpenH323/PTLib Architect and Co-founder./ Commercial support at >> http://www.voxlucida.com.au >> >> On 11/07/2013 12:32 PM, Simon Horne wrote: >>> Robert >>> >>> Just to clarify in H.323 the agreed industry standard is H.235.6 >>> with >>> 1024 DH Key and AES128 cipher. >>> >>> You can save your employer some money by grabbing the core RTP >>> H.235.6 encryption logic (using OpenSSL) straight out of h323plus. J >>> >>> But honestly implementing the H.323 signaling side of media >>> encryption >>> (H.235.x) is still going to be a nightmare as it touches everything. >>> H.225, H.245 (TCS and OLC) . There is DH Key matching/merging in >>> H.225, Cipher matching/merging in the H.245 TCS (on every >>> capability!) and that is just to generate the actual session key >>> encrypted in the OLC/OLCack which is of course different for each > RTP/RTCP media stream. >>> Simon >>> >>> *From:*Robert Jongbloed [mailto:ro...@vo...] >>> *Sent:* 11 July 2013 10:12 >>> *To:* Opa...@li... >>> *Subject:* Re: [Opalvoip-devel] H.235.8 - SRTP over H.323 >>> >>> Well, I am committed to doing what my customer pays me to do! :-) >>> >>> They said they wanted SRTP for H.323, but I will check if that is >>> really the case. >>> >>> *Robert Jongbloed* >>> /OPAL/OpenH323/PTLib Architect and Co-founder./ Commercial support >>> at http://www.voxlucida.com.au >>> >>> On 11/07/2013 10:06 AM, Simon Horne wrote: >>> >>> Robert >>> >>> Yes that is correct. While H.235.8 is defined there is NO SRTP >>> deployed in H.323. H.235.6 is "native" and stenographic meaning it >>> uses standard RTP and only encrypts the payload and pads/truncates >>> the encrypted payload (multiple of key length) so it appears to >>> wireshark etc as being just plain regular RTP. >>> >>> You will need to committed to adding encryption in H.323 as >>> implementing H.235.6 is absolutely no simple undertaking and there >>> is no possible interworking function with SIP other than proxy >>> decrypt and re-encrypt. For instance we implemented in GnuGk the >>> H.323 side H.235.6 encrypt/decrypt function so it could sit in >>> front of the H.323/SIP border controller. >>> >>> Simon >>> >>> *From:*Robert Jongbloed [mailto:ro...@vo...] >>> *Sent:* 11 July 2013 09:04 >>> *To:* Opa...@li... >>> <mailto:Opa...@li...> >>> *Subject:* Re: [Opalvoip-devel] H.235.8 - SRTP over H.323 >>> >>> So, you are saying the H.323 does not use SRTP at all? >>> >>> *Robert Jongbloed* >>> /OPAL/OpenH323/PTLib Architect and Co-founder./ >>> Commercial support at http://www.voxlucida.com.au >>> >>> On 10/07/2013 9:29 PM, Simon Horne wrote: >>> >>> Robert >>> >>> Nope. The universally agreed method in H.323 is H.235.6 (with >>> AES128,256) and this is what is deployed. >>> >>> While it was agreed, as I understand, at the time that >>> SRTP/H.235.8 for better interwork with SIP was going to be the >>> "way" of the future it just never happened. >>> >>> BTW: We agreed at the last ITU meeting to revise H.235.6 to >>> add 8k and 16k DH key length and more importantly to remove >>> the restrictive word "voice" out of the title to indicate it >>> is currently being deployed for both audio and video. >>> >>> Simon >>> >>> *From:*Robert Jongbloed [mailto:ro...@vo...] >>> *Sent:* 10 July 2013 18:44 >>> *To:* Opa...@li... >>> <mailto:Opa...@li...> >>> *Subject:* [Opalvoip-devel] H.235.8 - SRTP over H.323 >>> >>> Does anyone know of an endpoint that does SRTP over H.323, aka >>> H.235.8? >>> >>> >>> >>> -- >>> >>> *Robert Jongbloed* >>> /OPAL/OpenH323/PTLib Architect and Co-founder./ >>> Commercial support at http://www.voxlucida.com.au >>> > > -- > Jan Willamowius, ja...@wi..., http://www.gnugk.org/ > |
From: Jan W. <ja...@wi...> - 2013-07-15 11:38:16
|
Hi, while I agree that H.235.6 is what most endpoints use, it would be great to see H.235.8 implemented as well. It does support certificate exchange between both parties in the call so you can be sure you are actually encrypting to the right destination which H.235.6 lacks. According to this document H.235.8 is supported by Cisco IOS: http://www.cisco.com/en/US/docs/ios/12_4t/12_4t11/htsecure.html Regards, Jan Simon Horne wrote: > Robert > > > > Just to clarify in H.323 the agreed industry standard is H.235.6 with 1024 > DH Key and AES128 cipher. > > > > You can save your employer some money by grabbing the core RTP H.235.6 > encryption logic (using OpenSSL) straight out of h323plus. J > > > > But honestly implementing the H.323 signaling side of media encryption > (H.235.x) is still going to be a nightmare as it touches everything. H.225, > H.245 (TCS and OLC) . There is DH Key matching/merging in H.225, Cipher > matching/merging in the H.245 TCS (on every capability!) and that is just to > generate the actual session key encrypted in the OLC/OLCack which is of > course different for each RTP/RTCP media stream. > > > > Simon > > > > From: Robert Jongbloed [mailto:ro...@vo...] > Sent: 11 July 2013 10:12 > To: Opa...@li... > Subject: Re: [Opalvoip-devel] H.235.8 - SRTP over H.323 > > > > Well, I am committed to doing what my customer pays me to do! :-) > > They said they wanted SRTP for H.323, but I will check if that is really the > case. > > Robert Jongbloed > OPAL/OpenH323/PTLib Architect and Co-founder. > Commercial support at http://www.voxlucida.com.au > > On 11/07/2013 10:06 AM, Simon Horne wrote: > > Robert > > > > Yes that is correct. While H.235.8 is defined there is NO SRTP deployed in > H.323. H.235.6 is "native" and stenographic meaning it uses standard RTP and > only encrypts the payload and pads/truncates the encrypted payload (multiple > of key length) so it appears to wireshark etc as being just plain regular > RTP. > > > > You will need to committed to adding encryption in H.323 as implementing > H.235.6 is absolutely no simple undertaking and there is no possible > interworking function with SIP other than proxy decrypt and re-encrypt. For > instance we implemented in GnuGk the H.323 side H.235.6 encrypt/decrypt > function so it could sit in front of the H.323/SIP border controller. > > > > Simon > > > > From: Robert Jongbloed [mailto:ro...@vo...] > Sent: 11 July 2013 09:04 > To: Opa...@li... > Subject: Re: [Opalvoip-devel] H.235.8 - SRTP over H.323 > > > > So, you are saying the H.323 does not use SRTP at all? > > Robert Jongbloed > OPAL/OpenH323/PTLib Architect and Co-founder. > Commercial support at http://www.voxlucida.com.au > > On 10/07/2013 9:29 PM, Simon Horne wrote: > > Robert > > > > Nope. The universally agreed method in H.323 is H.235.6 (with AES128,256) > and this is what is deployed. > > While it was agreed, as I understand, at the time that SRTP/H.235.8 for > better interwork with SIP was going to be the "way" of the future it just > never happened. > > > > BTW: We agreed at the last ITU meeting to revise H.235.6 to add 8k and 16k > DH key length and more importantly to remove the restrictive word "voice" > out of the title to indicate it is currently being deployed for both audio > and video. > > > > Simon > > > > From: Robert Jongbloed [mailto:ro...@vo...] > Sent: 10 July 2013 18:44 > To: Opa...@li... > Subject: [Opalvoip-devel] H.235.8 - SRTP over H.323 > > > > Does anyone know of an endpoint that does SRTP over H.323, aka H.235.8? > > > > > > -- > > Robert Jongbloed > OPAL/OpenH323/PTLib Architect and Co-founder. > Commercial support at http://www.voxlucida.com.au > > > > > -- Jan Willamowius, ja...@wi..., http://www.gnugk.org/ |
From: Robert J. <ro...@vo...> - 2013-07-17 01:50:40
|
Thank you very much Jan, very useful to know. My quick web searches were a bit ambiguous in that I could get confirmation on SRTP, but nothing linking it to H.323. It was implied, but H.235.8 was not mentioned. Your reference does mention it which make me feel much better that my work was not completely wasted. FYI, OPAL does now do SRTP using H.235.8 key exchange /with itself/. I now need to find a system with that IOS to interop with, and figure out what I have done wrong. :-) And, of course, I may yet need to do the H.235.6 method. :-( Ah, standards, so many to choose from! *Robert Jongbloed* OPAL/OpenH323/PTLib Architect and Co-founder. Commercial support at http://www.voxlucida.com.au /Travelling, so email responses may be slow!/ On 15/07/13 9:38 PM, Jan Willamowius wrote: > Hi, > > while I agree that H.235.6 is what most endpoints use, it would be > great to see H.235.8 implemented as well. It does support certificate > exchange between both parties in the call so you can be sure you are > actually encrypting to the right destination which H.235.6 lacks. > > According to this document H.235.8 is supported by Cisco IOS: > http://www.cisco.com/en/US/docs/ios/12_4t/12_4t11/htsecure.html > > Regards, > Jan > > Simon Horne wrote: >> Robert >> >> >> >> Just to clarify in H.323 the agreed industry standard is H.235.6 with 1024 >> DH Key and AES128 cipher. >> >> >> >> You can save your employer some money by grabbing the core RTP H.235.6 >> encryption logic (using OpenSSL) straight out of h323plus. J >> >> >> >> But honestly implementing the H.323 signaling side of media encryption >> (H.235.x) is still going to be a nightmare as it touches everything. H.225, >> H.245 (TCS and OLC) . There is DH Key matching/merging in H.225, Cipher >> matching/merging in the H.245 TCS (on every capability!) and that is just to >> generate the actual session key encrypted in the OLC/OLCack which is of >> course different for each RTP/RTCP media stream. >> >> >> >> Simon >> >> >> >> From: Robert Jongbloed [mailto:ro...@vo...] >> Sent: 11 July 2013 10:12 >> To: Opa...@li... >> Subject: Re: [Opalvoip-devel] H.235.8 - SRTP over H.323 >> >> >> >> Well, I am committed to doing what my customer pays me to do! :-) >> >> They said they wanted SRTP for H.323, but I will check if that is really the >> case. >> >> Robert Jongbloed >> OPAL/OpenH323/PTLib Architect and Co-founder. >> Commercial support at http://www.voxlucida.com.au >> >> On 11/07/2013 10:06 AM, Simon Horne wrote: >> >> Robert >> >> >> >> Yes that is correct. While H.235.8 is defined there is NO SRTP deployed in >> H.323. H.235.6 is "native" and stenographic meaning it uses standard RTP and >> only encrypts the payload and pads/truncates the encrypted payload (multiple >> of key length) so it appears to wireshark etc as being just plain regular >> RTP. >> >> >> >> You will need to committed to adding encryption in H.323 as implementing >> H.235.6 is absolutely no simple undertaking and there is no possible >> interworking function with SIP other than proxy decrypt and re-encrypt. For >> instance we implemented in GnuGk the H.323 side H.235.6 encrypt/decrypt >> function so it could sit in front of the H.323/SIP border controller. >> >> >> >> Simon >> >> >> >> From: Robert Jongbloed [mailto:ro...@vo...] >> Sent: 11 July 2013 09:04 >> To: Opa...@li... >> Subject: Re: [Opalvoip-devel] H.235.8 - SRTP over H.323 >> >> >> >> So, you are saying the H.323 does not use SRTP at all? >> >> Robert Jongbloed >> OPAL/OpenH323/PTLib Architect and Co-founder. >> Commercial support at http://www.voxlucida.com.au >> >> On 10/07/2013 9:29 PM, Simon Horne wrote: >> >> Robert >> >> >> >> Nope. The universally agreed method in H.323 is H.235.6 (with AES128,256) >> and this is what is deployed. >> >> While it was agreed, as I understand, at the time that SRTP/H.235.8 for >> better interwork with SIP was going to be the "way" of the future it just >> never happened. >> >> >> >> BTW: We agreed at the last ITU meeting to revise H.235.6 to add 8k and 16k >> DH key length and more importantly to remove the restrictive word "voice" >> out of the title to indicate it is currently being deployed for both audio >> and video. >> >> >> >> Simon >> >> >> >> From: Robert Jongbloed [mailto:ro...@vo...] >> Sent: 10 July 2013 18:44 >> To: Opa...@li... >> Subject: [Opalvoip-devel] H.235.8 - SRTP over H.323 >> >> >> >> Does anyone know of an endpoint that does SRTP over H.323, aka H.235.8? >> >> >> >> >> >> -- >> >> Robert Jongbloed >> OPAL/OpenH323/PTLib Architect and Co-founder. >> Commercial support at http://www.voxlucida.com.au >> >> >> >> >> > |
From: Jan W. <ja...@wi...> - 2013-08-14 07:18:10
|
Hi Robert, I wrote the low-level crypto for H323Plus and I found similar padding issues with Polycom endpoints. I don't think this is documented in the H.235 specs, at least I couldn't find anything, but it seems rather wide spread. Due to the differing padding conventions, you can't use OpenSSL's EVP_DecryptFinal() for an interoperable decode function. I put a substitute with relaxed padding checking into src/h235/h235crypto.cxx. Regards, Jan Robert Jongbloed wrote: > Hi Simon, > while I could not use the actual code, OPAL and H323plus have > diverged too far over the years, it was very instructive looking at the > code. Thanks for doing the hard slog understanding the spec! > > Anyway, I /almost/ have it working. > > I have a question though, regarding RTP padding. The spec I have clearly > states: > > [RTP], section 5.1 describes a method of padding in which the > payload shall be padded to a > multiple of blocks. The last octet shall be set to the number of > padding octets (including the last), > and the P bit set in the RTP header. The value of the pad should be > determined by the normal > convention of the cipher algorithm. > > however, the system I am testing against (Codian MSE4510) equally > clearly does not do this! > > Is there some implementation note or late revision that states that this > is an exception to RFC 3550 padding rules? And if so, how do you > determine how many pad bytes are on the end? > > The reason I ask is because the OPAL code has the RFC 3550 padding > support needed for some other random system. Temporarily disabling that > code makes it work, but with numerous decode errors on both sides, > presumably because of the padding. > > Note, audio is perfect because a 20ms G.711 packet is exactly divisible > by the cipher block size. So, no padding occurs. > > *Robert Jongbloed* > /OPAL/OpenH323/PTLib Architect and Co-founder./ > Commercial support at http://www.voxlucida.com.au > > On 11/07/2013 12:32 PM, Simon Horne wrote: > > > > Robert > > > > Just to clarify in H.323 the agreed industry standard is H.235.6 with > > 1024 DH Key and AES128 cipher. > > > > You can save your employer some money by grabbing the core RTP H.235.6 > > encryption logic (using OpenSSL) straight out of h323plus. J > > > > But honestly implementing the H.323 signaling side of media encryption > > (H.235.x) is still going to be a nightmare as it touches everything. > > H.225, H.245 (TCS and OLC) . There is DH Key matching/merging in > > H.225, Cipher matching/merging in the H.245 TCS (on every capability!) > > and that is just to generate the actual session key encrypted in the > > OLC/OLCack which is of course different for each RTP/RTCP media stream. > > > > Simon > > > > *From:*Robert Jongbloed [mailto:ro...@vo...] > > *Sent:* 11 July 2013 10:12 > > *To:* Opa...@li... > > *Subject:* Re: [Opalvoip-devel] H.235.8 - SRTP over H.323 > > > > Well, I am committed to doing what my customer pays me to do! :-) > > > > They said they wanted SRTP for H.323, but I will check if that is > > really the case. > > > > *Robert Jongbloed* > > /OPAL/OpenH323/PTLib Architect and Co-founder./ > > Commercial support at http://www.voxlucida.com.au > > > > On 11/07/2013 10:06 AM, Simon Horne wrote: > > > > Robert > > > > Yes that is correct. While H.235.8 is defined there is NO SRTP > > deployed in H.323. H.235.6 is "native" and stenographic meaning it > > uses standard RTP and only encrypts the payload and pads/truncates > > the encrypted payload (multiple of key length) so it appears to > > wireshark etc as being just plain regular RTP. > > > > You will need to committed to adding encryption in H.323 as > > implementing H.235.6 is absolutely no simple undertaking and there > > is no possible interworking function with SIP other than proxy > > decrypt and re-encrypt. For instance we implemented in GnuGk the > > H.323 side H.235.6 encrypt/decrypt function so it could sit in > > front of the H.323/SIP border controller. > > > > Simon > > > > *From:*Robert Jongbloed [mailto:ro...@vo...] > > *Sent:* 11 July 2013 09:04 > > *To:* Opa...@li... > > <mailto:Opa...@li...> > > *Subject:* Re: [Opalvoip-devel] H.235.8 - SRTP over H.323 > > > > So, you are saying the H.323 does not use SRTP at all? > > > > *Robert Jongbloed* > > /OPAL/OpenH323/PTLib Architect and Co-founder./ > > Commercial support at http://www.voxlucida.com.au > > > > On 10/07/2013 9:29 PM, Simon Horne wrote: > > > > Robert > > > > Nope. The universally agreed method in H.323 is H.235.6 (with > > AES128,256) and this is what is deployed. > > > > While it was agreed, as I understand, at the time that > > SRTP/H.235.8 for better interwork with SIP was going to be the > > "way" of the future it just never happened. > > > > BTW: We agreed at the last ITU meeting to revise H.235.6 to > > add 8k and 16k DH key length and more importantly to remove > > the restrictive word "voice" out of the title to indicate it > > is currently being deployed for both audio and video. > > > > Simon > > > > *From:*Robert Jongbloed [mailto:ro...@vo...] > > *Sent:* 10 July 2013 18:44 > > *To:* Opa...@li... > > <mailto:Opa...@li...> > > *Subject:* [Opalvoip-devel] H.235.8 - SRTP over H.323 > > > > Does anyone know of an endpoint that does SRTP over H.323, aka > > H.235.8? > > > > > > > > -- > > > > *Robert Jongbloed* > > /OPAL/OpenH323/PTLib Architect and Co-founder./ > > Commercial support at http://www.voxlucida.com.au > > > -- Jan Willamowius, ja...@wi..., http://www.gnugk.org/ |
From: Robert J. <ro...@vo...> - 2013-08-15 01:16:07
|
Yeah, saw that code, but could not quite figure out what it actually did. I am always reluctant to put code in that I at least have a rudimentary idea of what it does. As best I can tell, the only difference between the standard code and your code is the bit that is commented out, correct? And Polycom (and apparently Codian, and possibly everyone ...) do PKCS padding when the "pad" bit in RTP is set and cipher stealing when not. Correct? Thanks heaps for you help on this. *Robert Jongbloed* /OPAL/OpenH323/PTLib Architect and Co-founder./ Commercial support at http://www.voxlucida.com.au On 14/08/2013 5:18 PM, Jan Willamowius wrote: > Hi Robert, > > I wrote the low-level crypto for H323Plus and I found similar padding > issues with Polycom endpoints. I don't think this is documented in the > H.235 specs, at least I couldn't find anything, but it seems rather wide > spread. > > Due to the differing padding conventions, you can't use OpenSSL's > EVP_DecryptFinal() for an interoperable decode function. I put a > substitute with relaxed padding checking into src/h235/h235crypto.cxx. > > Regards, > Jan > > Robert Jongbloed wrote: >> Hi Simon, >> while I could not use the actual code, OPAL and H323plus have >> diverged too far over the years, it was very instructive looking at the >> code. Thanks for doing the hard slog understanding the spec! >> >> Anyway, I /almost/ have it working. >> >> I have a question though, regarding RTP padding. The spec I have clearly >> states: >> >> [RTP], section 5.1 describes a method of padding in which the >> payload shall be padded to a >> multiple of blocks. The last octet shall be set to the number of >> padding octets (including the last), >> and the P bit set in the RTP header. The value of the pad should be >> determined by the normal >> convention of the cipher algorithm. >> >> however, the system I am testing against (Codian MSE4510) equally >> clearly does not do this! >> >> Is there some implementation note or late revision that states that this >> is an exception to RFC 3550 padding rules? And if so, how do you >> determine how many pad bytes are on the end? >> >> The reason I ask is because the OPAL code has the RFC 3550 padding >> support needed for some other random system. Temporarily disabling that >> code makes it work, but with numerous decode errors on both sides, >> presumably because of the padding. >> >> Note, audio is perfect because a 20ms G.711 packet is exactly divisible >> by the cipher block size. So, no padding occurs. >> >> *Robert Jongbloed* >> /OPAL/OpenH323/PTLib Architect and Co-founder./ >> Commercial support at http://www.voxlucida.com.au >> >> On 11/07/2013 12:32 PM, Simon Horne wrote: >>> Robert >>> >>> Just to clarify in H.323 the agreed industry standard is H.235.6 with >>> 1024 DH Key and AES128 cipher. >>> >>> You can save your employer some money by grabbing the core RTP H.235.6 >>> encryption logic (using OpenSSL) straight out of h323plus. J >>> >>> But honestly implementing the H.323 signaling side of media encryption >>> (H.235.x) is still going to be a nightmare as it touches everything. >>> H.225, H.245 (TCS and OLC) . There is DH Key matching/merging in >>> H.225, Cipher matching/merging in the H.245 TCS (on every capability!) >>> and that is just to generate the actual session key encrypted in the >>> OLC/OLCack which is of course different for each RTP/RTCP media stream. >>> >>> Simon >>> >>> *From:*Robert Jongbloed [mailto:ro...@vo...] >>> *Sent:* 11 July 2013 10:12 >>> *To:* Opa...@li... >>> *Subject:* Re: [Opalvoip-devel] H.235.8 - SRTP over H.323 >>> >>> Well, I am committed to doing what my customer pays me to do! :-) >>> >>> They said they wanted SRTP for H.323, but I will check if that is >>> really the case. >>> >>> *Robert Jongbloed* >>> /OPAL/OpenH323/PTLib Architect and Co-founder./ >>> Commercial support at http://www.voxlucida.com.au >>> >>> On 11/07/2013 10:06 AM, Simon Horne wrote: >>> >>> Robert >>> >>> Yes that is correct. While H.235.8 is defined there is NO SRTP >>> deployed in H.323. H.235.6 is "native" and stenographic meaning it >>> uses standard RTP and only encrypts the payload and pads/truncates >>> the encrypted payload (multiple of key length) so it appears to >>> wireshark etc as being just plain regular RTP. >>> >>> You will need to committed to adding encryption in H.323 as >>> implementing H.235.6 is absolutely no simple undertaking and there >>> is no possible interworking function with SIP other than proxy >>> decrypt and re-encrypt. For instance we implemented in GnuGk the >>> H.323 side H.235.6 encrypt/decrypt function so it could sit in >>> front of the H.323/SIP border controller. >>> >>> Simon >>> >>> *From:*Robert Jongbloed [mailto:ro...@vo...] >>> *Sent:* 11 July 2013 09:04 >>> *To:* Opa...@li... >>> <mailto:Opa...@li...> >>> *Subject:* Re: [Opalvoip-devel] H.235.8 - SRTP over H.323 >>> >>> So, you are saying the H.323 does not use SRTP at all? >>> >>> *Robert Jongbloed* >>> /OPAL/OpenH323/PTLib Architect and Co-founder./ >>> Commercial support at http://www.voxlucida.com.au >>> >>> On 10/07/2013 9:29 PM, Simon Horne wrote: >>> >>> Robert >>> >>> Nope. The universally agreed method in H.323 is H.235.6 (with >>> AES128,256) and this is what is deployed. >>> >>> While it was agreed, as I understand, at the time that >>> SRTP/H.235.8 for better interwork with SIP was going to be the >>> "way" of the future it just never happened. >>> >>> BTW: We agreed at the last ITU meeting to revise H.235.6 to >>> add 8k and 16k DH key length and more importantly to remove >>> the restrictive word "voice" out of the title to indicate it >>> is currently being deployed for both audio and video. >>> >>> Simon >>> >>> *From:*Robert Jongbloed [mailto:ro...@vo...] >>> *Sent:* 10 July 2013 18:44 >>> *To:* Opa...@li... >>> <mailto:Opa...@li...> >>> *Subject:* [Opalvoip-devel] H.235.8 - SRTP over H.323 >>> >>> Does anyone know of an endpoint that does SRTP over H.323, aka >>> H.235.8? >>> >>> >>> >>> -- >>> >>> *Robert Jongbloed* >>> /OPAL/OpenH323/PTLib Architect and Co-founder./ >>> Commercial support at http://www.voxlucida.com.au >>> > |
From: Jan W. <ja...@wi...> - 2013-08-15 08:32:42
|
I just removed the check for the padding. It would be even better to check if the padding is either RFC or "Polycom padding". I'm not sure if everyone is doing the wrong padding. I have a faint memory that I've also seen correct padding, but can't really remember from which endpoint (Tandberg ?). You can also see my attempts at ciphertext stealing for encryption in the H323Plus code, but that only works with itself and can't be decoded by big vendor enpoints and thus its curently disabled. It would save a few bytes on each video packet if we can get that working. Regards, Jan Robert Jongbloed wrote: > Yeah, saw that code, but could not quite figure out what it actually > did. I am always reluctant to put code in that I at least have a > rudimentary idea of what it does. > > As best I can tell, the only difference between the standard code and > your code is the bit that is commented out, correct? > > And Polycom (and apparently Codian, and possibly everyone ...) do PKCS > padding when the "pad" bit in RTP is set and cipher stealing when not. > Correct? > > > Thanks heaps for you help on this. > > *Robert Jongbloed* > /OPAL/OpenH323/PTLib Architect and Co-founder./ > Commercial support at http://www.voxlucida.com.au > > On 14/08/2013 5:18 PM, Jan Willamowius wrote: > > Hi Robert, > > > > I wrote the low-level crypto for H323Plus and I found similar padding > > issues with Polycom endpoints. I don't think this is documented in the > > H.235 specs, at least I couldn't find anything, but it seems rather wide > > spread. > > > > Due to the differing padding conventions, you can't use OpenSSL's > > EVP_DecryptFinal() for an interoperable decode function. I put a > > substitute with relaxed padding checking into src/h235/h235crypto.cxx. > > > > Regards, > > Jan > > > > Robert Jongbloed wrote: > >> Hi Simon, > >> while I could not use the actual code, OPAL and H323plus have > >> diverged too far over the years, it was very instructive looking at the > >> code. Thanks for doing the hard slog understanding the spec! > >> > >> Anyway, I /almost/ have it working. > >> > >> I have a question though, regarding RTP padding. The spec I have clearly > >> states: > >> > >> [RTP], section 5.1 describes a method of padding in which the > >> payload shall be padded to a > >> multiple of blocks. The last octet shall be set to the number of > >> padding octets (including the last), > >> and the P bit set in the RTP header. The value of the pad should be > >> determined by the normal > >> convention of the cipher algorithm. > >> > >> however, the system I am testing against (Codian MSE4510) equally > >> clearly does not do this! > >> > >> Is there some implementation note or late revision that states that this > >> is an exception to RFC 3550 padding rules? And if so, how do you > >> determine how many pad bytes are on the end? > >> > >> The reason I ask is because the OPAL code has the RFC 3550 padding > >> support needed for some other random system. Temporarily disabling that > >> code makes it work, but with numerous decode errors on both sides, > >> presumably because of the padding. > >> > >> Note, audio is perfect because a 20ms G.711 packet is exactly divisible > >> by the cipher block size. So, no padding occurs. > >> > >> *Robert Jongbloed* > >> /OPAL/OpenH323/PTLib Architect and Co-founder./ > >> Commercial support at http://www.voxlucida.com.au > >> > >> On 11/07/2013 12:32 PM, Simon Horne wrote: > >>> Robert > >>> > >>> Just to clarify in H.323 the agreed industry standard is H.235.6 with > >>> 1024 DH Key and AES128 cipher. > >>> > >>> You can save your employer some money by grabbing the core RTP H.235.6 > >>> encryption logic (using OpenSSL) straight out of h323plus. J > >>> > >>> But honestly implementing the H.323 signaling side of media encryption > >>> (H.235.x) is still going to be a nightmare as it touches everything. > >>> H.225, H.245 (TCS and OLC) . There is DH Key matching/merging in > >>> H.225, Cipher matching/merging in the H.245 TCS (on every capability!) > >>> and that is just to generate the actual session key encrypted in the > >>> OLC/OLCack which is of course different for each RTP/RTCP media stream. > >>> > >>> Simon > >>> > >>> *From:*Robert Jongbloed [mailto:ro...@vo...] > >>> *Sent:* 11 July 2013 10:12 > >>> *To:* Opa...@li... > >>> *Subject:* Re: [Opalvoip-devel] H.235.8 - SRTP over H.323 > >>> > >>> Well, I am committed to doing what my customer pays me to do! :-) > >>> > >>> They said they wanted SRTP for H.323, but I will check if that is > >>> really the case. > >>> > >>> *Robert Jongbloed* > >>> /OPAL/OpenH323/PTLib Architect and Co-founder./ > >>> Commercial support at http://www.voxlucida.com.au > >>> > >>> On 11/07/2013 10:06 AM, Simon Horne wrote: > >>> > >>> Robert > >>> > >>> Yes that is correct. While H.235.8 is defined there is NO SRTP > >>> deployed in H.323. H.235.6 is "native" and stenographic meaning it > >>> uses standard RTP and only encrypts the payload and pads/truncates > >>> the encrypted payload (multiple of key length) so it appears to > >>> wireshark etc as being just plain regular RTP. > >>> > >>> You will need to committed to adding encryption in H.323 as > >>> implementing H.235.6 is absolutely no simple undertaking and there > >>> is no possible interworking function with SIP other than proxy > >>> decrypt and re-encrypt. For instance we implemented in GnuGk the > >>> H.323 side H.235.6 encrypt/decrypt function so it could sit in > >>> front of the H.323/SIP border controller. > >>> > >>> Simon > >>> > >>> *From:*Robert Jongbloed [mailto:ro...@vo...] > >>> *Sent:* 11 July 2013 09:04 > >>> *To:* Opa...@li... > >>> <mailto:Opa...@li...> > >>> *Subject:* Re: [Opalvoip-devel] H.235.8 - SRTP over H.323 > >>> > >>> So, you are saying the H.323 does not use SRTP at all? > >>> > >>> *Robert Jongbloed* > >>> /OPAL/OpenH323/PTLib Architect and Co-founder./ > >>> Commercial support at http://www.voxlucida.com.au > >>> > >>> On 10/07/2013 9:29 PM, Simon Horne wrote: > >>> > >>> Robert > >>> > >>> Nope. The universally agreed method in H.323 is H.235.6 (with > >>> AES128,256) and this is what is deployed. > >>> > >>> While it was agreed, as I understand, at the time that > >>> SRTP/H.235.8 for better interwork with SIP was going to be the > >>> "way" of the future it just never happened. > >>> > >>> BTW: We agreed at the last ITU meeting to revise H.235.6 to > >>> add 8k and 16k DH key length and more importantly to remove > >>> the restrictive word "voice" out of the title to indicate it > >>> is currently being deployed for both audio and video. > >>> > >>> Simon > >>> > >>> *From:*Robert Jongbloed [mailto:ro...@vo...] > >>> *Sent:* 10 July 2013 18:44 > >>> *To:* Opa...@li... > >>> <mailto:Opa...@li...> > >>> *Subject:* [Opalvoip-devel] H.235.8 - SRTP over H.323 > >>> > >>> Does anyone know of an endpoint that does SRTP over H.323, aka > >>> H.235.8? > >>> > >>> > >>> > >>> -- > >>> > >>> *Robert Jongbloed* > >>> /OPAL/OpenH323/PTLib Architect and Co-founder./ > >>> Commercial support at http://www.voxlucida.com.au > >>> > > > -- Jan Willamowius, ja...@wi..., http://www.gnugk.org/ |
From: Robert J. <ro...@vo...> - 2013-08-15 08:35:22
|
Well, the Codian I was testing against never sent a cipher stealing packet. I am guessing it never does. Will be trying a Tandberg tomorrow (I hope) *Robert Jongbloed* /OPAL/OpenH323/PTLib Architect and Co-founder./ Commercial support at http://www.voxlucida.com.au On 15/08/2013 6:32 PM, Jan Willamowius wrote: > I just removed the check for the padding. It would be even better to > check if the padding is either RFC or "Polycom padding". > > I'm not sure if everyone is doing the wrong padding. I have a faint > memory that I've also seen correct padding, but can't really remember > from which endpoint (Tandberg ?). > > You can also see my attempts at ciphertext stealing for encryption in > the H323Plus code, but that only works with itself and can't be decoded > by big vendor enpoints and thus its curently disabled. It would save a > few bytes on each video packet if we can get that working. > > Regards, > Jan > > Robert Jongbloed wrote: >> Yeah, saw that code, but could not quite figure out what it actually >> did. I am always reluctant to put code in that I at least have a >> rudimentary idea of what it does. >> >> As best I can tell, the only difference between the standard code and >> your code is the bit that is commented out, correct? >> >> And Polycom (and apparently Codian, and possibly everyone ...) do PKCS >> padding when the "pad" bit in RTP is set and cipher stealing when not. >> Correct? >> >> >> Thanks heaps for you help on this. >> >> *Robert Jongbloed* >> /OPAL/OpenH323/PTLib Architect and Co-founder./ >> Commercial support at http://www.voxlucida.com.au >> >> On 14/08/2013 5:18 PM, Jan Willamowius wrote: >>> Hi Robert, >>> >>> I wrote the low-level crypto for H323Plus and I found similar padding >>> issues with Polycom endpoints. I don't think this is documented in the >>> H.235 specs, at least I couldn't find anything, but it seems rather wide >>> spread. >>> >>> Due to the differing padding conventions, you can't use OpenSSL's >>> EVP_DecryptFinal() for an interoperable decode function. I put a >>> substitute with relaxed padding checking into src/h235/h235crypto.cxx. >>> >>> Regards, >>> Jan >>> >>> Robert Jongbloed wrote: >>>> Hi Simon, >>>> while I could not use the actual code, OPAL and H323plus have >>>> diverged too far over the years, it was very instructive looking at the >>>> code. Thanks for doing the hard slog understanding the spec! >>>> >>>> Anyway, I /almost/ have it working. >>>> >>>> I have a question though, regarding RTP padding. The spec I have clearly >>>> states: >>>> >>>> [RTP], section 5.1 describes a method of padding in which the >>>> payload shall be padded to a >>>> multiple of blocks. The last octet shall be set to the number of >>>> padding octets (including the last), >>>> and the P bit set in the RTP header. The value of the pad should be >>>> determined by the normal >>>> convention of the cipher algorithm. >>>> >>>> however, the system I am testing against (Codian MSE4510) equally >>>> clearly does not do this! >>>> >>>> Is there some implementation note or late revision that states that this >>>> is an exception to RFC 3550 padding rules? And if so, how do you >>>> determine how many pad bytes are on the end? >>>> >>>> The reason I ask is because the OPAL code has the RFC 3550 padding >>>> support needed for some other random system. Temporarily disabling that >>>> code makes it work, but with numerous decode errors on both sides, >>>> presumably because of the padding. >>>> >>>> Note, audio is perfect because a 20ms G.711 packet is exactly divisible >>>> by the cipher block size. So, no padding occurs. >>>> >>>> *Robert Jongbloed* >>>> /OPAL/OpenH323/PTLib Architect and Co-founder./ >>>> Commercial support at http://www.voxlucida.com.au >>>> >>>> On 11/07/2013 12:32 PM, Simon Horne wrote: >>>>> Robert >>>>> >>>>> Just to clarify in H.323 the agreed industry standard is H.235.6 with >>>>> 1024 DH Key and AES128 cipher. >>>>> >>>>> You can save your employer some money by grabbing the core RTP H.235.6 >>>>> encryption logic (using OpenSSL) straight out of h323plus. J >>>>> >>>>> But honestly implementing the H.323 signaling side of media encryption >>>>> (H.235.x) is still going to be a nightmare as it touches everything. >>>>> H.225, H.245 (TCS and OLC) . There is DH Key matching/merging in >>>>> H.225, Cipher matching/merging in the H.245 TCS (on every capability!) >>>>> and that is just to generate the actual session key encrypted in the >>>>> OLC/OLCack which is of course different for each RTP/RTCP media stream. >>>>> >>>>> Simon >>>>> >>>>> *From:*Robert Jongbloed [mailto:ro...@vo...] >>>>> *Sent:* 11 July 2013 10:12 >>>>> *To:* Opa...@li... >>>>> *Subject:* Re: [Opalvoip-devel] H.235.8 - SRTP over H.323 >>>>> >>>>> Well, I am committed to doing what my customer pays me to do! :-) >>>>> >>>>> They said they wanted SRTP for H.323, but I will check if that is >>>>> really the case. >>>>> >>>>> *Robert Jongbloed* >>>>> /OPAL/OpenH323/PTLib Architect and Co-founder./ >>>>> Commercial support at http://www.voxlucida.com.au >>>>> >>>>> On 11/07/2013 10:06 AM, Simon Horne wrote: >>>>> >>>>> Robert >>>>> >>>>> Yes that is correct. While H.235.8 is defined there is NO SRTP >>>>> deployed in H.323. H.235.6 is "native" and stenographic meaning it >>>>> uses standard RTP and only encrypts the payload and pads/truncates >>>>> the encrypted payload (multiple of key length) so it appears to >>>>> wireshark etc as being just plain regular RTP. >>>>> >>>>> You will need to committed to adding encryption in H.323 as >>>>> implementing H.235.6 is absolutely no simple undertaking and there >>>>> is no possible interworking function with SIP other than proxy >>>>> decrypt and re-encrypt. For instance we implemented in GnuGk the >>>>> H.323 side H.235.6 encrypt/decrypt function so it could sit in >>>>> front of the H.323/SIP border controller. >>>>> >>>>> Simon >>>>> >>>>> *From:*Robert Jongbloed [mailto:ro...@vo...] >>>>> *Sent:* 11 July 2013 09:04 >>>>> *To:* Opa...@li... >>>>> <mailto:Opa...@li...> >>>>> *Subject:* Re: [Opalvoip-devel] H.235.8 - SRTP over H.323 >>>>> >>>>> So, you are saying the H.323 does not use SRTP at all? >>>>> >>>>> *Robert Jongbloed* >>>>> /OPAL/OpenH323/PTLib Architect and Co-founder./ >>>>> Commercial support at http://www.voxlucida.com.au >>>>> >>>>> On 10/07/2013 9:29 PM, Simon Horne wrote: >>>>> >>>>> Robert >>>>> >>>>> Nope. The universally agreed method in H.323 is H.235.6 (with >>>>> AES128,256) and this is what is deployed. >>>>> >>>>> While it was agreed, as I understand, at the time that >>>>> SRTP/H.235.8 for better interwork with SIP was going to be the >>>>> "way" of the future it just never happened. >>>>> >>>>> BTW: We agreed at the last ITU meeting to revise H.235.6 to >>>>> add 8k and 16k DH key length and more importantly to remove >>>>> the restrictive word "voice" out of the title to indicate it >>>>> is currently being deployed for both audio and video. >>>>> >>>>> Simon >>>>> >>>>> *From:*Robert Jongbloed [mailto:ro...@vo...] >>>>> *Sent:* 10 July 2013 18:44 >>>>> *To:* Opa...@li... >>>>> <mailto:Opa...@li...> >>>>> *Subject:* [Opalvoip-devel] H.235.8 - SRTP over H.323 >>>>> >>>>> Does anyone know of an endpoint that does SRTP over H.323, aka >>>>> H.235.8? >>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> *Robert Jongbloed* >>>>> /OPAL/OpenH323/PTLib Architect and Co-founder./ >>>>> Commercial support at http://www.voxlucida.com.au >>>>> > |
From: Jan W. <ja...@wi...> - 2013-08-15 08:40:05
|
If you implementation does it like the H323Plus code, then decryption of ciphertext stealing should work fine. Is just the encryption that I didn't get to work. But thats an optional item, because the sender gets to choose the padding method. Jan Robert Jongbloed wrote: > Well, the Codian I was testing against never sent a cipher stealing > packet. I am guessing it never does. > > Will be trying a Tandberg tomorrow (I hope) > > *Robert Jongbloed* > /OPAL/OpenH323/PTLib Architect and Co-founder./ > Commercial support at http://www.voxlucida.com.au > > On 15/08/2013 6:32 PM, Jan Willamowius wrote: > > I just removed the check for the padding. It would be even better to > > check if the padding is either RFC or "Polycom padding". > > > > I'm not sure if everyone is doing the wrong padding. I have a faint > > memory that I've also seen correct padding, but can't really remember > > from which endpoint (Tandberg ?). > > > > You can also see my attempts at ciphertext stealing for encryption in > > the H323Plus code, but that only works with itself and can't be decoded > > by big vendor enpoints and thus its curently disabled. It would save a > > few bytes on each video packet if we can get that working. > > > > Regards, > > Jan > > > > Robert Jongbloed wrote: > >> Yeah, saw that code, but could not quite figure out what it actually > >> did. I am always reluctant to put code in that I at least have a > >> rudimentary idea of what it does. > >> > >> As best I can tell, the only difference between the standard code and > >> your code is the bit that is commented out, correct? > >> > >> And Polycom (and apparently Codian, and possibly everyone ...) do PKCS > >> padding when the "pad" bit in RTP is set and cipher stealing when not. > >> Correct? > >> > >> > >> Thanks heaps for you help on this. > >> > >> *Robert Jongbloed* > >> /OPAL/OpenH323/PTLib Architect and Co-founder./ > >> Commercial support at http://www.voxlucida.com.au > >> > >> On 14/08/2013 5:18 PM, Jan Willamowius wrote: > >>> Hi Robert, > >>> > >>> I wrote the low-level crypto for H323Plus and I found similar padding > >>> issues with Polycom endpoints. I don't think this is documented in the > >>> H.235 specs, at least I couldn't find anything, but it seems rather wide > >>> spread. > >>> > >>> Due to the differing padding conventions, you can't use OpenSSL's > >>> EVP_DecryptFinal() for an interoperable decode function. I put a > >>> substitute with relaxed padding checking into src/h235/h235crypto.cxx. > >>> > >>> Regards, > >>> Jan > >>> > >>> Robert Jongbloed wrote: > >>>> Hi Simon, > >>>> while I could not use the actual code, OPAL and H323plus have > >>>> diverged too far over the years, it was very instructive looking at the > >>>> code. Thanks for doing the hard slog understanding the spec! > >>>> > >>>> Anyway, I /almost/ have it working. > >>>> > >>>> I have a question though, regarding RTP padding. The spec I have clearly > >>>> states: > >>>> > >>>> [RTP], section 5.1 describes a method of padding in which the > >>>> payload shall be padded to a > >>>> multiple of blocks. The last octet shall be set to the number of > >>>> padding octets (including the last), > >>>> and the P bit set in the RTP header. The value of the pad should be > >>>> determined by the normal > >>>> convention of the cipher algorithm. > >>>> > >>>> however, the system I am testing against (Codian MSE4510) equally > >>>> clearly does not do this! > >>>> > >>>> Is there some implementation note or late revision that states that this > >>>> is an exception to RFC 3550 padding rules? And if so, how do you > >>>> determine how many pad bytes are on the end? > >>>> > >>>> The reason I ask is because the OPAL code has the RFC 3550 padding > >>>> support needed for some other random system. Temporarily disabling that > >>>> code makes it work, but with numerous decode errors on both sides, > >>>> presumably because of the padding. > >>>> > >>>> Note, audio is perfect because a 20ms G.711 packet is exactly divisible > >>>> by the cipher block size. So, no padding occurs. > >>>> > >>>> *Robert Jongbloed* > >>>> /OPAL/OpenH323/PTLib Architect and Co-founder./ > >>>> Commercial support at http://www.voxlucida.com.au > >>>> > >>>> On 11/07/2013 12:32 PM, Simon Horne wrote: > >>>>> Robert > >>>>> > >>>>> Just to clarify in H.323 the agreed industry standard is H.235.6 with > >>>>> 1024 DH Key and AES128 cipher. > >>>>> > >>>>> You can save your employer some money by grabbing the core RTP H.235.6 > >>>>> encryption logic (using OpenSSL) straight out of h323plus. J > >>>>> > >>>>> But honestly implementing the H.323 signaling side of media encryption > >>>>> (H.235.x) is still going to be a nightmare as it touches everything. > >>>>> H.225, H.245 (TCS and OLC) . There is DH Key matching/merging in > >>>>> H.225, Cipher matching/merging in the H.245 TCS (on every capability!) > >>>>> and that is just to generate the actual session key encrypted in the > >>>>> OLC/OLCack which is of course different for each RTP/RTCP media stream. > >>>>> > >>>>> Simon > >>>>> > >>>>> *From:*Robert Jongbloed [mailto:ro...@vo...] > >>>>> *Sent:* 11 July 2013 10:12 > >>>>> *To:* Opa...@li... > >>>>> *Subject:* Re: [Opalvoip-devel] H.235.8 - SRTP over H.323 > >>>>> > >>>>> Well, I am committed to doing what my customer pays me to do! :-) > >>>>> > >>>>> They said they wanted SRTP for H.323, but I will check if that is > >>>>> really the case. > >>>>> > >>>>> *Robert Jongbloed* > >>>>> /OPAL/OpenH323/PTLib Architect and Co-founder./ > >>>>> Commercial support at http://www.voxlucida.com.au > >>>>> > >>>>> On 11/07/2013 10:06 AM, Simon Horne wrote: > >>>>> > >>>>> Robert > >>>>> > >>>>> Yes that is correct. While H.235.8 is defined there is NO SRTP > >>>>> deployed in H.323. H.235.6 is "native" and stenographic meaning it > >>>>> uses standard RTP and only encrypts the payload and pads/truncates > >>>>> the encrypted payload (multiple of key length) so it appears to > >>>>> wireshark etc as being just plain regular RTP. > >>>>> > >>>>> You will need to committed to adding encryption in H.323 as > >>>>> implementing H.235.6 is absolutely no simple undertaking and there > >>>>> is no possible interworking function with SIP other than proxy > >>>>> decrypt and re-encrypt. For instance we implemented in GnuGk the > >>>>> H.323 side H.235.6 encrypt/decrypt function so it could sit in > >>>>> front of the H.323/SIP border controller. > >>>>> > >>>>> Simon > >>>>> > >>>>> *From:*Robert Jongbloed [mailto:ro...@vo...] > >>>>> *Sent:* 11 July 2013 09:04 > >>>>> *To:* Opa...@li... > >>>>> <mailto:Opa...@li...> > >>>>> *Subject:* Re: [Opalvoip-devel] H.235.8 - SRTP over H.323 > >>>>> > >>>>> So, you are saying the H.323 does not use SRTP at all? > >>>>> > >>>>> *Robert Jongbloed* > >>>>> /OPAL/OpenH323/PTLib Architect and Co-founder./ > >>>>> Commercial support at http://www.voxlucida.com.au > >>>>> > >>>>> On 10/07/2013 9:29 PM, Simon Horne wrote: > >>>>> > >>>>> Robert > >>>>> > >>>>> Nope. The universally agreed method in H.323 is H.235.6 (with > >>>>> AES128,256) and this is what is deployed. > >>>>> > >>>>> While it was agreed, as I understand, at the time that > >>>>> SRTP/H.235.8 for better interwork with SIP was going to be the > >>>>> "way" of the future it just never happened. > >>>>> > >>>>> BTW: We agreed at the last ITU meeting to revise H.235.6 to > >>>>> add 8k and 16k DH key length and more importantly to remove > >>>>> the restrictive word "voice" out of the title to indicate it > >>>>> is currently being deployed for both audio and video. > >>>>> > >>>>> Simon > >>>>> > >>>>> *From:*Robert Jongbloed [mailto:ro...@vo...] > >>>>> *Sent:* 10 July 2013 18:44 > >>>>> *To:* Opa...@li... > >>>>> <mailto:Opa...@li...> > >>>>> *Subject:* [Opalvoip-devel] H.235.8 - SRTP over H.323 > >>>>> > >>>>> Does anyone know of an endpoint that does SRTP over H.323, aka > >>>>> H.235.8? > >>>>> > >>>>> > >>>>> > >>>>> -- > >>>>> > >>>>> *Robert Jongbloed* > >>>>> /OPAL/OpenH323/PTLib Architect and Co-founder./ > >>>>> Commercial support at http://www.voxlucida.com.au > >>>>> > > > -- Jan Willamowius, ja...@wi..., http://www.gnugk.org/ |
From: Robert J. <ro...@vo...> - 2013-08-15 22:50:15
|
Yep, stole that code. Just didn't get to try it as the Codian never sent it. *Robert Jongbloed* /OPAL/OpenH323/PTLib Architect and Co-founder./ Commercial support at http://www.voxlucida.com.au On 15/08/2013 6:39 PM, Jan Willamowius wrote: > If you implementation does it like the H323Plus code, then decryption > of ciphertext stealing should work fine. Is just the encryption that I > didn't get to work. But thats an optional item, because the sender > gets to choose the padding method. > > Jan > > Robert Jongbloed wrote: >> Well, the Codian I was testing against never sent a cipher stealing >> packet. I am guessing it never does. >> >> Will be trying a Tandberg tomorrow (I hope) >> >> *Robert Jongbloed* >> /OPAL/OpenH323/PTLib Architect and Co-founder./ >> Commercial support at http://www.voxlucida.com.au >> >> On 15/08/2013 6:32 PM, Jan Willamowius wrote: >>> I just removed the check for the padding. It would be even better to >>> check if the padding is either RFC or "Polycom padding". >>> >>> I'm not sure if everyone is doing the wrong padding. I have a faint >>> memory that I've also seen correct padding, but can't really remember >>> from which endpoint (Tandberg ?). >>> >>> You can also see my attempts at ciphertext stealing for encryption in >>> the H323Plus code, but that only works with itself and can't be decoded >>> by big vendor enpoints and thus its curently disabled. It would save a >>> few bytes on each video packet if we can get that working. >>> >>> Regards, >>> Jan >>> >>> Robert Jongbloed wrote: >>>> Yeah, saw that code, but could not quite figure out what it actually >>>> did. I am always reluctant to put code in that I at least have a >>>> rudimentary idea of what it does. >>>> >>>> As best I can tell, the only difference between the standard code and >>>> your code is the bit that is commented out, correct? >>>> >>>> And Polycom (and apparently Codian, and possibly everyone ...) do PKCS >>>> padding when the "pad" bit in RTP is set and cipher stealing when not. >>>> Correct? >>>> >>>> >>>> Thanks heaps for you help on this. >>>> >>>> *Robert Jongbloed* >>>> /OPAL/OpenH323/PTLib Architect and Co-founder./ >>>> Commercial support at http://www.voxlucida.com.au >>>> >>>> On 14/08/2013 5:18 PM, Jan Willamowius wrote: >>>>> Hi Robert, >>>>> >>>>> I wrote the low-level crypto for H323Plus and I found similar padding >>>>> issues with Polycom endpoints. I don't think this is documented in the >>>>> H.235 specs, at least I couldn't find anything, but it seems rather wide >>>>> spread. >>>>> >>>>> Due to the differing padding conventions, you can't use OpenSSL's >>>>> EVP_DecryptFinal() for an interoperable decode function. I put a >>>>> substitute with relaxed padding checking into src/h235/h235crypto.cxx. >>>>> >>>>> Regards, >>>>> Jan >>>>> >>>>> Robert Jongbloed wrote: >>>>>> Hi Simon, >>>>>> while I could not use the actual code, OPAL and H323plus have >>>>>> diverged too far over the years, it was very instructive looking at the >>>>>> code. Thanks for doing the hard slog understanding the spec! >>>>>> >>>>>> Anyway, I /almost/ have it working. >>>>>> >>>>>> I have a question though, regarding RTP padding. The spec I have clearly >>>>>> states: >>>>>> >>>>>> [RTP], section 5.1 describes a method of padding in which the >>>>>> payload shall be padded to a >>>>>> multiple of blocks. The last octet shall be set to the number of >>>>>> padding octets (including the last), >>>>>> and the P bit set in the RTP header. The value of the pad should be >>>>>> determined by the normal >>>>>> convention of the cipher algorithm. >>>>>> >>>>>> however, the system I am testing against (Codian MSE4510) equally >>>>>> clearly does not do this! >>>>>> >>>>>> Is there some implementation note or late revision that states that this >>>>>> is an exception to RFC 3550 padding rules? And if so, how do you >>>>>> determine how many pad bytes are on the end? >>>>>> >>>>>> The reason I ask is because the OPAL code has the RFC 3550 padding >>>>>> support needed for some other random system. Temporarily disabling that >>>>>> code makes it work, but with numerous decode errors on both sides, >>>>>> presumably because of the padding. >>>>>> >>>>>> Note, audio is perfect because a 20ms G.711 packet is exactly divisible >>>>>> by the cipher block size. So, no padding occurs. >>>>>> >>>>>> *Robert Jongbloed* >>>>>> /OPAL/OpenH323/PTLib Architect and Co-founder./ >>>>>> Commercial support at http://www.voxlucida.com.au >>>>>> >>>>>> On 11/07/2013 12:32 PM, Simon Horne wrote: >>>>>>> Robert >>>>>>> >>>>>>> Just to clarify in H.323 the agreed industry standard is H.235.6 with >>>>>>> 1024 DH Key and AES128 cipher. >>>>>>> >>>>>>> You can save your employer some money by grabbing the core RTP H.235.6 >>>>>>> encryption logic (using OpenSSL) straight out of h323plus. J >>>>>>> >>>>>>> But honestly implementing the H.323 signaling side of media encryption >>>>>>> (H.235.x) is still going to be a nightmare as it touches everything. >>>>>>> H.225, H.245 (TCS and OLC) . There is DH Key matching/merging in >>>>>>> H.225, Cipher matching/merging in the H.245 TCS (on every capability!) >>>>>>> and that is just to generate the actual session key encrypted in the >>>>>>> OLC/OLCack which is of course different for each RTP/RTCP media stream. >>>>>>> >>>>>>> Simon >>>>>>> >>>>>>> *From:*Robert Jongbloed [mailto:ro...@vo...] >>>>>>> *Sent:* 11 July 2013 10:12 >>>>>>> *To:* Opa...@li... >>>>>>> *Subject:* Re: [Opalvoip-devel] H.235.8 - SRTP over H.323 >>>>>>> >>>>>>> Well, I am committed to doing what my customer pays me to do! :-) >>>>>>> >>>>>>> They said they wanted SRTP for H.323, but I will check if that is >>>>>>> really the case. >>>>>>> >>>>>>> *Robert Jongbloed* >>>>>>> /OPAL/OpenH323/PTLib Architect and Co-founder./ >>>>>>> Commercial support at http://www.voxlucida.com.au >>>>>>> >>>>>>> On 11/07/2013 10:06 AM, Simon Horne wrote: >>>>>>> >>>>>>> Robert >>>>>>> >>>>>>> Yes that is correct. While H.235.8 is defined there is NO SRTP >>>>>>> deployed in H.323. H.235.6 is "native" and stenographic meaning it >>>>>>> uses standard RTP and only encrypts the payload and pads/truncates >>>>>>> the encrypted payload (multiple of key length) so it appears to >>>>>>> wireshark etc as being just plain regular RTP. >>>>>>> >>>>>>> You will need to committed to adding encryption in H.323 as >>>>>>> implementing H.235.6 is absolutely no simple undertaking and there >>>>>>> is no possible interworking function with SIP other than proxy >>>>>>> decrypt and re-encrypt. For instance we implemented in GnuGk the >>>>>>> H.323 side H.235.6 encrypt/decrypt function so it could sit in >>>>>>> front of the H.323/SIP border controller. >>>>>>> >>>>>>> Simon >>>>>>> >>>>>>> *From:*Robert Jongbloed [mailto:ro...@vo...] >>>>>>> *Sent:* 11 July 2013 09:04 >>>>>>> *To:* Opa...@li... >>>>>>> <mailto:Opa...@li...> >>>>>>> *Subject:* Re: [Opalvoip-devel] H.235.8 - SRTP over H.323 >>>>>>> >>>>>>> So, you are saying the H.323 does not use SRTP at all? >>>>>>> >>>>>>> *Robert Jongbloed* >>>>>>> /OPAL/OpenH323/PTLib Architect and Co-founder./ >>>>>>> Commercial support at http://www.voxlucida.com.au >>>>>>> >>>>>>> On 10/07/2013 9:29 PM, Simon Horne wrote: >>>>>>> >>>>>>> Robert >>>>>>> >>>>>>> Nope. The universally agreed method in H.323 is H.235.6 (with >>>>>>> AES128,256) and this is what is deployed. >>>>>>> >>>>>>> While it was agreed, as I understand, at the time that >>>>>>> SRTP/H.235.8 for better interwork with SIP was going to be the >>>>>>> "way" of the future it just never happened. >>>>>>> >>>>>>> BTW: We agreed at the last ITU meeting to revise H.235.6 to >>>>>>> add 8k and 16k DH key length and more importantly to remove >>>>>>> the restrictive word "voice" out of the title to indicate it >>>>>>> is currently being deployed for both audio and video. >>>>>>> >>>>>>> Simon >>>>>>> >>>>>>> *From:*Robert Jongbloed [mailto:ro...@vo...] >>>>>>> *Sent:* 10 July 2013 18:44 >>>>>>> *To:* Opa...@li... >>>>>>> <mailto:Opa...@li...> >>>>>>> *Subject:* [Opalvoip-devel] H.235.8 - SRTP over H.323 >>>>>>> >>>>>>> Does anyone know of an endpoint that does SRTP over H.323, aka >>>>>>> H.235.8? >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> >>>>>>> *Robert Jongbloed* >>>>>>> /OPAL/OpenH323/PTLib Architect and Co-founder./ >>>>>>> Commercial support at http://www.voxlucida.com.au >>>>>>> > |