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:
(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 :).
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:
(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.
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 .
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:
(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 :).
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.
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:
(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 :).
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.
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.
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).
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 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?
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).
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).
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").
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).
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.
[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:
one more question 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.
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.
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 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.
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.
.
what about when we receive the initial offer do