On Nov 14, 2008, at 11:42, Robert Marcano wrote: > yes that was the reason, Windows was running on an VM (virtualbox.org) > on my laptop connected to the net using NAT. So this test passed :-), > but I think this will cause me a little trouble on production when a > user is behind of one of those wireless routers that do NAT by default
Yeah, it's a problem. The original Kerberos 5 protocol was designed when NATs weren't much of an issue, and when including an IP address was thought to be a (more) helpful additional security measure. The revised spec (RFC 4120) fudges it by defining new "address" types that merely identify one party as the initiator of the authentication exchange and the other as the recipient, but MIT has not implemented this yet; I don't know if anyone else has. (There are also backwards compatibility issues to deal with, in case you're trying to talk to an implementation that doesn't yet know about these directional addresses -- how do you know when you can use the directional addresses? Or does the application-level code just have to try it twice?) And fixing this hasn't, unfortunately, bubbled up to the top of the Consortium's priority list just yet. Patches are welcome though. :-) I don't expect it to necessarily be helpful in your case, but VPN software may help -- or may hurt. If it gives the application a non- NATted address on the enterprise network, the Kerberos library may be able to determine the network address that the KDC will see the message as coming from. But on the other hand, some VPN software makes it difficult to figure out what that assigned address is, and will similarly cause things to break even if no NAT was involved in the first place. Ken ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos