On Fri, Nov 28, 2014 at 12:54 AM, Rick van Rein <r...@openfortress.nl> wrote:
> Hi Frank, > > > I didn't read the document, but from the name of it the EAP-GSS method I > noted earlier would be a true Kerberos authentication -- the client has to > pass on a kerberos token, not a password. It sounded like that's what you > were going after. > > Yes, it is, ideally. > > > I'm wouldn't be surprised if this isn't well > implemented/supported/documented. It would require the KDC to be out in > the open (to get the ticket used for the VPN auth) and most folks aren't > going to do that. > > Interesting observation. When we go cross-realm, we’ll have to open our > KDCs to the public… at least the TGS part, but that’s undistinguishable > from the AS part (same SRV record)… > I has a passing though to mention, but decided against it, that yeah cross-realm is the one place I could see this being more likely. A couple of years ago I did a [proprietary] implementation of a TGS-only server designed to sit on the public Internet. The idea was to do a more traditional web auth (sending password to server) to a tried and true web auth front-end, and you'd get back a token which an extension would pass on to the TGS server and give you a ticket. Through a bit of convolution this could then be dropped in the filesystem. There were numerous advantages to this approach for our environment, however we never deployed it. I should have written a brief paper at the time. ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos