From 439f8a54b60cb708f100ccee998b14377473142e Mon Sep 17 00:00:00 2001 From: Ian Paterson Date: Thu, 5 Oct 2006 19:13:50 +0000 Subject: [PATCH] 0.12 RC1 security field, updated otr field git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@78 4b5297f7-1745-476d-ba37-a9c6900126ab --- xep-0116.xml | 129 +++++++++++++++++++++++++++------------------------ 1 file changed, 69 insertions(+), 60 deletions(-) diff --git a/xep-0116.xml b/xep-0116.xml index ebc99990..04dafe24 100644 --- a/xep-0116.xml +++ b/xep-0116.xml @@ -69,6 +69,12 @@ &ianpaterson; &stpeter; &dizzyd; + + 0.12 + 2006-10-05 + ip +

Replaced secure field with security field; changed otr field to list-single

 + 0.11 2006-10-02 @@ -186,7 +192,7 @@

Note: If Alice believes Bob is offline then she SHOULD NOT use this negotiation protocol. However, she MAY use the protocol specified in Offline Encrypted Sessions to establish the ESession options and keys. Alternatively, she MAY send stanzas without encryption - in which case her client MUST make absolutely clear to her that the stanzas will not be protected and give her the option not to send the stanzas.

Note: In any case, Alice MUST NOT initiate a new ESession with Bob if she already has one established with him.

-

In addition to the "accept", "otr" and "secure" fields specified in Chat Session Negotiation, Alice MUST send to Bob each of the ESession options (see list below) that she is willing to use, in her order of preference (see Mandatory to Implement Technologies). Note: Alice SHOULD NOT include a "reason" field since Aunt Tillie may not be aware the ESession request is not encrypted.

+

In addition to the "accept", "otr" and "security" fields specified in Chat Session Negotiation, Alice MUST send to Bob each of the ESession options (see list below) that she is willing to use, in her order of preference (see Mandatory to Implement Technologies). Note: Alice SHOULD NOT include a "reason" field since Aunt Tillie may not be aware the ESession request is not encrypted.

  1. The list of Modular Exponential (MODP) group numbers (as specified in &rfc2409; or &rfc3526;) that MAY be used for Diffie-Hellman key exchange (valid group numbers include 1,2,3,4,5,14,15,16,17 and 18)

  2. Symmetric block cipher algorithm names

    3. @@ -214,11 +220,14 @@ 1 - - 0 + + + - - 0 + + + + @@ -271,7 +280,8 @@ ]]> -

    If Bob does not support one or more of the options in each ESession field, then he SHOULD return a &feature; error (but he MAY return no error if, for example, he does not want to reveal his presence to Alice for whatever reason):

    +

    If Bob does not want to reveal presence to Alice for whatever reason then Bob SHOULD return no response or error.

    +

    If Bob supports none of the options for one or more ESession fields, then he SHOULD return a ¬acceptable; error and SHOULD specify the field(s) with unsupported options in a comma-separated list in the XMPP <text/> element:

    - - + + modp,ver ]]>

    Either Bob or Alice MAY attempt to initiate a new ESession after any error during the negotiation process. However, both MUST consider the previous negotiation to have failed and MUST discard any information learned through the previous negotiation.

    -

    If Bob is unwilling to start an ESession, but he is ready to initiate a one-to-one chat session with Alice (see Chat Session Negotiation), then he SHOULD accept the Chat Session and terminate the ESession negotiation by not including a 'nonce' field in his response.

    +

    If Bob is unwilling to start an ESession, but he is ready to initiate a one-to-one chat session with Alice (see Chat Session Negotiation), and if Alice included an option for the "security" field with the value "none" or "c2s", then Bob SHOULD accept the Chat Session and terminate the ESession negotiation by specifying "none" or "c2s" for the value of the "security" field in his response.

    @@ -295,8 +305,8 @@ http://jabber.org/protocol/chatneg     1 - 1 - 0 + true + c2s @@ -364,8 +374,8 @@ http://jabber.org/protocol/chatneg     1 - 1 - 0 + true + e2e 5 aes256-ctr sha256 @@ -400,8 +410,8 @@ http://jabber.org/protocol/chatneg     1 - 1 - 0 + true + e2e 5 aes256-ctr sha256 @@ -762,7 +772,7 @@

    Alice and Bob MUST ensure that the value of e or d they provide when negotiating each online ESession is unique. This prevents complete online ESessions being replayed.

    -

    Organisations with full disclosure policies may require entities to disable encryption to enable the logging of all messages on their server. Unencrypted ESessions meet all the Security Requirements except for Confidentiality. Unencrypted ESessions enable Alice to to confirm securely with Bob that both client-server connections are secure. i.e. that the value of the 'secure' option (as specified in Chat Session Negotiation) has not been tampered with.

    +

    Organisations with full disclosure policies may require entities to disable encryption to enable the logging of all messages on their server. Unencrypted ESessions meet all the Security Requirements except for Confidentiality. Unencrypted ESessions enable Alice to to confirm securely with Bob that both client-server connections are secure. i.e. that the value of the 'security' option (as specified in Chat Session Negotiation) has not been tampered with.

    If either entity stores a (re-encrypted) transcript of an ESession for future consultation then the Perfect Forward Secrecy offered by this protocol is lost. If the negotiated value of the 'otr' Chat Session Negotiation field is 'true' the entities SHOULD NOT store any part of the ESession content (not even in encrypted form).

    @@ -853,7 +863,6 @@
    • http://jabber.org/protocol/esession
    • http://jabber.org/protocol/esession#init
      • -
    • http://jabber.org/protocol/esession#error
     @@ -863,6 +872,30 @@ http://jabber.org/protocol/esession XEP-0116 ESession negotiation forms + + + + + + - - - - - - - - - - + var='pk_hash' + type='boolean' + label='Respond with public key fingerprint'/> + + + +