[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: (ITS#5812) New option to disable SASL host canonicalization
------=_Part_45002_9684276.1226844472048
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
On Sun, Nov 16, 2008 at 2:25 AM, Howard Chu <hyc@symas.com> wrote:
> That is completely irrelevant. If a given site has a misconfigured DNS,
> whether or not it uses integrity or privacy checks on the DNS service, it is
> still misconfigured.
My point was that even if your reverse DNS mappings are correct, this is not
a sufficient base for canonicalization. as it would have to be secure too.
Or would you consider a DNS setup without DNSSEC to be broken too? In that
case 99% of all setups would be broken.
To maximize interoperability and security, applications SHOULD provide
> security
> mechanisms with names that result from folding the user- entered name to
> lowercase without performing any other modifications or canonicalization.
>
Wishful thinking; that recommendation is at least 15 years too late and the
> majority of Kerberized software isn't going to change to accommodate it.
Not everybody needs to do this at once. MIT Kerberos already supports
multiple ways of canonicalizing, including reverse DNS and the Canonicalize
bit. Applications can start supporting this one by one.
> In the meantime, the arguments about secure DNS are pure red herrings:
> 1. if your DNS has been hijacked, it's most likely that you'll be directed
> to a rogue KDC first, so the question of which service you're talking to is
> moot.
Wrong. Kerberos protects against that. A rogue KDC would not have your
secret key and therefore is unable to generate a correct ticket for you.
This would get noticed immediately by the library and the handshake would be
aborted.
> 2. there's nothing to gain from directing you to a rogue service, since
> if you managed to contact the legitimate KDC, you're going to have a service
> ticket that can only be decoded by the legitimate service principal.
> On the other hand, if the rogue service is actually a valid principal in
> your trusted KDC's database, then you clearly have an administrative problem
> in your KDC.
>
Ok, so let me show you a real attack scenario as it indeed requires one
copromised server. Supose an attacker has compromised one system in a
Kerberos realm that was running a Kerberos service. The attacker can now
spoof reverse DNS based on any of the available methods, and use it to
redirect any internal service to a service on his server. He now puts up a
mock up of the original service on the comprimised server, and coaxes users
into entering any data that he would only enter in the real service. He can
use this data to expand his compromised systems.
If you would use secure canonicalization, the above cannot happen. It limits
the scope of a compromise to that server. Without security canonicalization
this is basically all-or-nothing security which is bad.
This patch attempts to provide a band-aid without actually solving the real
> problem. It merely masks the problem temporarily, until it gets even worse.
No. From a security point it limits the impact of a comprimise of one server
in your environment. From other point of views it helps environments that
use the current best practise albeit broken method of canonicalizing host
name.
> This request is akin to asking for "schemachecking off" to be resurrected.
> This sort of feature is always requested because of an existing mistake, and
> allowing it only compounds the mistake further. We should never make it
> easier for admins to make and ignore mistakes.
This analogy does not work. The proposed option provides the possibility to
implement a recommendation from the Kerberos RFC. Where in the LDAP RFCs
does it say that it is recommended to turn schemachecking off?
Regards,Geert
------=_Part_45002_9684276.1226844472048
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
On Sun, Nov 16, 2008 at 2:25 AM, Howard Chu <span dir="ltr"><<a href="mailto:hyc@symas.com";>hyc@symas.com</a>></span> wrote:<br><div class="gmail_quote"> <br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
That is completely irrelevant. If a given site has a misconfigured DNS, whether or not it uses integrity or privacy checks on the DNS service, it is still misconfigured.</blockquote><div class="Ih2E3d"><br>My point was that even if your reverse DNS mappings are correct, this is not a sufficient base for canonicalization. as it would have to be secure too. Or would you consider a DNS setup without DNSSEC to be broken too? In that case 99% of all setups would be broken.<br>
<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
To maximize interoperability and security, applications SHOULD provide security<br>
mechanisms with names that result from folding the user- entered name to<br>
lowercase without performing any other modifications or canonicalization.<br>
</blockquote>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Wishful thinking; that recommendation is at least 15 years too late and the majority of Kerberized software isn't going to change to accommodate it.</blockquote><div><br>Not everybody needs to do this at once. MIT Kerberos already supports multiple ways of canonicalizing, including reverse DNS and the Canonicalize bit. Applications can start supporting this one by one.<br>
</div><div> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
In the meantime, the arguments about secure DNS are pure red herrings:<br>
1. if your DNS has been hijacked, it's most likely that you'll be directed to a rogue KDC first, so the question of which service you're talking to is moot.</blockquote><div><br>Wrong. Kerberos protects against that. A rogue KDC would not have your secret key and therefore is unable to generate a correct ticket for you. This would get noticed immediately by the library and the handshake would be aborted.<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
2. there's nothing to gain from directing you to a rogue service, since if you managed to contact the legitimate KDC, you're going to have a service ticket that can only be decoded by the legitimate service principal.</blockquote>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
On the other hand, if the rogue service is actually a valid principal in your trusted KDC's database, then you clearly have an administrative problem in your KDC.<br></blockquote><div><br>Ok, so let me show you a real attack scenario as it indeed requires one copromised server. Supose an attacker has compromised one system in a Kerberos realm that was running a Kerberos service. The attacker can now spoof reverse DNS based on any of the available methods, and use it to redirect any internal service to a service on his server. He now puts up a mock up of the original service on the comprimised server, and coaxes users into entering any data that he would only enter in the real service. He can use this data to expand his compromised systems.<br>
<br>If you would use secure canonicalization, the above cannot happen. It limits the scope of a compromise to that server. Without security canonicalization this is basically all-or-nothing security which is bad.<br><br></div>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
This patch attempts to provide a band-aid without actually solving the real problem. It merely masks the problem temporarily, until it gets even worse.</blockquote><div><br>No. From a security point it limits the impact of a comprimise of one server in your environment. From other point of views it helps environments that use the current best practise albeit broken method of canonicalizing host name. <br>
</div><div> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
This request is akin to asking for "schemachecking off" to be resurrected. This sort of feature is always requested because of an existing mistake, and allowing it only compounds the mistake further. We should never make it easier for admins to make and ignore mistakes.</blockquote>
<div><br>This analogy does not work. The proposed option provides the possibility to implement a recommendation from the Kerberos RFC. Where in the LDAP RFCs does it say that it is recommended to turn schemachecking off?<br>
<br>Regards,Geert</div></div><br>
------=_Part_45002_9684276.1226844472048--