[Hipsec] Progress on HIP DEX

[Robert Moskowitz <[e-mail]>]

First I have recognized that without a hash, you cannot offer ECDSA.  In 
fact without a hash (or rather a compress function that offers collision 
resistance), a signing with ECC is NOT ECDSA by definition, it is 
something else.

So I have designed HIP DEX to only use:

AES-CCM
CMAC
ECC ElGamel Encryption (is there a nice acronym for this?)

Since there is no signing function, HIP DEX does not use the SIGMA 
model, but I believe that I provide (by the end of the exchange) the 
same proofs.

This protocol is expected to run over networks that lose lots of 
packets, so you need to ensure success by aggressive retransmission of 
packets until you get proof that your packet was received.  To this end 
there is a timer, t, in msec there is also a lifetime (when sender will 
just quit sending) in msec.  Example values of 100,3000.  This 
retransmission also plays an interesting part in completing to exchange, 
so timers are used even when there is no packet loss.

With all of this there are subtle differences between the BEX and DEX 
state machines.

parties are:

I   ::= Initator
R   ::= Responder
MR  ::= Malicious Responder
IR  ::= Malicious Initator

Values are:

PK  ::= Public key of
t   ::= retransmit timer value and lifetime
n   ::= nonce
Pn  ::= Puzzle based on and containing nonce n
Sn  ::= Puzzle solution based on nonce n
x,y ::= random secrets

Functions are:

ECR ::= ECC ElGamal Encryption
MAC ::= CMAC
|   ::= concatination
||  ::= Key expansion extraction

R or MR                                                                I 
or IR
I1 ::= <---  t
R1 ::=               t, Pn, PKr                                ------>
I2 ::= <--- t, Pn, Sn, PKi, ECR(PKr,n|x), MAC(x,(t, Pn, Sn, PKi, 
ECR(PKr,n|x)))
R                                                                      I 
or IR
R2 ::=               n, ECR(PKi,n|y), MAC(x, (n, ECR(PKi,n|y))) ------>
R                                                                      I
<---  Data, MAC(x||y, Data) ------>

I starts sending I1 and continues send it until it receives R1
R sends R1 and continues to send it until it receives I2
I sends I2 and continues send it until it receives R2, then it 
transistions to connected state
R sends R2 and continues send it until it stops receiving I2, then it 
transistions to connected state

R1 and I2 need to be held to check incoming for duplicates.  I am not 
sure what the processing logic should be if there are differences 
between packets.  Process first and drop all duplicates and deviants?  
Process deviants as they may be the actual uncorrupted (by Malice) 
packets?  Note that R1 does NOT have any integrity proof.  MR could get 
mean.

Without this retransmission, there would have to be an extended exchange 
to prove completeness.

After the first datagram is received by R, each party has proved 
ownership of their private key, there is no proof that R is whom I 
**THINKS** R is nor about who I is for R.  That all has to be 
established else how (eg ACLS of PKs).

This lack of proof of I owning PKi until receipt of data is one of the 
key claims that DEX looses.  It would take an I3 to 'fix' this without 
R's HIP 'snooping' into the start of ESP traffic.  The end of I2 packets 
is only an ASSuMption of proof.

Note that DEX does not have PFS.  It does take the theft of both private 
keys to gain x & y of a recorded exchange.

I2 should probably be:

I2 ::= <--- t, Pn, Sn, PKr, PKi, ECR(PKr,n|x), MAC(x,(t, Pn, Sn, PKr, 
PKi, ECR(PKr,n|x)))

The adding of PKr 'helps' R in acting on I2 as it weakens a substitution 
attack on R1 by MR.  I think.

As implied by the datagram, the established key is x||y where || is some 
KEYMAT function built on the
MAC function (thus imposing constraints on x and y).

I feel a bit like diving off into the deep end of the pool without my 
swimming trunks properly tied.  But
I think I have a safe exchange.  And it is the barebones minimum in 
crypto functions.