Password changing from behind a NAT
kenh at cmf.nrl.navy.mil
Mon Oct 20 11:59:15 EDT 2003
>We do not consider this a solution because of the reflection problems.
So, I had to look at this to understand the risks here.
There's a replay cache on the server. Assuming the client doesn't reuse
a session key (unlikely, I think), there shouldn't be any risk for the
server's response to be reflected back to the server. So the only risk
here I can see is the client's request reflected back to itself.
The first two bytes of the expected response are the error code; the
rest is a plain-text error message. The worst I can imagine here is
that if the requested password was reflected back to the client, the
client would interpret it as a strange error code and error message,
and would think that the password change failed, when it really
succeeded. That's a risk I'm personally willing to live with.
>My recommendation would be to implement directional address support on
>the server all the time, and to cause clients to send directional
>addresses if they notice they are using a private address and talking
>to something on a public address. Long term, we can always use
>directional addresses, but that creates interop problems now.
Doesn't really do anything for deployed clients now, though, which
is my real problem.
More information about the krbdev