> Brian, the earlier suggestion to use IPsec to your servers sounds
> like an elegant approach, but sounds like you may have rather
> too many client machines to make this practical.
> As a much simpler alternative, and one that is SSL based (and hence
> X.509 cert public key encryption based for easy deployment), you
> could use openVPN. openVPN works well, and easily, on Windows and
> lots of Unixes.
> You wouldn't need to make any code changes - just some network config.
> Our experiences with openVPN are very positive.
> I guess we Kerberos fans would prefer to see an integrated Kerberos
> solution (SSL sessions, without client authentication, for otherwise
> normal Kerberos transactions perhaps ? We use that approach in a custom
> banking application, but the code isn't general I'm afraid). But as
> you said you can't change your KDC servers.
This(as-req tunneled over SSL without client authentication) is
something that my site would be interested in as well. we however are
interested in combining this with a pre-auth method that would actually
send the password to the kdc(over the SSL tunnel) for use with one time
passwords. I know that the idea of a "null" pre-auth method that sends a
password to the kdc would be a horrible thing if that communication
isn't otherwise protected, but if client libraries refuse to generate
such requests without already having established a secure communication
channel with the kdc, and KDCs are unwilling to issue TGTs based on such
requests unless there is an already established secure communication
channel, do people still find such an auth method un-palatable?
If people are interested in discussing what something like this should
look like, I would like to look into it some more. perhaps this should
be moved to the ietf-krb-wg? I've cc:ed that list as well in case there
is interest there by someone who is not paying attention to this list.