[sip-comm-dev] ZRTP hash generation and XMPP


#1

Hey Werner,

I am currently working on the jingle session negotiation (almost done)
and have just stumbled upon a small issue with ZRTP. According to
XEP-0262, when transported with XMPP, zrtp hash info would look the
following way:

<zrtp-hash version='1.10'>
    fe30efd02423cb054e50efd0248742ac7a52c8f91bc2df881ae642c371ba46df
</zrtp-hash>

(new lines and indentation are there solely for readability)

The thing is that the ZRTP lib, and hence our media service, would
return both the version number and the hash value in a single string.
This form is quite convenient for SDP and less so for jingle.

Do you think we can change that? I see that the status of XEP-0262 is
currently "Deferred" but I think it's quite likely that any new version
would keep the ZRTP version as a separate attribute. Our SIP provider on
the other hand would be perfectly capable of doing the string
concatenation by itself :).

What do you think?
Emil

···

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#2

Hey Werner,

I am currently working on the jingle session negotiation (almost done)
and have just stumbled upon a small issue with ZRTP. According to
XEP-0262, when transported with XMPP, zrtp hash info would look the
following way:

<zrtp-hash version='1.10'>
    fe30efd02423cb054e50efd0248742ac7a52c8f91bc2df881ae642c371ba46df
</zrtp-hash>

(new lines and indentation are there solely for readability)

The thing is that the ZRTP lib, and hence our media service, would
return both the version number and the hash value in a single string.
This form is quite convenient for SDP and less so for jingle.

Do you think we can change that? I see that the status of XEP-0262 is
currently "Deferred" but I think it's quite likely that any new version
would keep the ZRTP version as a separate attribute.

It's "Deferred" because it hasn't been updated in 12+ months and we're
waiting for advancement of the core ZRTP spec at the IETF before moving
forward with XEP-0262.

Our SIP provider on
the other hand would be perfectly capable of doing the string
concatenation by itself :).

I'm not wedded to breaking out the version from the hash value as shown
in that example, but it seems cleaner in XML.

Peter

···

On 7/21/10 11:25 AM, Emil Ivov wrote:

--
Peter Saint-Andre
https://stpeter.im/

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#3

Hi Emil,

the string that is produced by the ZRTP implementation is according
to the ZRTP spec. I wonder about the format taken by XMPP. I would
read the XML tag that the zrtp-hash has version 1.10 and not the
ZRTP protocol version :slight_smile: .

Well, the ZRTP spec is just waiting for another 2 spec it depends on
thus it is very unlikely that the hash string will change inside the
ZRTP spec and I would propose to modify the value between the start/end
tag to hold the full hash string as defined in the ZRTP spec. I
haven't read XEP-0262: is the hash an optional attribute similar to
the way it is inside SDP?

Regards,
Werner

PS: I could implement another call that would return two strings
instead of just one.

Werner

···

Am 21.07.2010 19:25, schrieb Emil Ivov:

Hey Werner,

I am currently working on the jingle session negotiation (almost done)
and have just stumbled upon a small issue with ZRTP. According to
XEP-0262, when transported with XMPP, zrtp hash info would look the
following way:

<zrtp-hash version='1.10'>
    fe30efd02423cb054e50efd0248742ac7a52c8f91bc2df881ae642c371ba46df
</zrtp-hash>

(new lines and indentation are there solely for readability)

The thing is that the ZRTP lib, and hence our media service, would
return both the version number and the hash value in a single string.
This form is quite convenient for SDP and less so for jingle.

Do you think we can change that? I see that the status of XEP-0262 is
currently "Deferred" but I think it's quite likely that any new version
would keep the ZRTP version as a separate attribute. Our SIP provider on
the other hand would be perfectly capable of doing the string
concatenation by itself :).

What do you think?
Emil

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#4

Hey Peter,

На 21.07.10 20:28, Peter Saint-Andre написа:

It's "Deferred" because it hasn't been updated in 12+ months and we're
waiting for advancement of the core ZRTP spec at the IETF before moving
forward with XEP-0262.

Alright, thanks for the explanation!

Another quick question. XEP-0262 shows the zrtp-hash element as being
transported directly inside the <jingle/> extension. Wouldn't it make
more sense to have it inside the <content/> elements?

Here's what the ZRTP spec says:

   The a=zrtp-hash attribute can only be included in the SDP at the
   media level since Hello messages sent in different media streams will
   have unique hashes.

I realize that the situation may have been different when XEP-0262 was
first written but just wanted to confirm whether this is likely to
become the case in future versions.

Cheers,
Emil

···

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#5

Hey Werner,

На 23.07.10 20:25, Werner Dittmann написа:

PS: I could implement another call that would return two strings
instead of just one.

Yeah, I think that would do. I suppose that it would also be nice to
have the same separation for the setters. WDYT?

Cheers,
Emil

···

Werner

Am 21.07.2010 19:25, schrieb Emil Ivov:

Hey Werner,

I am currently working on the jingle session negotiation (almost done)
and have just stumbled upon a small issue with ZRTP. According to
XEP-0262, when transported with XMPP, zrtp hash info would look the
following way:

<zrtp-hash version='1.10'>
    fe30efd02423cb054e50efd0248742ac7a52c8f91bc2df881ae642c371ba46df
</zrtp-hash>

(new lines and indentation are there solely for readability)

The thing is that the ZRTP lib, and hence our media service, would
return both the version number and the hash value in a single string.
This form is quite convenient for SDP and less so for jingle.

Do you think we can change that? I see that the status of XEP-0262 is
currently "Deferred" but I think it's quite likely that any new version
would keep the ZRTP version as a separate attribute. Our SIP provider on
the other hand would be perfectly capable of doing the string
concatenation by itself :).

What do you think?
Emil

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
SIP Communicator
emcho@sip-communicator.org PHONE: +33.1.77.62.43.30
http://sip-communicator.org FAX: +33.1.77.62.47.31

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#6

Emil, that's a good catch. Clearly XEP-0262 needs to be updated. I'll
see if I can squeeze that in during IETF 78 this week.

Peter

- --
Peter Saint-Andre
https://stpeter.im/

···

On 7/25/10 9:57 AM, Emil Ivov wrote:

Hey Peter,

На 21.07.10 20:28, Peter Saint-Andre написа:

It's "Deferred" because it hasn't been updated in 12+ months and we're
waiting for advancement of the core ZRTP spec at the IETF before moving
forward with XEP-0262.

Alright, thanks for the explanation!

Another quick question. XEP-0262 shows the zrtp-hash element as being
transported directly inside the <jingle/> extension. Wouldn't it make
more sense to have it inside the <content/> elements?

Here's what the ZRTP spec says:

   The a=zrtp-hash attribute can only be included in the SDP at the
   media level since Hello messages sent in different media streams will
   have unique hashes.

I realize that the situation may have been different when XEP-0262 was
first written but just wanted to confirm whether this is likely to
become the case in future versions.


#7

Hi Emil,

I can prepare this during the weekend and commit it (the ZRTP lib).

Hey Werner,

�� 23.07.10 20:25, Werner Dittmann ������:

PS: I could implement another call that would return two strings
instead of just one.

Yeah, I think that would do. I suppose that it would also be nice to
have the same separation for the setters. WDYT?

There are no setters - the ZRTP computes the hash during initialization
of ZRTP and is different for each instanziation and the version is fixed
and defines the protocol version.

Regards,
Werner

···

Am 23.07.2010 21:15, schrieb Emil Ivov:

Cheers,
Emil

Werner


#8

На 25.07.10 10:03, Peter Saint-Andre написа:

Emil, that's a good catch. Clearly XEP-0262 needs to be updated. I'll
see if I can squeeze that in during IETF 78 this week.

Thanks!

···

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#9

I'm on a break here, so I took a quick look at this. It's not as easy as
I thought, because Jingle session-info messages are expected to contain
elements qualified by other namespaces, and not a <content/> element
qualified by the 'urn:xmpp:jingle:1' namespace. I suggest that we add a
'content' attribute that corresponds to the name of the relevant
<content/> element (see XEP-0167 for examples).

Thus:

<iq from='romeo@montague.lit/orchard'
    id='vna13b9a'
    from='juliet@capulet.lit/balcony'
    type='set'>
  <jingle xmlns='urn:xmpp:jingle:0'
          action='session-info'
          initiator='romeo@montague.lit/orchard'
          sid='a73sjjvkla37jfea'>
    <zrtp-hash xmlns='urn:xmpp:jingle:apps:rtp:zrtp:0'
               content='webcam'
               ^^^^^^^^^^^^^^^^
               version='1.10'>
fe30efd02423cb054e50efd0248742ac7a52c8f91bc2df881ae642c371ba46df</zrtp-hash>
  </jingle>
</iq>

I'll bring this up on the Jingle list as a sanity check.

Peter

- --
Peter Saint-Andre
https://stpeter.im/

···

On 7/25/10 10:03 AM, Peter Saint-Andre wrote:

On 7/25/10 9:57 AM, Emil Ivov wrote:

Hey Peter,

0 21.07.10 20:28, Peter Saint-Andre =0?8A0:

It's "Deferred" because it hasn't been updated in 12+ months and we're
waiting for advancement of the core ZRTP spec at the IETF before moving
forward with XEP-0262.

Alright, thanks for the explanation!

Another quick question. XEP-0262 shows the zrtp-hash element as being
transported directly inside the <jingle/> extension. Wouldn't it make
more sense to have it inside the <content/> elements?

Here's what the ZRTP spec says:

   The a=zrtp-hash attribute can only be included in the SDP at the
   media level since Hello messages sent in different media streams will
   have unique hashes.

I realize that the situation may have been different when XEP-0262 was
first written but just wanted to confirm whether this is likely to
become the case in future versions.

Emil, that's a good catch. Clearly XEP-0262 needs to be updated. I'll
see if I can squeeze that in during IETF 78 this week.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#10

Hey Werner,

На 24.07.10 09:53, Werner Dittmann написа:

Hi Emil,

I can prepare this during the weekend and commit it (the ZRTP lib).

Hey Werner,

На 23.07.10 20:25, Werner Dittmann написа:

PS: I could implement another call that would return two strings
instead of just one.

Just saw you commit. Thanks! Wouldn't it be easier to have two separate
methods for generating the hash and getting the version? Or is there
something that binds a version number to a specific hash instance?

Cheers,
Emil

···

Am 23.07.2010 21:15, schrieb Emil Ivov:

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#11

На 25.07.10 10:36, Peter Saint-Andre написа:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hey Peter,

0 21.07.10 20:28, Peter Saint-Andre =0?8A0:

It's "Deferred" because it hasn't been updated in 12+ months and we're
waiting for advancement of the core ZRTP spec at the IETF before moving
forward with XEP-0262.

Alright, thanks for the explanation!

Another quick question. XEP-0262 shows the zrtp-hash element as being
transported directly inside the <jingle/> extension. Wouldn't it make
more sense to have it inside the <content/> elements?

Here's what the ZRTP spec says:

   The a=zrtp-hash attribute can only be included in the SDP at the
   media level since Hello messages sent in different media streams will
   have unique hashes.

I realize that the situation may have been different when XEP-0262 was
first written but just wanted to confirm whether this is likely to
become the case in future versions.

Emil, that's a good catch. Clearly XEP-0262 needs to be updated. I'll
see if I can squeeze that in during IETF 78 this week.

I'm on a break here, so I took a quick look at this. It's not as easy as
I thought, because Jingle session-info messages are expected to contain
elements qualified by other namespaces, and not a <content/> element
qualified by the 'urn:xmpp:jingle:1' namespace. I suggest that we add a
'content' attribute that corresponds to the name of the relevant
<content/> element (see XEP-0167 for examples).

Yes, this would probably work. I was initially suggesting something else
though: is there any reason we wouldn't to allow sending the hash inside
the <content/> elements of the 'session-initiate' and 'session-accept' ?

I am not a ZRTP expert but as far as I understand this, the zrtp-hash
only makes sense during session initiation and if the client doesn't
have it by the time it starts sending media, it would simply fall back
to using the RTP negotiation.

Besides, sending hashes upon initiation is the way things happen with
SIP so it would probably make implementation easier for applications
that already have ZRTP support for SIP (like ourselves).

Emil

···

On 7/25/10 10:03 AM, Peter Saint-Andre wrote:

On 7/25/10 9:57 AM, Emil Ivov wrote:

Thus:

<iq from='romeo@montague.lit/orchard'
    id='vna13b9a'
    from='juliet@capulet.lit/balcony'
    type='set'>
  <jingle xmlns='urn:xmpp:jingle:0'
          action='session-info'
          initiator='romeo@montague.lit/orchard'
          sid='a73sjjvkla37jfea'>
    <zrtp-hash xmlns='urn:xmpp:jingle:apps:rtp:zrtp:0'
               content='webcam'
               ^^^^^^^^^^^^^^^^
               version='1.10'>
fe30efd02423cb054e50efd0248742ac7a52c8f91bc2df881ae642c371ba46df</zrtp-hash>
  </jingle>
</iq>

I'll bring this up on the Jingle list as a sanity check.

Peter

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#12

(Resending for both sip-comm-dev and jingle)

На 25.07.10 10:36, Peter Saint-Andre написа:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hey Peter,

0 21.07.10 20:28, Peter Saint-Andre =0?8A0:

It's "Deferred" because it hasn't been updated in 12+ months and we're
waiting for advancement of the core ZRTP spec at the IETF before moving
forward with XEP-0262.

Alright, thanks for the explanation!

Another quick question. XEP-0262 shows the zrtp-hash element as being
transported directly inside the <jingle/> extension. Wouldn't it make
more sense to have it inside the <content/> elements?

Here's what the ZRTP spec says:

   The a=zrtp-hash attribute can only be included in the SDP at the
   media level since Hello messages sent in different media streams will
   have unique hashes.

I realize that the situation may have been different when XEP-0262 was
first written but just wanted to confirm whether this is likely to
become the case in future versions.

Emil, that's a good catch. Clearly XEP-0262 needs to be updated. I'll
see if I can squeeze that in during IETF 78 this week.

I'm on a break here, so I took a quick look at this. It's not as easy as
I thought, because Jingle session-info messages are expected to contain
elements qualified by other namespaces, and not a <content/> element
qualified by the 'urn:xmpp:jingle:1' namespace. I suggest that we add a
'content' attribute that corresponds to the name of the relevant
<content/> element (see XEP-0167 for examples).

Yes, this would probably work. I was initially suggesting something else
though: is there any reason we wouldn't to allow sending the hash inside
the <content/> elements of the 'session-initiate' and 'session-accept' ?

I am not a ZRTP expert but as far as I understand this, the zrtp-hash
only makes sense during session initiation and if the client doesn't
have it by the time it starts sending media, it would simply fall back
to using the RTP negotiation.

Besides, sending hashes upon initiation is the way things happen with
SIP so it would probably make implementation easier for applications
that already have ZRTP support for SIP (like ourselves).

Emil

···

On 7/25/10 10:03 AM, Peter Saint-Andre wrote:

On 7/25/10 9:57 AM, Emil Ivov wrote:

Thus:

<iq from='romeo@montague.lit/orchard'
    id='vna13b9a'
    from='juliet@capulet.lit/balcony'
    type='set'>
  <jingle xmlns='urn:xmpp:jingle:0'
          action='session-info'
          initiator='romeo@montague.lit/orchard'
          sid='a73sjjvkla37jfea'>
    <zrtp-hash xmlns='urn:xmpp:jingle:apps:rtp:zrtp:0'
               content='webcam'
               ^^^^^^^^^^^^^^^^
               version='1.10'>
fe30efd02423cb054e50efd0248742ac7a52c8f91bc2df881ae642c371ba46df</zrtp-hash>
  </jingle>
</iq>

I'll bring this up on the Jingle list as a sanity check.

Peter

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#13

(Resending for both sip-comm-dev and jingle)

На 25.07.10 10:36, Peter Saint-Andre написа:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hey Peter,

0 21.07.10 20:28, Peter Saint-Andre =0?8A0:

It's "Deferred" because it hasn't been updated in 12+ months and we're
waiting for advancement of the core ZRTP spec at the IETF before moving
forward with XEP-0262.

Alright, thanks for the explanation!

Another quick question. XEP-0262 shows the zrtp-hash element as being
transported directly inside the <jingle/> extension. Wouldn't it make
more sense to have it inside the <content/> elements?

Here's what the ZRTP spec says:

   The a=zrtp-hash attribute can only be included in the SDP at the
   media level since Hello messages sent in different media streams will
   have unique hashes.

I realize that the situation may have been different when XEP-0262 was
first written but just wanted to confirm whether this is likely to
become the case in future versions.

Emil, that's a good catch. Clearly XEP-0262 needs to be updated. I'll
see if I can squeeze that in during IETF 78 this week.

I'm on a break here, so I took a quick look at this. It's not as easy as
I thought, because Jingle session-info messages are expected to contain
elements qualified by other namespaces, and not a <content/> element
qualified by the 'urn:xmpp:jingle:1' namespace. I suggest that we add a
'content' attribute that corresponds to the name of the relevant
<content/> element (see XEP-0167 for examples).

Yes, this would probably work. I was initially suggesting something else
though: is there any reason we wouldn't to allow sending the hash inside
the <content/> elements of the 'session-initiate' and 'session-accept' ?

Aha, I missed that suggestion.

That seems to be consistent with the ZRTP draft:

   To support best effort encryption from the Media Security
   Requirements [RFC5479], ZRTP uses normal RTP/AVP profile (AVP) media
   lines in the initial offer/answer exchange.

I am not a ZRTP expert but as far as I understand this, the zrtp-hash
only makes sense during session initiation and if the client doesn't
have it by the time it starts sending media, it would simply fall back
to using the RTP negotiation.

Besides, sending hashes upon initiation is the way things happen with
SIP so it would probably make implementation easier for applications
that already have ZRTP support for SIP (like ourselves).

So it seems. Let me take a bit of time to look at the ZRTP draft again
with XEP-0262 in mind, but I think you're right that we need to include
this information in the Jingle invite ( = "offer").

Peter

···

On 7/25/10 11:15 AM, Emil Ivov wrote:

On 7/25/10 10:03 AM, Peter Saint-Andre wrote:

On 7/25/10 9:57 AM, Emil Ivov wrote:

--
Peter Saint-Andre
https://stpeter.im/


#14

Emil, Peter,

some short answers to some of the e-mails exchanged:

- the normal getHelloHash method delivers a string that is in
  accordance to the ZRTP specification chapter 8

The meaning and the use of the Hello hash is manifold:

- if a user has Zfone (Phil's implementation which is a Bump-in-the-wire)
  installed then Zfone is able to check the SDP parameter and can determine
  that the client that sends the SIP INVITE support ZRTP natively and
  then ZFone does not start its own ZRTP negotiation. Thus SC and Zfone
  can be used and installed on the same system. Another user of the
  system may use another SIP Client (Zfone may be started as a service on
  Windows systems and thus always runs). Of course this works only if
  you don't use SIPS

- another topic is end-to-end security without reading the SAS strings. This
  works only if you have an integrity protected end-to-end SIP connection
  (chapter 8.1.1) - it's somewhat complex but in some cases this allows for
  "unmaned" operation.

- A ZRTP implementation may use the Hello hash contained in the signaling part
  and compare it with a generated hash during the ZRTP negotiation. This is
  an additional feature to check if somebody tampered the SIP/SDP data during
  transfer. In this case the ZRTP implementation can issue a warning and
  a check of SAS should be performed (this check is not implemented in SC)

- In any case Hello hash is only an optional feature to support security but
  it usually does not influence the normal ZRTP negotiation via the media
  connection (maybe only in case on "unmaned" operation).

Regards,
Werner

···

Am 25.07.2010 10:55, schrieb Emil Ivov:

На 25.07.10 10:36, Peter Saint-Andre написа:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 7/25/10 10:03 AM, Peter Saint-Andre wrote:

On 7/25/10 9:57 AM, Emil Ivov wrote:

Hey Peter,

0 21.07.10 20:28, Peter Saint-Andre =0?8A0:

It's "Deferred" because it hasn't been updated in 12+ months and we're
waiting for advancement of the core ZRTP spec at the IETF before moving
forward with XEP-0262.

Alright, thanks for the explanation!

Another quick question. XEP-0262 shows the zrtp-hash element as being
transported directly inside the <jingle/> extension. Wouldn't it make
more sense to have it inside the <content/> elements?

Here's what the ZRTP spec says:

   The a=zrtp-hash attribute can only be included in the SDP at the
   media level since Hello messages sent in different media streams will
   have unique hashes.

I realize that the situation may have been different when XEP-0262 was
first written but just wanted to confirm whether this is likely to
become the case in future versions.

Emil, that's a good catch. Clearly XEP-0262 needs to be updated. I'll
see if I can squeeze that in during IETF 78 this week.

I'm on a break here, so I took a quick look at this. It's not as easy as
I thought, because Jingle session-info messages are expected to contain
elements qualified by other namespaces, and not a <content/> element
qualified by the 'urn:xmpp:jingle:1' namespace. I suggest that we add a
'content' attribute that corresponds to the name of the relevant
<content/> element (see XEP-0167 for examples).

Yes, this would probably work. I was initially suggesting something else
though: is there any reason we wouldn't to allow sending the hash inside
the <content/> elements of the 'session-initiate' and 'session-accept' ?

I am not a ZRTP expert but as far as I understand this, the zrtp-hash
only makes sense during session initiation and if the client doesn't
have it by the time it starts sending media, it would simply fall back
to using the RTP negotiation.

Besides, sending hashes upon initiation is the way things happen with
SIP so it would probably make implementation easier for applications
that already have ZRTP support for SIP (like ourselves).

Emil

Thus:

<iq from='romeo@montague.lit/orchard'
    id='vna13b9a'
    from='juliet@capulet.lit/balcony'
    type='set'>
  <jingle xmlns='urn:xmpp:jingle:0'
          action='session-info'
          initiator='romeo@montague.lit/orchard'
          sid='a73sjjvkla37jfea'>
    <zrtp-hash xmlns='urn:xmpp:jingle:apps:rtp:zrtp:0'
               content='webcam'
               ^^^^^^^^^^^^^^^^
               version='1.10'>
fe30efd02423cb054e50efd0248742ac7a52c8f91bc2df881ae642c371ba46df</zrtp-hash>
  </jingle>
</iq>

I'll bring this up on the Jingle list as a sanity check.

Peter

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#15

The ABNF is:

       zrtp-attribute = "a=zrtp-hash:" zrtp-version zrtp-hash-value

       zrtp-version = token

       zrtp-hash-value = 1*(HEXDIG)

I suppose that in Jingle we could communicated the zrtp-attribute, not
the zrtp-hash-value...

Peter

- --
Peter Saint-Andre
https://stpeter.im/

···

On 7/25/10 11:45 AM, Werner Dittmann wrote:

Emil, Peter,

some short answers to some of the e-mails exchanged:

- the normal getHelloHash method delivers a string that is in
  accordance to the ZRTP specification chapter 8

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#16

(Resending for both sip-comm-dev and jingle)

...

Yes, this would probably work. I was initially suggesting something else
though: is there any reason we wouldn't to allow sending the hash inside
the <content/> elements of the 'session-initiate' and 'session-accept' ?

Aha, I missed that suggestion.

That seems to be consistent with the ZRTP draft:

   To support best effort encryption from the Media Security
   Requirements [RFC5479], ZRTP uses normal RTP/AVP profile (AVP) media
   lines in the initial offer/answer exchange.

Yes, the Hello hash is an extension to the RTP/AVP media lines, IMHO already
registered.

I am not a ZRTP expert but as far as I understand this, the zrtp-hash
only makes sense during session initiation and if the client doesn't
have it by the time it starts sending media, it would simply fall back
to using the RTP negotiation.

Besides, sending hashes upon initiation is the way things happen with
SIP so it would probably make implementation easier for applications
that already have ZRTP support for SIP (like ourselves).

So it seems. Let me take a bit of time to look at the ZRTP draft again
with XEP-0262 in mind, but I think you're right that we need to include
this information in the Jingle invite ( = "offer").

Peter, this was my idea as well when I first saw how Jingle sets up its
"invite" some time ago.

···

Am 25.07.2010 11:34, schrieb Peter Saint-Andre:

On 7/25/10 11:15 AM, Emil Ivov wrote:

Peter

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#17

Emil, Peter,

Hey Peter,

--sent from my mobile

[Written while in flight; delivery will be delayed.]

Emil (or anyone else), do you know if the zrtp-hash is also sent in the
SDP answer? I can't find anything about that in the ZRTP spec, which is
embarrassing because I reviewed it for the IESG ballot. I'll need to ping the spec authors for answers.

Well, I used to think it went both ways but they seem to only travel in the offers.

Werner is the ZRTP expert on our side, Werner, could you please correct me if I am wrong?

actually the hrtp-hash attribute is usually on both ways, in the offer and
the answer. However, zrtp-hash is an optional SDP attribute anyhow.

If an application really uses it in a way described in the spec then both
applications need to know the zrtp-hash of the other party.

Regards,
Werner

···

Am 04.08.2010 16:02, schrieb Emil Ivov:

On 3 août 2010, at 12:54, Peter Saint-Andre <stpeter@stpeter.im> wrote:

Cheers
Emil

Peter

--
Peter Saint-Andre
https://stpeter.im/

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#18

Hi Werner,

one more question :slight_smile: what about when we receive the initial offer do
we have to send it in the answer. Or when we see that other party is
not sending us the zrtp-hash so we skip it in our answer.

Cheers
damencho

···

On Thu, Aug 5, 2010 at 7:41 PM, Werner Dittmann <Werner.Dittmann@t-online.de> wrote:

Emil, Peter,

Am 04.08.2010 16:02, schrieb Emil Ivov:

Hey Peter,

--sent from my mobile

On 3 août 2010, at 12:54, Peter Saint-Andre <stpeter@stpeter.im> wrote:

[Written while in flight; delivery will be delayed.]

Emil (or anyone else), do you know if the zrtp-hash is also sent in the
SDP answer? I can't find anything about that in the ZRTP spec, which is
embarrassing because I reviewed it for the IESG ballot. I'll need to ping the spec authors for answers.

Well, I used to think it went both ways but they seem to only travel in the offers.

Werner is the ZRTP expert on our side, Werner, could you please correct me if I am wrong?

actually the hrtp-hash attribute is usually on both ways, in the offer and
the answer. However, zrtp-hash is an optional SDP attribute anyhow.

If an application really uses it in a way described in the spec then both
applications need to know the zrtp-hash of the other party.

Regards,
Werner

Cheers
Emil

Peter

--
Peter Saint-Andre
https://stpeter.im/

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#19

Hi Damencho,

no - that's not necessary. We use ZRTP hash only to signal in SIP/SDP
that SC implements ZRTP and will not use Phil's Zfone if this is also
installed and running on the same system.

Sometimes it is necessary to switch off (it's configurable) the inclusion
of the ZRTP hash into SIP/SDP because some packet gateways in mobile
networks filter out SIP/SDP packet if they contain unknown SDP parameters.

Regards,
Werner

···

Am 10.08.2010 13:17, schrieb Damian Minkov:

Hi Werner,

one more question :slight_smile: what about when we receive the initial offer do
we have to send it in the answer. Or when we see that other party is
not sending us the zrtp-hash so we skip it in our answer.

Cheers
damencho

On Thu, Aug 5, 2010 at 7:41 PM, Werner Dittmann > <Werner.Dittmann@t-online.de> wrote:

Emil, Peter,

Am 04.08.2010 16:02, schrieb Emil Ivov:

Hey Peter,

--sent from my mobile

On 3 ao�t 2010, at 12:54, Peter Saint-Andre <stpeter@stpeter.im> wrote:

[Written while in flight; delivery will be delayed.]

Emil (or anyone else), do you know if the zrtp-hash is also sent in the
SDP answer? I can't find anything about that in the ZRTP spec, which is
embarrassing because I reviewed it for the IESG ballot. I'll need to ping the spec authors for answers.

Well, I used to think it went both ways but they seem to only travel in the offers.

Werner is the ZRTP expert on our side, Werner, could you please correct me if I am wrong?

actually the hrtp-hash attribute is usually on both ways, in the offer and
the answer. However, zrtp-hash is an optional SDP attribute anyhow.

If an application really uses it in a way described in the spec then both
applications need to know the zrtp-hash of the other party.

Regards,
Werner

Cheers
Emil

Peter

--
Peter Saint-Andre
https://stpeter.im/

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net