RE: Secret public keys

["David P. Kemp" <dpkemp@xxxxxxxxxxxxxx>]

> From: "Waters, Stephen" <Stephen.Waters@cabletron.com>
> 
> The problem I have now is mapping that id to the client's public key or
> certificate in a manageable way. I hope we can agree that managing
> public-key to id mapping can only be handled by using the CA/certificate
> approach.

It seems to me that the client must pass some sort of ID to the server,
and that the server must have some sort of client-specific data that is
*not* contained in a public certificate to enable XAUTH to work.  You
mentioned a large shared-secret value which could be unlocked on the
client by use of a short password; how is that shared-secret made known
to the server, in a manageable way?  If shared-secrets are manageable,
then a certificateless secret public key is just as manageable, using
the identical procedures.

Please describe exactly the steps you proposed for enabling a secondary
authentication exchange (XAUTH).  What data is stored on the client,
what is stored on the server, and what flows between them during the
IKE and XAUTH exchanges?

The question that began this thread was "does IKE+XAUTH have any
value-added over IKE alone?"  It's obvious that managing secrets
is more difficult than managing public data.  But I believe that
regardless of whether you choose to use secret information on the
server to eliminate the possibility of offline password guessing
attacks on the client, a secondary authentication exchange is
superfluous.  Whatever the requirements are, they can be satisfied
within IKE.