krb5_rd_cred checks IP address.

[Booker C. Bense]

On Thu, 7 Feb 2002, Sam Hartman wrote:

>
>
> amu recently filed a Debian bug against my ssh-krb5 package
> complaining that when he forwarded addressless tickets from behind a
> NAT using ssh protocol version 1 to a new server, it didn't work.  It
> turns out all of those qualifiers are necessary to reproduce the bug;
> change one and it works fine.  Well, OK, if you get addressful tickets
> behind a NAT, it fails much earlier
>
>
> Here's the problem.  Our implementation of krb5_rd_cread checks the
> source address to make sure it matches the source address in the
> KRB-CRED structure.  It turns out it only does this if the krb-cred
> structure is encrypted.  It turns out that you'll only encrypt the
> structure under the ssh v1 forwarding mechanism when a new client
> talks to a new server.
>
> I'm not really sure what good this check does other than to screw over
> NAT users.  Even if we pretend that we actually still care about IP
> address authentication what is the harm of accepting tickets from
> someone provided that they work?

- I can't see one. The whole rational for the IP check is to make
replay attacks harder, but I don't grok how that would even apply
in this situation.

>
> I'm really not sure how to go about fixing this problem.  I could see
> solving in several ways and am not sure which one the community
> prefers.  Do we remove the check on the source address?

- I would vote for this option. The IP checks have always seemed to
me to be the wrong solution to replay attacks, it doesn't really
solve the problem. A session key cache does.

- Booker C. Bense