[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Legacy auth methods support

At the Washington meeting, we discussed mechanisms to support legacy
  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
  while driving home (I live a good way out in the country--so I have
  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
  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
        sending an Entrust EPF file if you happen to use that
        If you have such an infrastructure, however, you likely don't
        this protocol.

  closes the connection

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

In the ephemeral case, the server could spend idle moments generating
  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".