[Openswan dev] msgids and IVs

Michael Richardson mcr at sandelman.ottawa.on.ca
Wed Feb 4 14:09:23 CET 2004


-----BEGIN PGP SIGNED MESSAGE-----


Andreas asked some questions in IRC about IVs and MSGIDs in pluto.

For openswan 2.0.0 and all FreeS/WAN, a state can have at most one 
active msgid. The phase 2 creates a new state.

Things like XAUTH confuse this - one could create a new "phase 1.5" 
state for XAUTH. However, it and modecfg can actually use several msgid.

Further, there are potential situations where an informational exchange
should be done with a new msgid, yet that is in fact part of phase 1.

Why do message ID's matter? Because they are used with the SKEY value to
produce the IKE encryption keys. (IKEv2 simplifies this whole thing)

Right now, state objects have:

    msgid_t            st_msgid;               /* MSG-ID from header.  Network Order! */

    u_char             st_iv[MAX_DIGEST_LEN];  /* IV for encryption */
    u_char             st_old_iv[MAX_DIGEST_LEN];  /* IV for encryption */
    u_char             st_new_iv[MAX_DIGEST_LEN];
    u_char             st_ph1_iv[MAX_DIGEST_LEN]; /* IV at end if phase 1 */

with the "st_ph1_iv" having been added very recently to save the state at
the end of phase 1, so that multiple phase 2 IV's can be created easily.

My suggestion is that we create a new structure:

   struct isakmp_cipher_context {
	  msgid_t       st_msgid;
	  u_char        st_iv[MAX_DIGEST_LEN];
	  unsigned int  st_iv_len;
	  err_t         st_iv_purpose;     /* for debugging/documentation */
   };

and that we have a small array of these in the "struct state". 
"find_state()" will check all of these. 

To do this, we require to know which isakmp_cipher_context is active.
   1) we can pass a pointer to this new structure around in many places where
      we only require "struct state" now.

   2) we can point to the right (active) one in a new st_icc variable.
      (either index or pointer)

   3) we can include "struct state *" back pointer in the above structure,
      and replace "struct state *" with "struct isakmp_cipher_context *"
      in most functions.

I do not propose to dynamically allocate these structures.

Alternatively, the situations that require more st_msgid could be changed to
use more state structures, but I think that this is messy.


{Paul, I just realized why the Vigor stuff kicked off the passerts.
 I'll bet that it uses SHA1 instead of MD5 in phase1, which we seldom
 test. I'm not even sure there are any controls to change the phase1
 proposals.}


]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson,    Xelerance Corporation, Ottawa, ON    |net architect[
] mcr at xelerance.com      http://www.sandelman.ottawa.on.ca/mcr/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Finger me for keys

iQCVAwUBQCFDWIqHRg3pndX9AQEXDQP/TPwrmlge7NQPyikhIEUAuqhOAaGgTLsA
C0HfSsLGSnSCKIsnL7nWaRrLrjtZD2gOgfUQ1CoP2Oq9rmh94NEmx3YHV7Y1bkGQ
X+pxi0qo22kGSkue+yStpybibG0NmZ/Eh8uzD8716tFPRmEixBzdh8T/RfZtqFuV
DBwvo+qlA9Q=
=Rnfc
-----END PGP SIGNATURE-----


More information about the Dev mailing list