Legacy auth methods support

["Marcus Leech" <mleech@xxxxxxxxxxxxxxxxxx>]

At the Washington meeting, we discussed mechanisms to support legacy
authentication
  methods that would:

    1) Require no changes to IKE
    2) Result in an acquisition of an appropriate certificate for use
with IKE

The discussion was started by Steve Bellovin, but I had some ideas last
night
  while driving home (I live a good way out in the country--so I have
time
  to think :-) )

I want to bounce some *technical* ideas off the list, and avoid any of
  the current politics.

The idea is to have a simple application-style protocol that rides on
top of
  TLS, with TLS operating in server-has-a-certificate mode.

The protocol would run something like this:

  client sends list of auth methods available to it

  server replies with a "go ahead" indicating the method to use

  client does the method (with possible multiple round trips if it's a
challenge/
  response type method)

  server sends either a "go away" and closes the connection or

  sends a certificate encoded as a PKCS#7 certificate-only message

  sends a corresponding private-key encoded in PKCS#8 format 

      --one could potentially make the exact format negotiable; like
just
        sending an Entrust EPF file if you happen to use that
infrastructure.
        If you have such an infrastructure, however, you likely don't
need
        this protocol.

  closes the connection

The certificates that the server sends would ideally be ephemeral, but
could
  also be long-term certs, in which case the client would use this
protocol
  once in a blue moon, and hold on to the results.

In the ephemeral case, the server could spend idle moments generating
key-pairs
  into a "pool" that is doled out as needed.   The interface to IKE
could be
  kept very simple--a simple policy that says "any valid cert issued by
  the cert server is OK with me".