moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-12-22 07:38:52 -05:00
Code Issues Releases Wiki Activity

0.17

Browse Source 
git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@2980 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Peter Saint-Andre 2009-04-05 02:00:44 +00:00
parent 0986764ea2
commit ce54970dd1
1 changed files with 6 additions and 8 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

14
xep-0177.xml
View File

@ -27,6 +27,12 @@
&scottlu; &scottlu;
&hildjj; &hildjj;
&seanegan; &seanegan;
<revision>
<version>0.17</version>
<date>2009-04-04</date>
<initials>psa</initials>
<remark><p>Removed security consideration about sending IP address before session acceptance, since that functionality is no longer supported.</p></remark>
</revision>
<revision> <revision>
<version>0.16</version> <version>0.16</version>
<date>2009-03-09</date> <date>2009-03-09</date>
@ -334,14 +340,6 @@ INITIATOR RESPONDER
</section1> </section1>
<section1 topic='Security Considerations' anchor='security'> <section1 topic='Security Considerations' anchor='security'>
<section2 topic='Sharing IP Addresses' anchor='security-sharing'>
<p>By definition, the exchange of transport candidates results in exposure of the sender's IP addresses, which comprise a form of personally identifying information. A Jingle client MUST enable a user to control which entities will be allowed to receive such information. If a human user explicitly accepts a session request, then the client SHOULD consider that action to imply approval of IP address sharing. However, waiting for a human user to explicitly accept the session request can result in delays during session setup, since it is more efficient to immediately begin sharing transport candidates. Therefore, it is RECOMMENDED for the client to immediately send transport candidates to a contact (without waiting for explicit user approval of the session request) in the following cases:</p>
<ol>
<li>The user has permanently and formally authorized the contact to view the user's presence information via a presence subscription as reflected in an XMPP roster item (see &xmppim;).</li>
<li>The user has temporarily and dynamically shared presence with the contact via "directed presence" as described in <cite>RFC 3921</cite>.</li>
<li>The user has explicitly added the contact to a "whitelist" of entities who are allowed to access the user's personally-identifying information.</li>
</ol>
</section2>
<section2 topic='Encryption of Media' anchor='security-media'> <section2 topic='Encryption of Media' anchor='security-media'>
<p>A Jingle implementation SHOULD support security preconditions that are enforced before application media is allowed to flow over a UDP association, such as those described in &xtls;.</p> <p>A Jingle implementation SHOULD support security preconditions that are enforced before application media is allowed to flow over a UDP association, such as those described in &xtls;.</p>
<p>Application types that use the Jingle Raw UDP transport method MAY also define their own application-specific encryption methods, such as the Secure Real-time Transport Protocol (SRTP) for RTP exchanges as described in &xep0167;.</p> <p>Application types that use the Jingle Raw UDP transport method MAY also define their own application-specific encryption methods, such as the Secure Real-time Transport Protocol (SRTP) for RTP exchanges as described in &xep0167;.</p>