[OTR-dev] About the draft

[Ian Goldberg]

On Mon, Oct 17, 2005 at 07:50:39PM +0200, Mario wrote:
> Hi to all,
> I've some questions about the AKE from the draft of the new protocol:
> I've (hardly) recognized the SIGMA protocol in it, but:
> - why do you encrypt the component g^x with AES under a fresh key $r$
> when you reveal $r$ under the third message? In this way you are
> temporarily hiding the component $g^x$. Why?

It's actually the hash(g^x) in that message that's important; Bob is
committing to a choice of x, so that we can use a truncated hash
of g^{xy} later in the protocol (as the secure session id) without
a MITM being able to match the truncated hashes.  What we've got:

-> enc_r(g^x), hash(g^x)
<- g^y
-> r, authenticator
<- authenticator

is just the same as

-> hash(g^x)
<- g^y
-> g^x, authenticator
<- authenticator

except that r is much smaller than g^x, and so we save space in the
(crowded) third message by putting enc_r(g^x) in the first message.
Many IM networks have very limited message sizes, so we have to be
careful about how much we send.

> - What's the aim of the keyid_B and keyid_A fields in the AKE? For
> example, keyid_B is included into MAC_B (with g^x from which it is
> derivated).

The keyids are used to identify the keys for the subsequent Data
Messages.  They're used to keep track of the key rotations.

> - Why do you generate a further MAC_B=MAC_{m1}(g^x,g^y,pub_B,keyid_B)
> and then you sign it as sig_B(MAC_B) instead to sign directly
> sig_B(g^x,g^y,pub_B,keyid_B)?
> - In the SIGMA protocol, the part signs only the DH-components and not
> the his identity (that is contained into the separated MAC_{Km}(0,A)).
> You are signing (indirectly signing the MAC) the identity of the part.

We use the space-saving variant of SIGMA that IKE also uses: instead of
sending

    sig_B(g^x, g^y), MAC_k(pub_B)

you send

    sig_B(MAC_k(g^x, g^y, pub_B))

The rules of SIGMA are that you have to MAC your identity, and
you have to sign fresh values (such as the DH params), but you can
always do more.  And this way saves message space, since you only send
one signature, instead of one signature and one MAC.  [The message is
then itself encrypted and MAC'd for identity protection, but that's a
separate MAC.]

See section 5.4 of Krawczyk, "SIGMA: the 'SIGn-and-MAc' Approach to
Authenticated Diffie-Hellman and its Use in the IKE Protocols", for
example.

> I hope that my comments don't arrive too late. I suggest to keep the
> protocol as simple as possible (without unnecessary layer of
> complexity). Nevertheless, actually I don't see security problems.

Thanks for your comments [as well as, of course, the paper that
instigated them ;-) ]!

   - Ian