otr.diff

5c5
< <title>Off-the-Record Messaging Protocol version 2 - DRAFT</title>
---
> <title>Off-the-Record Messaging Protocol version 3 - DRAFT</title>
13,24c13,25
< <h1>Off-the-Record Messaging Protocol version 2</h1>
< <p>This document describes version 2 of the Off-the-Record Messaging
< protocol.  The main changes over version 1 include:</p>
< <ul>
< <li>Resolving the identity-binding flaw identified by Di Raimondo,
< Gennaro, and Krawczyk</li>
< <li>Not revealing the users' public keys to passive eavesdroppers; this
< could be useful if the application sending the OTR messages is also
< privacy-preserving</li>
< <li>Supporting fragmentation of OTR messages, to support IM networks
< whose maximum message size is very small.</li>
< <li>Better protocol version control, for future extensibility.</li>
---
> <h1>Off-the-Record Messaging Protocol version 3</h1>
> <p>This document describes version 3 of the Off-the-Record Messaging
> protocol.  The main changes over version 2 include:</p>
> <ul>
> <li>Both fragmented and unfragmented messages contain sender and
> recipient instance tags. This avoids an issue on IM networks that
> always relay all messages to all sessions of a client who is logged
> in multiple times. In this situation, OTR clients can attempt to
> establish an OTR session indefinitely if there are interleaving
> messages from each of the sessions.</li>
> <li>An extra symmetric key is derived during AKE. This may be used for
> secure communication over a different channel (e.g., file transfer,
> voice chat).</li>
38c39
< Version 2 of OTR uses a variant of the SIGMA protocol as its AKE.</li>
---
> Versions 2 and 3 of OTR use a variant of the SIGMA protocol as its AKE.</li>
181c182
< AES-CTR<sub>ek,ctr</sub>(T<sub>A</sub>).</li>
---
> AES-CTR<sub>ek,ctr</sub>(msg).</li>
184a186,253
> <h3>Socialist Millionaires' Protocol (SMP)</h3>
> <p>While data messages are being exchanged, either Alice or Bob may
> run SMP to detect impersonation or man-in-the-middle attacks.
> As above, all exponentiations are done modulo a particular 1536-bit
> prime, and g<sub>1</sub> is a generator of that group.  All sent values
> include zero-knowledge proofs that they were generated according to
> this protocol, as indicated in the detailed description below.</p>
> <p>Suppose Alice and Bob have secret information x and y respectively,
> and they wish to know whether x = y.  The Socialist Millionaires' Protocol
> allows them to compare x and y without revealing any other information
> than the value of (x == y).  For OTR, the secrets contain
> information about both parties' long-term authentication public keys,
> as well as information entered by the users themselves.  If x = y,
> this means that Alice and Bob entered the same secret information, and
> so must be the same entities who established that secret to begin with.</p>
> <p>Assuming that Alice begins the exchange:</p>
> <ul>
> <li>Alice:
> <ol>
> <li>Picks random exponents a<sub>2</sub> and a<sub>3</sub></li>
> <li>Sends Bob g<sub>2a</sub> = g<sub>1</sub><sup>a<sub>2</sub></sup> and
> g<sub>3a</sub> = g<sub>1</sub><sup>a<sub>3</sub></sup></li>
> </ol></li>
> <li>Bob:
> <ol>
> <li>Picks random exponents b<sub>2</sub> and b<sub>3</sub></li>
> <li>Computes g<sub>2b</sub> = g<sub>1</sub><sup>b<sub>2</sub></sup> and
> g<sub>3b</sub> = g<sub>1</sub><sup>b<sub>3</sub></sup></li>
> <li>Computes g<sub>2</sub> = g<sub>2a</sub><sup>b<sub>2</sub></sup> and
> g<sub>3</sub> = g<sub>3a</sub><sup>b<sub>3</sub></sup></li>
> <li>Picks random exponent r</li>
> <li>Computes P<sub>b</sub> = g<sub>3</sub><sup>r</sup> and
> Q<sub>b</sub> = g<sub>1</sub><sup>r</sup> g<sub>2</sub><sup>y</sup></li>
> <li>Sends Alice g<sub>2b</sub>, g<sub>3b</sub>, P<sub>b</sub> and
> Q<sub>b</sub></li>
> </ol></li>
> <li>Alice:
> <ol>
> <li>Computes g<sub>2</sub> = g<sub>2b</sub><sup>a<sub>2</sub></sup> and
> g<sub>3</sub> = g<sub>3b</sub><sup>a<sub>3</sub></sup></li>
> <li>Picks random exponent s</li>
> <li>Computes P<sub>a</sub> = g<sub>3</sub><sup>s</sup> and
> Q<sub>a</sub> = g<sub>1</sub><sup>s</sup> g<sub>2</sub><sup>x</sup></li>
> <li>Computes R<sub>a</sub> = (Q<sub>a</sub> / Q<sub>b</sub>)
> <sup>a<sub>3</sub></sup></li>
> <li>Sends Bob P<sub>a</sub>, Q<sub>a</sub> and R<sub>a</sub></li>
> </ol></li>
> <li>Bob:
> <ol>
> <li>Computes R<sub>b</sub> = (Q<sub>a</sub> / Q<sub>b</sub>)
> <sup>b<sub>3</sub></sup></li>
> <li>Computes R<sub>ab</sub> = R<sub>a</sub><sup>b<sub>3</sub></sup></li>
> <li>Checks whether R<sub>ab</sub> == (P<sub>a</sub> / P<sub>b</sub>)</li>
> <li>Sends Alice R<sub>b</sub></li>
> </ol></li>
> <li>Alice:
> <ol>
> <li>Computes R<sub>ab</sub> = R<sub>b</sub><sup>a<sub>3</sub></sup></li>
> <li>Checks whether R<sub>ab</sub> == (P<sub>a</sub> / P<sub>b</sub>)</li>
> </ol></li>
> <li>If everything is done correctly, then R<sub>ab</sub> should hold the
> value of (P<sub>a</sub> / P<sub>b</sub>) times
> (g<sub>2</sub><sup>a<sub>3</sub>b<sub>3</sub></sup>)<sup>(x - y)</sup>, which means that the test at the end of
> the protocol will only succeed if x == y. Further, since
> g<sub>2</sub><sup>a<sub>3</sub>b<sub>3</sub></sup> is a random number
> not known to any party, if x is not equal to y, no other information is
> revealed.</li>
> </ul>
199,201c268,270
< The byte identifier for OTR version 2 is "2".  The order of the
< identifiers between the "v" and the "?" does not matter, but none should
< be listed more than once.</li>
---
> The byte identifier for OTR version 2 is "2", and similarly for 3.  The
> order of the identifiers between the "v" and the "?" does not matter,
> but none should be listed more than once.</li>
208a278,279
> <dt>"?OTRv23?"</dt>
> <dd>Versions 2 and 3</dd>
244a316,317
> <li>"\x20\x20\x09\x09\x20\x20\x09\x09" to indicate a willingness to use
> OTR version 3 with Bob</li>
319c392,393
< <dd>      (len is the length of the DSA public parameter q)
---
> <dd>      (len is the length of the DSA public parameter q, which in
> current implementations must be 20 bytes, or 160 bits)
331a406,427
> <h4>Instance Tags</h4>
> <p>Clients include instance tags in all OTR version 3 messages. Instance
> tags are 32-bit values that are intended to be persistent. If the same
> client is logged into the same account from multiple locations, the
> intention is that the client will have different instance tags at each
> location. As shown below, OTR version 3 messages (fragmented and
> unfragmented) include the source and destination instance tags. If a client
> receives a message that lists a destination instance tag different from its
> own, the client should discard the message.</p>
> <p>The smallest valid instance tag is 0x00000100. It is appropriate to set the
> destination instance tag to '0' when an actual destination instance tag is
> not known at the time the message is prepared. If a client receives a
> message with the sender instance tag set to less than 0x00000100, it should
> discard the message. Similarly, if a client receives a message with the
> recipient instance tag set to greater than 0 but less than 0x00000100, it
> should discard the message.
> </p>
> 
> <p>This avoids an issue on IM networks that always relay all messages to
> all sessions of a client who is logged in multiple times. In this
> situation, OTR clients can attempt to establish an OTR session indefinitely
> if there are interleaving messages from each of the sessions.</p>
340c436
< <dd>The version number of this protocol is 0x0002.</dd>
---
> <dd>The version number of this protocol is 0x0003.</dd>
342a439,444
> <dt>Sender Instance tag (INT)</dt>
> <dd>The instance tag of the person sending this message.</dd>
> <dt>Receiver Instance tag (INT)</dt>
> <dd>The instance tag of the intended recipient.
> For a commit message this will often be 0, since the other party
> may not have identified their instance tag yet.</dd>
355c457
< <dd>This is the SHA-256 hash of gxmpi.</dd>
---
> <dd>This is the SHA256 hash of gxmpi.</dd>
362c464
< <dd>The version number of this protocol is 0x0002.</dd>
---
> <dd>The version number of this protocol is 0x0003.</dd>
364a467,470
> <dt>Sender Instance tag (INT)</dt>
> <dd>The instance tag of the person sending this message.</dd>
> <dt>Receiver Instance tag (INT)</dt>
> <dd>The instance tag of the intended recipient.</dd>
377c483
< <dd>The version number of this protocol is 0x0002.</dd>
---
> <dd>The version number of this protocol is 0x0003.</dd>
379a486,489
> <dt>Sender Instance tag (INT)</dt>
> <dd>The instance tag of the person sending this message.</dd>
> <dt>Receiver Instance tag (INT)</dt>
> <dd>The instance tag of the intended recipient.</dd>
418c528
< <dd>The version number of this protocol is 0x0002.</dd>
---
> <dd>The version number of this protocol is 0x0003.</dd>
420a531,534
> <dt>Sender Instance tag (INT)</dt>
> <dd>The instance tag of the person sending this message.</dd>
> <dt>Receiver Instance tag (INT)</dt>
> <dd>The instance tag of the intended recipient.</dd>
493a608,637
> <dt>Type 2: SMP Message 1</dt>
> <dd>The value represents an initiating message of the Socialist
> Millionaires' Protocol, described below.</dd>
> <dt>Type 3: SMP Message 2</dt>
> <dd>The value represents the second message in an instance of SMP.</dd>
> <dt>Type 4: SMP Message 3</dt>
> <dd>The value represents the third message in an instance of SMP.</dd>
> <dt>Type 5: SMP Message 4</dt>
> <dd>The value represents the final message in an instance of SMP.</dd>
> <dt>Type 6: SMP Abort Message</dt>
> <dd>If the user cancels SMP prematurely or encounters an error in the
> protocol and cannot continue, you may send a message (possibly with empty
> human-readable part) with this TLV type to instruct the other party's
> client to abort the protocol.  The associated length should be zero and
> the associated value should be empty.  If you receive a TLV of this type,
> you should change the SMP state to SMP_EXPECT1 (see below).</dd>
> <dt>Type 7: SMP Message 1Q</dt>
> <dd>Like a SMP Message 1, but whose value begins with a NUL-terminated
> user-specified question.</dd>
> <dt>Type 8: Extra symmetric key</dt>
> <dd>If you wish to use the extra symmetric key, compute it yourself as
> outlined in the section "Extra symmetric key", below.  Then send this
> type 8 TLV to your buddy to indicate that you'd like to use the extra
> symmetric key for something.  The value of the TLV begins with a 4-byte
> indication of what this symmetric key will be used for (file transfer,
> voice encryption, etc.). After that, the contents are use-specific
> (which file, etc.). There are no currently defined uses.  Note that the
> value of the key itself is <em>not</em> placed into the TLV; your buddy
> will compute it on his/her own.
> </dd>
494a639,652
> <p>SMP Message TLVs (types 2-5) all carry data sharing the same general
> format:</p> 
> <dl>
> <dt>MPI count (INT)</dt>
> <dd>The number of MPIs contained in the remainder of the TLV.</dd>
> <dt>MPI 1 (MPI)</dt>
> <dd>The first MPI of the TLV, serialized into a byte array.</dd>
> <dt>MPI 2 (MPI)</dt>
> <dd>The second MPI of the TLV, serialized into a byte array.</dd>
> <dt>etc.</dt>
> </dl>
> <p>There should be as many MPIs as declared in the MPI count field.  For
> the exact MPIs passed for each SMP TLV, see the SMP state machine
> below.</p>
502c660
< <dd>The version number of this protocol is 0x0002.</dd>
---
> <dd>The version number of this protocol is 0x0003.</dd>
504a663,666
> <dt>Sender Instance tag (INT)</dt>
> <dd>The instance tag of the person sending this message.</dd>
> <dt>Receiver Instance tag (INT)</dt>
> <dd>The instance tag of the intended recipient.</dd>
544c706,1071
< <h4>Key Management</h4>
---
> <h3>Socialist Millionaires' Protocol (SMP)</h3>
> <p>The Socialist Millionaires' Protocol allows two parties with secret
> information x and y respectively to check whether (x==y) without revealing
> any additional information about the secrets.  The protocol used by OTR is
> based on the work of Boudot, Schoenmakers and Traore (2001).  A full 
> justification for its use in OTR is made by Alexander and Goldberg,
> in a paper published in 2007.  The following is a technical account
> of what is transmitted during the course of the protocol.</p>
> <h4>Secret information</h4>
> <p>The secret information x and y compared during this protocol contains
> not only information entered by the users, but also information unique to
> the conversation in which SMP takes place.  Specifically, the format is:</p>
> <dl>
> <dt>Version (BYTE)</dt>
> <dd>The version of SMP used.  The version described here is 1.</dd>
> <dt>Initiator fingerprint (20 BYTEs)</dt>
> <dd>The fingerprint that the party initiating SMP is using in
> the current conversation.</dd>
> <dt>Responder fingerprint (20 BYTEs)</dt>
> <dd>The fingerprint that the party that did not initiate SMP is 
> using in the current conversation.</dd>
> <dt>Secure Session ID</dt>
> <dd>The ssid described below.</dd>
> <dt>User-specified secret</dt>
> <dd>The input string given by the user at runtime.</dd>
> </dl>
> <p>Then the SHA256 hash of the above is taken, and the digest becomes the 
> actual secret (x or y) to be used in SMP.  The additional fields insure
> that not only do both parties know the same secret input string, but no
> man-in-the-middle is capable of reading their communication either.</p>
> <h3>The SMP state machine</h3>
> <p>Whenever the OTR message state machine has MSGSTATE_ENCRYPTED set
> (see below), the SMP state machine may progress.  If at any point 
> MSGSTATE_ENCRYPTED becomes unset, SMP must abandon its state and return
> to its initial setup.  The SMP state consists of one main variable, as
> well as information from the partial computations at each protocol step.</p>
> <h4>Expected Message</h4>
> <p>This main state variable for SMP controls what SMP-specific TLVs will
> be accepted.  This variable has no effect on type 0 or type 1 TLVs, which
> are always allowed.  smpstate can take one of four values:</p>
> <dl>
> <dt>SMPSTATE_EXPECT1</dt>
> <dd>This state indicates that only type 2 (SMP message 1) and type 7
> (SMP message 1Q) TLVs should be accepted.  This is the default state when
> SMP has not yet begun.  This state is also reached whenever an error
> occurs or SMP is aborted, and the protocol must be restarted from the
> beginning.</dd>
> <dt>SMPSTATE_EXPECT2</dt>
> <dd>This state indicates that only type 3 TLVs (SMP message 2) should
> be accepted.</dd>
> <dt>SMPSTATE_EXPECT3</dt>
> <dd>This state indicates that only type 4 TLVs (SMP message 3) should
> be accepted.</dd>
> <dt>SMPSTATE_EXPECT4</dt>
> <dd>This state indicates that only type 5 TLVs (SMP message 4) should
> be accepted.</dd>
> </dl>
> <h4>State Transitions</h4>
> <p>There are 7 actions that an OTR client must handle:</p>
> <ul>
> <li>Received TLVs:
> <ul>
> <li>SMP Message 1</li>
> <li>SMP Message 2</li>
> <li>SMP Message 3</li>
> <li>SMP Message 4</li>
> <li>SMP Abort Message</li>
> </ul></li>
> <li>User actions:</li>
> <ul>
> <li>User requests to begin SMP</li>
> <li>User requests to abort SMP</li>
> </ul></li>
> </ul>
> <p>The following sections outline what is to be done in each case.  They
> all assume that MSGSTATE_ENCRYPTED is set.  For simplicity, they also
> assume that Alice has begun SMP, and Bob is responding to her.</p>
> <h4>SMP Hash function</h4>
> <p>In the following actions, there are many places where a SHA256 hash of
> an integer followed by one or two MPIs is taken.  The input to this hash
> function is:</p>
> <dl>
> <dt>Version (BYTE)</dt>
> <dd>This distinguishes calls to the hash function at different points in
> the protocol, to prevent Alice from replaying Bob's zero knowledge proofs
> or vice versa.</dd>
> <dt>First MPI (MPI)</dt>
> <dd>The first MPI given as input, serialized in the usual way.</dd>
> <dt>Second MPI (MPI)</dt>
> <dd>The second MPI given as input, if present, serialized in the usual way.
> If only one MPI is given as input, this field is simply omitted.</dd>
> </dl>
> <h4>Receiving a type 2 TLV (SMP message 1)</h4>
> <p>SMP message 1 is sent by Alice to begin a DH exchange to determine two
> new generators, g<sub>2</sub> and g<sub>3</sub>.  It contains the
> following mpi values:</p>
> <dl>
> <dt>g<sub>2a</sub></dt>
> <dd>Alice's half of the DH exchange to determine g<sub>2</sub>.</dd>
> <dt>c2, D2</dt>
> <dd>A zero-knowledge proof that Alice knows the exponent associated with
> her transmitted value g<sub>2a</sub>.</dd>
> <dt>g<sub>3a</sub></dt>
> <dd>Alice's half of the DH exchange to determine g<sub>3</sub>.</dd>
> <dt>c3, D3</dt>
> <dd>A zero-knowledge proof that Alice knows the exponent associated with
> her transmitted value g<sub>3a</sub>.</dd>
> </dl>
> <p>A type 7 (SMP Message 1Q) TLV is the same as the above, but is
> preceded by a user-specified question, which is associated with the
> user-specified portion of the secret.</p>
> <p>When Bob receives this TLV he should do:</p>
> <dl>
> <dt>If smpstate is not SMPSTATE_EXPECT1:</dt>
> <dd>Set smpstate to SMPSTATE_EXPECT1 and send a type 6 TLV (SMP abort)
> to Alice.</dd>
> <dt>If smpstate is SMPSTATE_EXPECT1:</dt>
> <dd>Verify Alice's zero-knowledge proofs for g<sub>2a</sub> and
> g<sub>3a</sub>:
> <ol>
> <li>Check that both g<sub>2a</sub> and g<sub>3a</sub> are &gt;= 2 and
> &lt;= modulus-2.</li>
> <li>Check that c2 = SHA256(1, g<sub>1</sub><sup>D2</sup> 
> g<sub>2a</sub><sup>c2</sup>).</li>
> <li>Check that c3 = SHA256(2, g<sub>1</sub><sup>D3</sup> 
> g<sub>3a</sub><sup>c3</sup>).</li>
> </ol>
> Create a type 3 TLV (SMP message 2) and send it to Alice:
> <ol>
> <li>Determine Bob's secret input y, which is to be compared to Alice's
> secret x.</li>
> <li>Pick random exponents b<sub>2</sub> and b<sub>3</sub>.
> These will used during the DH exchange to pick generators.</li>
> <li>Pick random exponents r2, r3, r4, r5 and r6.
> These will be used to add a blinding factor to the final results, and
> to generate zero-knowledge proofs that this message was created honestly.</li>
> <li>Compute g<sub>2b</sub> = g<sub>1</sub><sup>b<sub>2</sub></sup> and
> g<sub>3b</sub> = g<sub>1</sub><sup>b<sub>3</sub></sup></li>
> <li>Generate a zero-knowledge proof that the exponent b<sub>2</sub> is
> known by setting c2 = SHA256(3, g<sub>1</sub><sup>r2</sup>) and
> D2 = r2 - b<sub>2</sub> c2 mod q. In the zero-knowledge proofs the D values
> are calculated modulo q = (p - 1) / 2, where p is the same 1536-bit prime
> as elsewhere. The random exponents are 1536-bit numbers.</li>
> <li>Generate a zero-knowledge proof that the exponent b<sub>3</sub> is
> known by setting c3 = SHA256(4, g<sub>1</sub><sup>r3</sup>) and
> D3 = r3 - b<sub>3</sub> c3 mod q.</li>
> <li>Compute g<sub>2</sub> = g<sub>2a</sub><sup>b<sub>2</sub></sup> and
> g<sub>3</sub> = g<sub>3a</sub><sup>b<sub>3</sub></sup></li>
> <li>Compute P<sub>b</sub> = g<sub>3</sub><sup>r4</sup> and
> Q<sub>b</sub> = g<sub>1</sub><sup>r4</sup> g<sub>2</sub><sup>y</sup></li>
> <li>Generate a zero-knowledge proof that P<sub>b</sub> and Q<sub>b</sub>
> were created according to the protocol by setting 
> cP = SHA256(5, g<sub>3</sub><sup>r5</sup>, g<sub>1</sub><sup>r5</sup> 
> g<sub>2</sub><sup>r6</sup>), D5 = r5 - r4 cP mod q and D6 = r6 - y cP mod q.</li>
> <li>Store the values of g<sub>3a</sub>, g<sub>2</sub>, g<sub>3</sub>,
> b<sub>3</sub>, P<sub>b</sub> and Q<sub>b</sub> for use later in the
> protocol.</li>
> <li>Send Alice a type 3 TLV (SMP message 2) containing g<sub>2b</sub>, 
> c2, D2, g<sub>3b</sub>, c3, D3, P<sub>b</sub>, Q<sub>b</sub>, cP, D5
> and D6, in that order.</li>
> </ol>
> Set smpstate to SMPSTATE_EXPECT3.</dd>
> </dl>
> <h4>Receiving a type 3 TLV (SMP message 2)</h4>
> <p>SMP message 2 is sent by Bob to complete the DH exchange to
> determine the new generators, g<sub>2</sub> and g<sub>3</sub>. 
> It also begins the construction of the values used in the final
> comparison of the protocol.  It contains the following mpi values:</p>
> <dl>
> <dt>g<sub>2b</sub></dt>
> <dd>Bob's half of the DH exchange to determine g<sub>2</sub>.</dd>
> <dt>c2, D2</dt>
> <dd>A zero-knowledge proof that Bob knows the exponent associated with
> his transmitted value g<sub>2b</sub>.</dd>
> <dt>g<sub>3b</sub></dt>
> <dd>Bob's half of the DH exchange to determine g<sub>3</sub>.</dd>
> <dt>c3, D3</dt>
> <dd>A zero-knowledge proof that Bob knows the exponent associated with
> his transmitted value g<sub>3b</sub>.</dd>
> <dt>P<sub>b</sub>, Q<sub>b</sub></dt>
> <dd>These values are used in the final comparison to determine if Alice
> and Bob share the same secret.</dd>
> <dt>cP, D5, D6</dt>
> <dd>A zero-knowledge proof that P<sub>b</sub> and Q<sub>b</sub> were
> created according to the protcol given above.</dd>
> </dl>
> <p>When Alice receives this TLV she should do:</p>
> <dl>
> <dt>If smpstate is not SMPSTATE_EXPECT2:</dt>
> <dd>Set smpstate to SMPSTATE_EXPECT1 and send a type 6 TLV (SMP abort)
> to Bob.</dd>
> <dt>If smpstate is SMPSTATE_EXPECT2:</dt>
> <dd>Verify Bob's zero-knowledge proofs for g<sub>2b</sub>, 
> g<sub>3b</sub>, P<sub>b</sub> and Q<sub>b</sub>:
> <ol>
> <li>Check that g<sub>2b</sub>,
> g<sub>3b</sub>, P<sub>b</sub> and Q<sub>b</sub> are &gt;= 2 and
> &lt;= modulus-2.</li>
> <li>Check that c2 = SHA256(3, g<sub>1</sub><sup>D2</sup> 
> g<sub>2b</sub><sup>c2</sup>).</li>
> <li>Check that c3 = SHA256(4, g<sub>1</sub><sup>D3</sup> 
> g<sub>3b</sub><sup>c3</sup>).</li>
> <li>Check that cP = SHA256(5, g<sub>3</sub><sup>D5</sup> 
> P<sub>b</sub><sup>cP</sup>, g<sub>1</sub><sup>D5</sup>
> g<sub>2</sub><sup>D6</sup> Q<sub>b</sub><sup>cP</sup>).</li>
> </ol>
> Create a type 4 TLV (SMP message 3) and send it to Bob:
> <ol>
> <li>Pick random exponents r4, r5, r6 and r7.
> These will be used to add a blinding factor to the final results, and
> to generate zero-knowledge proofs that this message was created honestly.</li>
> <li>Compute g<sub>2</sub> = g<sub>2b</sub><sup>a<sub>2</sub></sup> and
> g<sub>3</sub> = g<sub>3b</sub><sup>a<sub>3</sub></sup></li>
> <li>Compute P<sub>a</sub> = g<sub>3</sub><sup>r4</sup> and
> Q<sub>a</sub> = g<sub>1</sub><sup>r4</sup> g<sub>2</sub><sup>x</sup></li>
> <li>Generate a zero-knowledge proof that P<sub>a</sub> and Q<sub>a</sub>
> were created according to the protocol by setting 
> cP = SHA256(6, g<sub>3</sub><sup>r5</sup>, g<sub>1</sub><sup>r5</sup> 
> g<sub>2</sub><sup>r6</sup>), D5 = r5 - r4 cP mod q and D6 = r6 - x cP mod q.</li>
> <li>Compute R<sub>a</sub> = (Q<sub>a</sub> / Q<sub>b</sub>)
> <sup>a<sub>3</sub></sup></li>
> <li>Generate a zero-knowledge proof that R<sub>a</sub> was created 
> according to the protocol by setting cR = SHA256(7, g<sub>1</sub><sup>r7</sup>, 
> (Q<sub>a</sub> / Q<sub>b</sub>)<sup>r7</sup>) and 
> D7 = r7 - a<sub>3</sub> cR mod q.</li>
> <li>Store the values of g<sub>3b</sub>, (P<sub>a</sub> / P<sub>b</sub>), 
> (Q<sub>a</sub> / Q<sub>b</sub>) and R<sub>a</sub> for use later in the
> protocol.</li>
> <li>Send Bob a type 4 TLV (SMP message 3) containing P<sub>a</sub>, 
> Q<sub>a</sub>, cP, D5, D6, R<sub>a</sub>, cR and D7 in that order.</li>
> </ol>
> Set smpstate to SMPSTATE_EXPECT4.</dd>
> </dl>
> <h4>Receiving a type 4 TLV (SMP message 3)</h4>
> <p>SMP message 3 is Alice's final message in the SMP exchange.  It 
> has the last of the information required by Bob to determine if x = y.
> It contains the following mpi values:</p>
> <dl>
> <dt>P<sub>a</sub>, Q<sub>a</sub></dt>
> <dd>These values are used in the final comparison to determine if Alice
> and Bob share the same secret.</dd>
> <dt>cP, D5, D6</dt>
> <dd>A zero-knowledge proof that P<sub>a</sub> and Q<sub>a</sub> were
> created according to the protcol given above.</dd>
> <dt>R<sub>a</sub></dt>
> <dd>This value is used in the final comparison to determine if Alice
> and Bob share the same secret.</dd>
> <dt>cR, D7</dt>
> <dd>A zero-knowledge proof that R<sub>a</sub> was
> created according to the protcol given above.</dd>
> <dt>
> </dl>
> <p>When Bob receives this TLV he should do:</p>
> <dl>
> <dt>If smpstate is not SMPSTATE_EXPECT3:</dt>
> <dd>Set smpstate to SMPSTATE_EXPECT1 and send a type 6 TLV (SMP abort)
> to Bob.</dd>
> <dt>If smpstate is SMPSTATE_EXPECT3:</dt>
> <dd>Verify Alice's zero-knowledge proofs for P<sub>a</sub>, Q<sub>a</sub> 
> and R<sub>a</sub>:
> <ol>
> <li>Check that P<sub>a</sub>, Q<sub>a</sub> and R<sub>a</sub> are &gt;= 2 and
> &lt;= modulus-2.</li>
> <li>Check that cP = SHA256(6, g<sub>3</sub><sup>D5</sup> 
> P<sub>a</sub><sup>cP</sup>, g<sub>1</sub><sup>D5</sup> g<sub>2</sub><sup>D6</sup> 
> Q<sub>a</sub><sup>cP</sup>).</li>
> <li>Check that cR = SHA256(7, g<sub>1</sub><sup>D7</sup>
> g<sub>3a</sub><sup>cR</sup>, (Q<sub>a</sub> / Q<sub>b</sub>)<sup>D7</sup> 
> R<sub>a</sub><sup>cR</sup>).</li> 
> </ol>
> Create a type 5 TLV (SMP message 4) and send it to Alice:
> <ol>
> <li>Pick a random exponent r7.
> This will be used to generate Bob's final zero-knowledge proof that 
> this message was created honestly.</li>
> <li>Compute R<sub>b</sub> = (Q<sub>a</sub> / Q<sub>b</sub>)
> <sup>b<sub>3</sub></sup></li>
> <li>Generate a zero-knowledge proof that R<sub>b</sub> was created 
> according to the protocol by setting cR = SHA256(8, g<sub>1</sub><sup>r7</sup>, 
> (Q<sub>a</sub> / Q<sub>b</sub>)<sup>r7</sup>) and 
> D7 = r7 - b<sub>3</sub> cR mod q.</li>
> <li>Send Alice a type 5 TLV (SMP message 4) containing R<sub>b</sub>, 
> cR and D7 in that order.</li>
> </ol>
> Check whether the protocol was successful:
> <ol>
> <li>Compute R<sub>ab</sub> = R<sub>a</sub><sup>b<sub>3</sub></sup>.</li>
> <li>Determine if x = y by checking the equivalent condition that 
> (P<sub>a</sub> / P<sub>b</sub>) = R<sub>ab</sub>.</li>
> </ol>
> Set smpstate to SMPSTATE_EXPECT1, as no more messages are expected from
> Alice.</dd>
> </dl>
> <h4>Receiving a type 5 TLV (SMP message 4)</h4>
> <p>SMP message 4 is Bob's final message in the SMP exchange.  It 
> has the last of the information required by Alice to determine if x = y.
> It contains the following mpi values:</p>
> <dl>
> <dt>R<sub>b</sub></dt>
> <dd>This value is used in the final comparison to determine if Alice
> and Bob share the same secret.</dd>
> <dt>cR, D7</dt>
> <dd>A zero-knowledge proof that R<sub>b</sub> was
> created according to the protcol given above.</dd>
> <dt>
> </dl>
> <p>When Alice receives this TLV she should do:</p>
> <dl>
> <dt>If smpstate is not SMPSTATE_EXPECT4:</dt>
> <dd>Set smpstate to SMPSTATE_EXPECT1 and send a type 6 TLV (SMP abort)
> to Bob.</dd>
> <dt>If smpstate is SMPSTATE_EXPECT4:</dt>
> <dd>Verify Bob's zero-knowledge proof for R<sub>b</sub>:
> <ol>
> <li>Check that R<sub>b</sub> is &gt;= 2 and
> &lt;= modulus-2.</li>
> <li>Check that cR = SHA256(8, g<sub>1</sub><sup>D7</sup>
> g<sub>3b</sub><sup>cR</sup>, (Q<sub>a</sub> / Q<sub>b</sub>)<sup>D7</sup> 
> R<sub>b</sub><sup>cR</sup>).</li> 
> </ol>
> Check whether the protocol was successful:
> <ol>
> <li>Compute R<sub>ab</sub> = R<sub>b</sub><sup>a<sub>3</sub></sup>.</li>
> <li>Determine if x = y by checking the equivalent condition that 
> (P<sub>a</sub> / P<sub>b</sub>) = R<sub>ab</sub>.</li>
> </ol>
> Set smpstate to SMPSTATE_EXPECT1, as no more messages are expected from
> Bob.</dd>
> </dl>
> <h4>User requests to begin SMP</h4>
> <dl>
> <dt>If smpstate is not set to SMPSTATE_EXPECT1:</dt>
> <dd>SMP is already underway.  If you wish to restart SMP, send a
> type 6 TLV (SMP abort) to the other party and then proceed as if
> smpstate was SMPSTATE_EXPECT1.  Otherwise, you may simply continue the
> current SMP instance.</dd>
> <dt>If smpstate is set to SMPSTATE_EXPECT1:</dt>
> <dd>No current exchange is underway.  In this case, Alice should 
> create a valid type 2 TLV (SMP message 1) as follows:
> <ol>
> <li>Determine her secret input x, which is to be compared to Bob's
> secret y.</li>
> <li>Pick random values a<sub>2</sub> and a<sub>3</sub> (128 bits).
> These will be Alice's exponents for the DH exchange to pick generators.</li>
> <li>Pick random values r2 and r3 (128 bits).
> These will be used to generate zero-knowledge proofs that this message
> was created according to the protocol.</li>
> <li>Compute g<sub>2a</sub> = g<sub>1</sub><sup>a<sub>2</sub></sup> and
> g<sub>3a</sub> = g<sub>1</sub><sup>a<sub>3</sub></sup></li>
> <li>Generate a zero-knowledge proof that the exponent a<sub>2</sub> is
> known by setting c2 = SHA256(1, g<sub>1</sub><sup>r2</sup>) and
> D2 = r2 - a<sub>2</sub> c2 mod q.</li>
> <li>Generate a zero-knowledge proof that the exponent a<sub>3</sub> is
> known by setting c3 = SHA256(2, g<sub>1</sub><sup>r3</sup>) and
> D3 = r3 - a<sub>3</sub> c3 mod q.</li>
> <li>Store the values of x, a<sub>2</sub> and a<sub>3</sub> 
> for use later in the protocol.</li>
> <li>Send Bob a type 2 TLV (SMP message 1) containing g<sub>2a</sub>, 
> c2, D2, g<sub>3a</sub>, c3 and D3 in that order.</li>
> </ol>
> Set smpstate to SMPSTATE_EXPECT2.</dd>
> </dl>
> <h4>User requests to abort SMP</h4>
> <p>In all cases, send a type 6 TLV (SMP abort) to the correspondent and
> set smpstate to SMPSTATE_EXPECT1.</p>
> <h3>Key Management</h3>
630c1157
< SHA256 hash of the (5+len) bytes consisting of the byte b, followed by
---
> SHA256 hash of the (5+len) bytes consisting of the byte b followed by
690a1218,1232
> <h4>Extra symmetric key</h4>
> <p>OTR version 3 defines an additional symmetric key that can be derived
> by the communicating parties to use for application-specific purposes,
> such as file transfer, voice encryption, etc.  When one party wishes to
> use the extra symmetric key, he or she creates a type 8 TLV attached to
> a Data Message (see above).  The key itself is then derived using the
> same "secbytes" used to compute the encryption and MAC keys used to
> protect the Data Message.
> The extra symmetric key is derived by calculating
> h2(0xFF) and keeping the entire 256 bits, using the same definition
> of h2 as above.</p>
> <p>Upon receipt of the Data Message containing the type 8 TLV, the
> recipient will compute the extra symmetric key in the same way.  Note
> that the value of the extra symmetric key is <em>not</em> contained in
> the TLV itself.</p>
693,695c1235,1238
< one of your correspondent's old D-H public keys, take all of the MAC keys
< that were generated by that key (note that there are up to four: the
< sending and receiving MAC keys produced by the pairings of that key with
---
> one of your correspondent's old D-H public keys, take all of the
> receiving MAC keys
> that were generated by that key (note that there are up to two: the
> receiving MAC keys produced by the pairings of that key with
697,698c1240,1241
< take MAC keys that were actually used to either create a MAC on a
< message, or verify a MAC on a message), and put them (as a set of
---
> take MAC keys that were actually used to verify a MAC on a message), and
> put them (as a set of
706c1249
< <h4>Fragmentation</h4>
---
> <h3>Fragmentation</h3>
710,712c1253,1255
< describes the format of the fragments.  All OTR version 2 clients must
< be able to assemble received fragments, but performing fragmentation on
< outgoing messages is optional.</p>
---
> describes the format of the fragments.  All OTR version 2 and 3 clients
> must be able to assemble received fragments, but performing
> fragmentation on outgoing messages is optional.</p>
726,727c1269,1270
<     <li>Transmit (n) messages with the following (printf-like) structure
<       (as k runs from 1 to n inclusive):
---
>     <li>Transmit (n) OTR version 3 fragmented messages with the following
>       (printf-like) structure (as k runs from 1 to n inclusive):
729c1272,1279
<       <p>"?OTR,%hu,%hu,%s," , k , n , piece[k]</p></li>
---
>       <p>"?OTR|%x|%x,%hu,%hu,%s," , sender_instance, receiver_instance, 
>       k , n , piece[k]</p>
>       
>       OTR version 2 messages get fragmented in a similar format, but 
>       without the instance tags fields:
>       
>       <p>"?OTR,%hu,%hu,%s," , sender_instance, receiver_instance, 
>       k , n , piece[k]</p></li>
738c1288
< <dd>If you receive a message containing "?OTR," (note that you'll need
---
> <dd>If you receive a message containing "?OTR|" (note that you'll need
744a1295,1298
>     <li>If the recipient's own instance tag does not match the listed
>     receiver instance tag, and the listed receiver instance tag is not
>     zero, the recipient should discard the message and optionally pass
>     along a warning for the user.</li>
778c1332,1336
<     (0,0) as (K,N).</p></dd>
---
>     (0,0) as (K,N).</p>
>     
>     <p>OTR version 2 fragmented messages follow the same behaviour as
>     described above, but do not list the sender and receiver instance
>     tags.</dd>
785,798c1343,1348
< ?OTR:AAEDAAAAAQAAAAEAAADAVf3Ei72ZgFeKqWvLMnuVPVCwxktsOZ1Qdje
< Lp6jn62mCVtlY9nS6sRkecpjuLYHRxyTdRu2iEVtSsjZqK55ovZ35SfkOPHe
< FYa9BIuxWi9djHMVKQ8KOVGAVLibjZ6P8LreDSKtWDv9YQjIEnkwFVGCPfpB
< q2SX4VTQfJAQXHggR8izKxPvluXUdG9rIPh4cac98++VLdIuFMiEXjUIoTX2
< rEzunaCLMy0VIfowlRsgsKGrwhCCv7hBWyglbzwz+AAAAAAAAAAQAAAF2SOr
< JvPUerB9mtf4bqQDFthfoz/XepysnYuReHHEXKe+BFkaEoMNGiBl4TCLZx72
< DvmZwKCewWRH1+W66ggrXKw2VdVl+vLsmzxNyWChGLfBTL5/3SUF09BfmCEl
< 03Ckk7htAgyAQcBf90RJznZndv7HwVAi3syupi0sQDdOKNPyObR5FRtqyqud
< ttWmSdmGCGFcZ/fZqxQNsHB8QuYaBiGL7CDusES+wwfn8Q7BGtoJzOPDDx6K
< yIyox/flPx2DZDJIZrMz9b0V70a9kqKLo/wcGhvHO6coCyMxenBAacLJ1DiI
< NLKoYOoJTM7zcxsGnvCxaDZCvsmjx3j8Yc5r3i3ylllCQH2/lpr/xCvXFarG
< tG7+wts+UqstS9SThLBQ9Ojq4oPsX7HBHKvq19XU3/ChIgWMy+bczc5gpkC/
< eLAIGfJ0D5DJsl68vMXSmCoFK0HTwzzNa7lnZK4IutYPBNBCv0pWORQqDpsk
< Ez96YOGyB8+gtpFgCrkuV1bSB9SRVmEBfDtKPQFhKowAAAAA=.
---
> ?OTR:AAMDJ+MVmSfjFZcAAAAAAQAAAAIAAADA1g5IjD1ZGLDVQEyCgCyn9hb
> rL3KAbGDdzE2ZkMyTKl7XfkSxh8YJnudstiB74i4BzT0W2haClg6dMary/jo
> 9sMudwmUdlnKpIGEKXWdvJKT+hQ26h9nzMgEditLB8vjPEWAJ6gBXvZrY6ZQ
> rx3gb4v0UaSMOMiR5sB7Eaulb2Yc6RmRnnlxgUUC2alosg4WIeFN951PLjSc
> ajVba6dqlDi+q1H5tPvI5SWMN7PCBWIJ41+WvF+5IAZzQZYgNaVLbAAAAAAA
> AAAEAAAAHwNiIi5Ms+4PsY/L2ipkTtquknfx6HodLvk3RAAAAAA==.
805,810c1355,1358
< ?OTR,1,3,?OTR:AAEDAAAAAQAAAAEAAADAVf3Ei72ZgFeKqWvLMnuVPVCwxk
< tsOZ1QdjeLp6jn62mCVtlY9nS6sRkecpjuLYHRxyTdRu2iEVtSsjZqK55ovZ
< 35SfkOPHeFYa9BIuxWi9djHMVKQ8KOVGAVLibjZ6P8LreDSKtWDv9YQjIEnk
< wFVGCPfpBq2SX4VTQfJAQXHggR8izKxPvluXUdG9rIPh4cac98++VLdIuFMi
< EXjUIoTX2rEzunaCLMy0VIfowlRsgsKGrwhCCv7hBWyglbzwz+AAAAAAAAAA
< QAAAF2SOr,
---
> ?OTR|5a73a599|27e31597,00001,00003,?OTR:AAMDJ+MVmSfjFZcAAAAA
> AQAAAAIAAADA1g5IjD1ZGLDVQEyCgCyn9hbrL3KAbGDdzE2ZkMyTKl7XfkSx
> h8YJnudstiB74i4BzT0W2haClg6dMary/jo9sMudwmUdlnKpIGEKXWdvJKT+
> hQ26h9nzMgEditLB8v,
814,819c1362,1365
< ?OTR,2,3,JvPUerB9mtf4bqQDFthfoz/XepysnYuReHHEXKe+BFkaEoMNGiB
< l4TCLZx72DvmZwKCewWRH1+W66ggrXKw2VdVl+vLsmzxNyWChGLfBTL5/3SU
< F09BfmCEl03Ckk7htAgyAQcBf90RJznZndv7HwVAi3syupi0sQDdOKNPyObR
< 5FRtqyqudttWmSdmGCGFcZ/fZqxQNsHB8QuYaBiGL7CDusES+wwfn8Q7BGto
< JzOPDDx6KyIyox/flPx2DZDJIZrMz9b0V70a9kqKLo/wcGhvHO6coCyMxenB
< AacLJ1DiI,
---
> ?OTR|5a73a599|27e31597,00002,00003,jPEWAJ6gBXvZrY6ZQrx3gb4v0
> UaSMOMiR5sB7Eaulb2Yc6RmRnnlxgUUC2alosg4WIeFN951PLjScajVba6dq
> lDi+q1H5tPvI5SWMN7PCBWIJ41+WvF+5IAZzQZYgNaVLbAAAAAAAAAAEAAAA
> HwNiIi5Ms+4PsY/L2i,
823,826c1369,1370
< ?OTR,3,3,NLKoYOoJTM7zcxsGnvCxaDZCvsmjx3j8Yc5r3i3ylllCQH2/lpr
< /xCvXFarGtG7+wts+UqstS9SThLBQ9Ojq4oPsX7HBHKvq19XU3/ChIgWMy+b
< czc5gpkC/eLAIGfJ0D5DJsl68vMXSmCoFK0HTwzzNa7lnZK4IutYPBNBCv0p
< WORQqDpskEz96YOGyB8+gtpFgCrkuV1bSB9SRVmEBfDtKPQFhKowAAAAA=.,
---
> ?OTR|5a73a599|27e31597,00003,00003,pkTtquknfx6HodLvk3RAAAAAA
> ==.,
886,888c1430,1431
< Signature Message (and replies with her own Signature Message),</li>
< <li>Alice (in AUTHSTATE_NONE) receives Bob's Version 1 Key Exchange
< Message (and replies with her own Key Exchange Message),</li>
---
> Signature Message (and replies with her own Signature Message), <b>or</b>
> </li>
890,892c1433
< <b>or</b></li>
< <li>Bob (in AUTHSTATE_V1_SETUP) receives Alice's Version 1 Key Exchange
< Message,</li>
---
> /li>
902c1443
< speaks only OTR version 2, except with Charlie, who she knows has only
---
> speaks only OTR version 3, except with Charlie, who she knows has only
910c1451,1453
< <dd>Allow version 1 of the OTR protocol to be used.</dd>
---
> <dd>Allow version 1 of the OTR protocol to be used (in general this
> document will not address OTR protocol version 1; see previous
> protocol documents for these details).</dd>
912a1456,1457
> <dt>ALLOW_V3</dt>
> <dd>Allow version 3 of the OTR protocol to be used.</dd>
922,936d1466
< <p>The four old version 1 policies correspond to the following
< combinations of flags (adding an allowance for version 2 of the
< protocol):</p>
< <dl>
< <dt>NEVER</dt>
< <dd>No flags set</dd>
< <dt>MANUAL</dt>
< <dd>ALLOW_V1 | ALLOW_V2</dd>
< <dt>OPPORTUNISTIC</dt>
< <dd>ALLOW_V1 | ALLOW_V2 | SEND_WHITESPACE_TAG | WHITESPACE_START_AKE |
< ERROR_START_AKE</dd>
< <dt>ALWAYS</dt>
< <dd>ALLOW_V1 | ALLOW_V2 | REQUIRE_ENCRYPTION | WHITESPACE_START_AKE |
< ERROR_START_AKE</dd>
< </dl>
952d1481
< <li>Version 1 Key Exchange Message</li>
963,965c1492,1500
< case.  They all assume that at least one of ALLOW_V1 or ALLOW_V2 is set;
< if not, then OTR is completely disabled, and no special handling of
< messages should be done at all.</p>
---
> case.  They all assume that at least one of ALLOW_V1, ALLOW_V2 or
> ALLOW_V3 is set; if not, then OTR is completely disabled, and no
> special handling of messages should be done at all. For version 1
> messages, please refer to previous OTR protocol documents. For version
> 3 messages, someone receiving a message with a recipient instance tag
> specified that does not equal their own should discard the message
> and optionally warn the user. The exception here is the D-H Commit
> Message where the recipient instance tag may be 0, indicating that no
> particular instance is specified.</p>
987,988c1522,1526
< <dt>If the tag offers OTR version 2 and ALLOW_V2 is set:</dt>
< <dd>Send a D-H Commit Message, and transition authstate to
---
> <dt>If the tag offers OTR version 3 and ALLOW_V3 is set:</dt>
> <dd>Send a version 3 D-H Commit Message, and transition authstate to
> AUTHSTATE_AWAITING_DHKEY.</dd>
> <dt>Otherwise, if the tag offers OTR version 2 and ALLOW_V2 is set:</dt>
> <dd>Send a version 2 D-H Commit Message, and transition authstate to
990,992d1527
< <dt>Otherwise, if the tag offers OTR version 1 and ALLOW_V1 is set:</dt>
< <dd>Send a Version 1 Key Exchange Message, and transition authstate to
< AUTHSTATE_V1_SETUP.</dd>
996,997c1531,1535
< <dt>If the Query Message offers OTR version 2 and ALLOW_V2 is set:</dt>
< <dd>Send a D-H Commit Message, and transition authstate to
---
> <dt>If the query message offers OTR version 3 and ALLOW_V3 is set:</dt>
> <dd>Send a version 3 D-H Commit Message, and transition authstate to
> AUTHSTATE_AWAITING_DHKEY.</dd>
> <dt>Otherwise, if the message offers OTR version 2 and ALLOW_V2 is set:</dt>
> <dd>Send a version 2 D-H Commit Message, and transition authstate to
999,1001d1536
< <dt>Otherwise, if the message offers OTR version 1 and ALLOW_V1 is set:</dt>
< <dd>Send a Version 1 Key Exchange Message, and transition authstate to
< AUTHSTATE_V1_SETUP.</dd>
1009c1544,1546
< <p>If ALLOW_V2 is not set, ignore this message.  Otherwise:</p>
---
> <p>If the message is version 2 and ALLOW_V2 is not set, ignore this message.
> Similarly if the message is version 3 and ALLOW_V3 is not set, ignore the
> message. Otherwise:</p>
1053c1590,1592
< <p>If ALLOW_V2 is not set, ignore this message.  Otherwise:</p>
---
> <p>If the message is version 2 and ALLOW_V2 is not set, ignore this
> message. Similarly if the message is version 3 and ALLOW_V3 is not
> set, ignore this message. Otherwise:</p>
1105c1644
< AUTHSTATE_AWAITING_REVEALSIG, or AUTHSTATE_V1_SETUP:</dt>
---
> or AUTHSTATE_AWAITING_REVEALSIG:</dt>
1108,1139d1646
< <h4>Receiving a Version 1 Key Exchange Message</h4>
< <p>If ALLOW_V1 is not set, ignore this message.  Otherwise:</p>
< <dl>
< <dt>If authstate is AUTHSTATE_NONE, AUTHSTATE_AWAITING_DHKEY,
< AUTHSTATE_AWAITING_REVEALSIG, or AUTHSTATE_AWAITING_SIG:</dt>
< <dd><dl><dt>If the reply field is not set to 0x01:</dt>
< <dd>Verify the information in the Key Exchange Message.  If the
< verification succeeds:
< <ul>
< <li>Reply with a Key Exchange Message with the reply field set to
< 0x01.</li>
< <li>Transition authstate to AUTHSTATE_NONE.</li>
< <li>Transition msgstate to MSGSTATE_ENCRYPTED.</li>
< <li>If there is a recent stored message, encrypt it and send it as a
< Data Message.</li>
< </ul>
< Otherwise, ignore the message.</dd>
< <dt>Otherwise, ignore the message.</dt></dl></dd>
< <dt>If authstate is AUTHSTATE_V1_SETUP:</dt>
< <dd>Verify the information in the Key Exchange Message.  If the
< verification succeeds:
< <ul>
< <li>If the received Key Exchange Message did not have the reply field
< set to 0x01, reply with a Key Exchange Message with the reply field set
< to 0x01.</li>
< <li>Transition authstate to AUTHSTATE_NONE.</li>
< <li>Transition msgstate to MSGSTATE_ENCRYPTED.</li>
< <li>If there is a recent stored message, encrypt it and send it as a
< Data Message.</li>
< </ul>
< Otherwise, ignore the message.</dd>
< </dl>