Public Keys to initiate IPsec.

["Eric Nielsen" <Eric.Nielsen@sylantro.com>]

I have been listening in on the IPsec discussion (as best as I can) for
some time, but I am sure my question/suggestion will show naivety to
many aspects of IPsec, but I must ask.

I am having trouble deciphering IPsec to determine the best way to 
deploy it in large scale. I have an idea of how it might work and would 
like to test these ideas out, or at least set me straight so I can find 
the best way to move forward deploying IPsec based security.

IPsec communications work well once setup. But key and session management 
is less straightforward. IKE, JFK, and IKEv2 provide means to bootstrap 
the process of setting up a secure connection, but I worry about the 
potential performance impacts of thousands of simultaneous restarts when 
a server recovers. Administration must be minimized, too.

The deployment in mind has 
 * > 10,000 clients to a server.  
 * The clients are small, embedded systems
 * Can make restriction that secure connections are always initiated by 
   the client
 * A trust relationship will persist with that client unless some 
   administrative action is taken to remove that trust.
 * Will use Transport mode AH

I would like some level of trust to persist beyond one point in time, or 
to be distributed among servers. I have focused on performing the IKE 
Phase 1 negotiations faster and simpler to administer: IKE Phase 1 
negotiations include:
 - negotiation of security parameters
 - establish a shared secret
 - authenticate identities. 

Here is a process that I think might perform that work.
=======================================================================

Step 1:
	Before setting up the network connection both sides would be 
provided a human password grade shared secret key, one that non-
technical people will not fear or mis-type. This is outside of IPsec.


Step 2: 
	To initiate the process of creating a secure communication path, 
the embedded unit would generate a large private/public key pair (e.g., 
RSA with at minimum 1028 bits). [an issue here is key randomness].


Step 3: 
	One end point will contact the other with negotiation parameters. 
In addition to the already defined parameters, that (big) packet would 
include:
 - the endpoint's public key
 - an [optional] endpoint identifier
 - a signature that covers the public key, endpoint ID, and private 
shared password.

The receiver will first validate the ID (it any) for:
  a) is the ID one that the server will service?
  b) is the ID is valid still for first-time initiation of a secure 
     relationship?
After this simple validation the receiver could then do the more 
processor intensive work validating the signature in the negotiation 
request. If the receiver does not include this capability, it will 
ignore these negotiation parameters and proceed down another path.


Step 4: 
	A response is crafted that selects this type of negotiation. The 
response includes the public key signed in the same way as in step 2.

Upon completion of Step 4 the two ends have authenticated, authorized, 
and have securely exchanged public keys. It looks like the two ends are 
ready for Phase 2 to create/share session keys. They may be symmetric 
keys for ESP or a private/public key pair for AH. 


Beyond Initialization:
	It would be best if the Phase 1 public keys were durable, being 
renegotiated only on an as needed basis. Phase 1 negotiations should 
persist past IP address changes. Each end can attempt to re-initiate 
Phase 1 to create a new durable public/private key pair. Each new key 
requires a signature using the prior durable key.  Either end can refuse 
the update by policy, and then have the option to terminate the trust 
relationship, thus requiring a new password to start the initialization 
process from square one.

This Phase 1 negotiated information may be shared among servers to 
assure smooth disaster recovery. Upon recovery the server receiving 
IPsec packets would reply that the session has expired and then recreate 
only the Phase 2 exchange.

========================================================================
All that said, is there a streamlined process like this I can implement 
within IPsec/IKE/IKEv2/JFK today? Are there key differences or security 
holes that may or may not make it possible to use this kind of process?

Thank you for your attention,

Eric


Eric Nielsen
Chief Technology Strategist
Sylantro Systems Corporation          http://www.sylantro.com
910 E. Hamilton Ave.
Campbell, CA  95008  USA
+1.408.626.2345