Kbrfw: failed to decrypt password

[Ken Raeburn]

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