Subject: [Hipsec] existential forgeries and HIP DEX

From: Robert Moskowitz <[email-masked]>
Date: Mon, 07 Jun 2010 16:20:33 -0400

I am working out a challenge in HIP DEX on the cfrg list....

Note that HIP DEX does NOT have a cryptographic hash function.  It's 
goal is to succeed with only a CMAC primative for all message reduction 
needs.

http://www.ietf.org/id/draft-mcgrew-fundamental-ecc-03.txt explains that 
a cryptographic hash is needed on the message before signing to avoid an 
existential forgery.  Huh what is that?  So a little searching gets the 
definition where Malice can generate the same signature as Bob, using 
only the public key.

At first blush, that does not seem to be an issue here, because R1, I2, 
and R2 are always signed, so what if Malice could have generated them too?

Then I realized that with existential forgeries, the signature, by 
itself, cannot be trusted to prove ownership of the private key.  More 
is needed.  That *more* could be proof of using the private key, eg 
decrypting a secret encrypted with the public key.  So I worked out the 
following R1through R2 exchange:

Bob or 
Malice                                                                
Alice or Malice2

  Sign (Bob's PK, stuff)  -------->
<----------- Sign(Alice's PK, (stuff, Encrypt(Bob's PK, secret), 
MAC(secret))
Bob only                                                                 
     Alice Only
  Sign (Bob's PK, (stuff, Encrypt(Alice's PK, secret2), MAC(secret))  
-------->
<-----------     Encrypt (secret|secret2, data)  -------->

This is the best I have done (so far).  It deviates from BEX in that the 
final keying material is NOT available in I2, only in R2.  This means 
that KEYMAT needs to be run twice.  A 'special' run for I2 and R2, then 
the 'real' run for all subsequent packets.

This DOES simplify getting keying material from the Responder.  I was 
doing it optionally in R1, when the Responder had I's PK in an ACL or 
some other source.  This is cleaner.