[krbdev.mit.edu #3427] NAT causes password change to fail with Bad Address

[nate.yocom@centrify.com via RT]

Sam - Thanks for the response.  You are correct, in re-reading 4120
(3.5.2 I think) I realize I missed the "A failed match for either case
generates a KRB_AP_ERR_BADADDR error." sentence, and thought the address
was required within the message, but verification was not.

I understand your hesitation, but would stress that the default behavior
is unchanged by this patch - the address is still verified and a
KRB_AP_ERR_BADADDR still returned if the verification fails.  It takes
purposeful action on the part of the administrator (or whomever controls
the config) to change this behavior, and documentation could clearly
state the 'potential' security risks (as you say, I am not convinced
reflection is truly an issue here). 

However, the "fix" in using directional addresses is a MAY, not a MUST
according  to 4120 - so *requiring* that a KDC do this to work behind a
NAT isn't possible (regardless of whether its advisable).  This leaves a
situation where a KDC/client MAY work through a NAT if both agree on the
use of the unrequired section of the RFC.  I do think implementation of
directional addresses would be the long term solution, but I'd think it
would be advantageous to provide MIT users another way out in the
meantime, especially when using a non MIT KDC.

At least one other user has indicated this is what he does in his
private source tree (Ken Hornstein [kenh at cmf.nrl.navy.mil]), and it
wouldn't surprise me if there were others doing the same who haven't
spoken up.  I'm including Paul in this email as well, as he first found
the 'issue' and brought it up on the dev list.

Nate


-----Original Message-----
From: 0000-Admin [mailto:daemon at MIT.EDU] On Behalf Of Sam Hartman via RT
Sent: Friday, January 27, 2006 8:18 PM
To: Nate Yocom
Subject: Re: [krbdev.mit.edu #3427] NAT causes password change to fail
with Bad Address

Hi.  I'm very uncomfortable accepting this patch.  I definitely would
not want to accept a patch that always ignored the address for
krb5_rd_priv, and it would require significant convincing to decide that
a patch targeted at the change password protocol would be a good idea.

Not checking the source address is a direct violation of RFC 4120.
The reason the requirement is there is to avoid reflection attacks.
It's not clear to me that the password protocol is vulnerable to
reflection attacks however.



The right "fix" for this would be to implement directional addresses
(see RFC 4120) and to implement support for them in the change password
protocol.