From e50dedb486fe1c8c2b5b283dc543764cec1f5d6b Mon Sep 17 00:00:00 2001 From: Ian Paterson Date: Fri, 16 Mar 2007 10:32:36 +0000 Subject: [PATCH] 0.15 RC1 clarified how Bob should find the retained retained secret git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@673 4b5297f7-1745-476d-ba37-a9c6900126ab --- xep-0116.xml | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/xep-0116.xml b/xep-0116.xml index a5d9de0f..36da9971 100644 --- a/xep-0116.xml +++ b/xep-0116.xml @@ -74,6 +74,12 @@ &ianpaterson; &stpeter; &dizzyd; + + 0.15 + 2007-03-16 + ip +

Clarified procedure for identification of the shared retained secret

+
0.14 2007-03-15 @@ -673,9 +679,9 @@ -

Bob MUST identify the shared retained secret (SRS) by selecting from his client's list of the secrets it retained from sessions with Alice's clients (the most recent secret for each of the clients she has used to negotiate ESessions with Bob's client).

+

Bob MUST identify the shared retained secret (SRS) by selecting from his client's list of the secrets it retained from previous sessions with Alice's clients (i.e., secrets from sessions where the bareJID was the same as the one Alice is currently using). Note: The list contains the most recent shared secret for each of Alice's clients that she has previously used to negotiate ESessions with the client Bob is currently using.

Bob does this by calculating the HMAC (using HASH and the key &NsubA;) of each secret in the list in turn and comparing it with each of the values in the 'rshashes' field he received from Alice (see Sending Alice's Identity). Once he finds a match, and has confirmed that the secret has not expired (because it is older than an implementation-defined period of time), then he has found the SRS.

-

Note: If Bob cannot find a match, then he SHOULD search through all the retained secrets for all the other JIDs his client has communicated with to try to find a match with one of the values in the 'rshashes' field he received from Alice (since she may simply be using a different JID, perhaps in order to protect her identity).

+

If Bob cannot find a match, then he SHOULD search through all the retained secrets that have not expired for all the other JIDs his client has communicated with to try to find a match with one of the values in the 'rshashes' field he received from Alice (since she may simply be using a different JID, perhaps in order to protect her identity from third parties). Resource-constrained implementations MAY make the performance of this extended search an optional feature.

Bob MUST calculate the final session key by appending to K (the Diffie-Hellman shared secret) the SRS (only if one was found) and then the Other Shared Secret (only if one exists) and then setting K to be the HASH result of the concatenated string of bytes:

K = HASH(K | SRS | OSS)

Bob MUST now use the new value of K to generate the new session keys (&KCsubA;, &KMsubA;, &KCsubB;, &KMsubB; and &KSsubB;) in exactly the same way as he does for 3-message negotiations (see Generating Session Keys). These keys will be used to exchange encrypted stanzas. Note: Bob will still need the value of K in the next section.