[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
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
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
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
kept very simple--a simple policy that says "any valid cert issued by
the cert server is OK with me".