RE: Public Keys to initiate IPsec.

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

Thanks for the pointers.

After reading thru PKIX and SCEP, and being reinforced by Alex
Alten's message today RE: addresses and IKEv2, it is clear
a key element of my problem is associating the application's 
endpoint name with the security key, but not the dynamically
provided IP address. The endpoint name is not in DNS, and
customer premise DHCP is outside of our control.

When the endpoint's IP address changes the client app. reregisters.
Upon each regstriation a new session key and SA should be created.
At all other times the secure session needs to be up 24x7x365. 

It looks like the regsitration process must always be initiated
without security so that an entry can be put into the IPsecConfig
updating the new mapping of IP address to key. It also seems like
a potential DoS mechanism to act based on this unauthenticated
registration message. 

It would be best that prior to registration a new SA is created
that links the (non-DNS) endpoint name to a shared private or
public key. Extra work and changes to configurations would not
be needed based on unauthenticated messages. 

It looks like SCEP is about the right weight for key management
using LDAP for storage. But then anoterh protocol is required,
and all intervening firewalls need to allow it. More possibilities
for error. It would be nice if this level of key management could
be performed over the IPsec link.  Can a public certificate be 
associated with an application name/URI that does not exist in DNS?

Eric


-----Original Message-----
From: Greg Carter
To: ipsec@lists.tislabs.com
Sent: 5/31/02 8:18 PM
Subject: Re: Public Keys to initiate IPsec.


----- Original Message -----
From: "Eric Nielsen" <Eric.Nielsen@sylantro.com>
Subject: Public Keys to initiate IPsec.

>They may be symmetric keys for ESP or a private/public key pair for AH.
AH uses symmetric based cryptography.

>
========================================================================
> All that said, is there a streamlined process like this I can
implement
> within IPsec/IKE/IKEv2/JFK today?

Not really, at least not in IKE v1.

>Are there key differences or security
> holes that may or may not make it possible to use this kind of
process?

What you have describe as your phase one is in essence a PKI and
enrolling a
client into that PKI with the one time password.  IKE assumes that you
already have the trust relationship in place, either through a shared
key or
via a certified public key.  All(!)you are doing in IKE is verifying the
identity, you are not managing the identities credentials within your
trust
'hierarchy'.  Combining the two operations would unnecessarily
complicate
IKE.

Check out the PKIX working group, specifically RFC 2510, and/or RFC
2797.
But I would look into finding more about SCEP before implementing 2797
if
you want an "on line" enrolment protocol.

Bye.
Greg.