From 3e61673a03ac66a338db787de6a0dcab75e66660 Mon Sep 17 00:00:00 2001 From: Ian Paterson Date: Mon, 27 Nov 2006 02:09:58 +0000 Subject: [PATCH] 0.4 RC1 git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@214 4b5297f7-1745-476d-ba37-a9c6900126ab --- xep-0187.xml | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/xep-0187.xml b/xep-0187.xml index 800a79bf..39b1c747 100644 --- a/xep-0187.xml +++ b/xep-0187.xml @@ -80,7 +80,7 @@ 0.3 2006-10-05 ip -

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

 +

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

 0.2 @@ -122,7 +122,7 @@

Note: Alice MAY also publish another similar set of relatively long-lived The more often Alice changes her published ESession options, the shorter the Perfect Forward Secrecy window of vulnerability. However, whenever she changes them she divulges her presence to all the entities that are monitoring them. offline ESession options that any entity MAY use for the same purpose.

-

In order to publish either set of her offline ESession options Alice MUST create an options data form in exactly the same way as she would create an online ESession request data form (see the ESession Request section in Encrypted Session Negotiation) except she MUST omit The 'accept' and 'pk_hash' fields. Note: The list of stanza types she is willing to decrypt MUST NOT include the value 'iq'.

+

In order to publish either set of her offline ESession options Alice MUST create an options data form in exactly the same way as she would create an online ESession request data form (see the ESession Request section in Encrypted Session Negotiation) except she MUST omit The 'accept' and 'pubkey' fields. Note: The list of stanza types she is willing to decrypt MUST NOT include the value 'iq'.

Alice MUST append to the content of the form an 'expires' field containing the UTC time (see &xep0082;) that she decides her offline ESession options will expire (see Options Expiry Time Security Considerations).

Alice MUST store her value of &NsubA; (her ESession ID), all her values of x (one for each MODP group) and the time she decides her offline ESession options will expire in a secure way, so that she can retrieve them when she comes back online (idealy even if that is using a different client and/or a different machine).

If Alice would not be able to decrypt stanzas if she came back online using a different client and/or a different machine then she SHOULD also encapsulate the resource of her client in a 'match_resource' field and append it to her options data form. In this case, the list of stanza types she is willing to decrypt MUST include only 'message'.

@@ -232,7 +232,7 @@ ** Base64 encoded ESession ID ** - + ** Base64 encoded value of e5 ** ** Base64 encoded value of e14 ** ** Base64 encoded value of e2 ** @@ -294,7 +294,7 @@

  1. Diffie-Hellman Preparation (Bob) Note: If the value of e he selected is not valid, Bob SHOULD terminate the ESession without sending an error.

  2. Generating Session Keys

    3. -

  3. Hiding Identity Note: Since Bob did not receive a 'pk_hash' field, he MUST assume its value is false. Bob SHOULD NOT include a 'pk_hash' field in &formB; since Alice has already proved her identity.

    4. +

  4. Hiding Identity Note: Since Bob did not receive a 'pubkey' field, he MUST assume its value is 'key'. Bob SHOULD NOT include a 'pubkey' field in &formB; since Alice has already 'proved' her identity.

As with 3-message ESession negotiation, Bob should encapsulate the Base64 encoded values of &IDB; and &MsubB; in data form fields ('identity' and 'mac'), and append the new fields to &formB;.

Bob MAY also send encrypted content (see the Exchanging Stanzas section of Encrypted Session Negotiation) in the same stanza. Note: If he also includes a field named "terminate" set to a value of "1" or "true" within the data form (see the ESession Termination section of Encrypted Session Negotiation) then the ESession is terminated immediately. This special case, where a single stanza is encrypted and sent in isolation, is equivalent to object encryption (or object signing if no encryption is specified) and offers several significant advantages over non-session approaches - including perfect forward secrecy.

@@ -321,7 +321,7 @@ ** Base64 encoded ESession ID ** - + ** Base64 encoded value of d ** @@ -371,7 +371,7 @@

  • Alice MUST now continue as if Bob had responded to her online ESession request, performing the steps described in two of the sections of Encrypted Session Negotiation:

    • Diffie-Hellman Preparation (Alice) Note: If she is not prepared to support any of the ESession options specified by Bob, or if the value of d she selected is not valid, then Alice SHOULD terminate the ESession without sending an error.

      • -

    • Verifying Bob's Identity Note: Since Alice did not send a 'pk_hash' field to Bob, she MUST assume its value is false. If the value of &MsubB; she calculated does not match the one she received, or if she cannot confirm that &pubKeyB; really is Bob's public key, or if she cannot confirm that &signB; is the signature of the HMAC result, then Alice SHOULD terminate the ESession without sending an error.

      • +

    • Verifying Bob's Identity Note: Since Alice did not send a 'pubkey' field to Bob, she MUST assume its value is 'key'. If the value of &MsubB; she calculated does not match the one she received, or if she cannot confirm that &pubKeyB; really is Bob's public key, or if she cannot confirm that &signB; is the signature of the HMAC result, then Alice SHOULD terminate the ESession without sending an error.

    •