Copy: kerberos@mit.edu

On 5/26/2020 5:09 PM, Ken Dreyer wrote:

Hi folks,

In public cloud environments or Kubernetes environments, PTR records
are difficult or impossible for administrators to set. We increasingly
have to tell users to set "rdns = fallback" or "rdns = false".

As described in RFC4120 Section 1.3

https://tools.ietf.org/html/rfc4120#section-1.3

Kerberos implementations "MUST NOT use insecure DNS queries to
canonicalize the hostname components of the service principal names."

That said MIT and Heimdal have canonicalized hostnames using insecure
DNS since the beginning of time and changing the defaults will be sure
to break authentication for some unknown number of sites.

I'm wondering what the original purpose of Kerberos' rdns feature was.
Why would a client want or need to do hostname canonicalization?

There are two reasons that scream at me:

1. Before the introduction of Kerberos Referrals by Microsoft
(and later standardized and adopted by MIT, Heimdal, ...),
the clients required the PTR name in order to determine the
true "domain" for host domain to realm mapping. With Kerberos
referrals it is best if the Kerberos client sends the initial
service ticket request to a KDC in the client principal's
realm and allow the KDC to refer the client to the first
cross-realm hop if required.

There are still too many systems that have client-side
domain_realm mapping data that would break if "rdns" was turned
off.

2. Before the existence of DNS SRV records, CNAME records were the
only method of offering a service on multiple hosts. However,
its a poor idea to share the same key across all of the hosts.
In order to identify the name of the host that was contacted
the DNS PTR record is used. Even with the existence of SRV
records, too few application protocols use them.

Even for services that are hosted on a system system, CNAME
records are convenient to permit migration of services from an
old machine to a new one.

Again, disabling "rdns" by default will break an unknown number
of application clients.

I'm also wondering if we will ever be able to default MIT Kerberos'
rdns setting to "fallback" or "false" in a future version. IMHO this
would make it easier to deploy Kerberos applications in modern hosting environments.

I'm unaware of any OS distribution that ships with Kerberos that doesn't provide some default equivalent of "/etc/krb5.conf". Those
distributions can of course add whatever default settings it wants with appropriate documentation. If a distribution ships default krb5.conf
with "rdns = false", then an end user that replaces the default
krb5.conf with their organization's krb5.conf will not be broken. If
the hard coded default is changed, then installing the organization's
krb5.conf might not work as intended.

Jeffrey Altman



MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DJowggYBMIIE6aADAgECAhBAAWz+KYD2VMyFQOAs831nMA0GCSqGSIb3DQEBCwUAMDoxCzAJ BgNVBAYTAlVTMRIwEAYDVQQKEwlJZGVuVHJ1c3QxFzAVBgNVBAMTDlRydXN0SUQgQ0EgQTEy MB4XDTE5MDkwNDIxMjM0OFoXDTIyMTEwMjIxMjM0OFowgZUxNTAzBgNVBAsMLFZlcmlmaWVk IEVtYWlsOiBqYWx0bWFuQHNlY3VyZS1lbmRwb2ludHMuY29tMSswKQYJKoZIhvcNAQkBFhxq YWx0bWFuQHNlY3VyZS1lbmRwb2ludHMuY29tMS8wLQYKCZImiZPyLGQBARMfQTAxNDEwRDAw MDAwMTZDRkUyOTgwRTQwMDAwMzlFQjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB ALRdw150e8iZjFFewsrI/Q5nQtYINFrVpOdYR5RnrrNUvwRrBkkYcFwNWP/wzHOPiaFgthaX ydoQXKqFH0gZ6EaipfJ1L/r8NKAELVf1mTY7Yw+M6EuApsT9X8Ix6DPyhRc9D/rZ4KuBaszA gdpqdBYkkNlcogKPuM6jCzCHfOW3l9Hj1P98GjLmvhK7bDV56kz5NP13rFYe8dln9dvAKY/a MS1Ghrmvuu2VudoYgPPMXYWnhtrLhxuvLiGUXrKissrBuh3JedDdmSAPNrKxpgVP2m7TrH3u 4FY+MFO+Vv8Z9aGtz5FRdLObgQpq1IyQfoMBJtgqBeqaCkuQGCSJo/UCAwEAAaOCAqUwggKh MA4GA1UdDwEB/wQEAwIFoDCBhAYIKwYBBQUHAQEEeDB2MDAGCCsGAQUFBzABhiRodHRwOi8v Y29tbWVyY2lhbC5vY3NwLmlkZW50cnVzdC5jb20wQgYIKwYBBQUHMAKGNmh0dHA6Ly92YWxp ZGF0aW9uLmlkZW50cnVzdC5jb20vY2VydHMvdHJ1c3RpZGNhYTEyLnA3YzAfBgNVHSMEGDAW gBSkc9rvaTWKdcygGXsIMvhrieRC7DAJBgNVHRMEAjAAMIIBLAYDVR0gBIIBIzCCAR8wggEb BgtghkgBhvkvAAYLATCCAQowSgYIKwYBBQUHAgEWPmh0dHBzOi8vc2VjdXJlLmlkZW50cnVz dC5jb20vY2VydGlmaWNhdGVzL3BvbGljeS90cy9pbmRleC5odG1sMIG7BggrBgEFBQcCAjCB rgyBq1RoaXMgVHJ1c3RJRCBDZXJ0aWZpY2F0ZSBoYXMgYmVlbiBpc3N1ZWQgaW4gYWNjb3Jk YW5jZSB3aXRoIApJZGVuVHJ1c3QncyBUcnVzdElEIENlcnRpZmljYXRlIFBvbGljeSBmb3Vu ZCBhdCBodHRwczovL3NlY3VyZS5pZGVudHJ1c3QuY29tL2NlcnRpZmljYXRlcy9wb2xpY3kv dHMvaW5kZXguaHRtbDBFBgNVHR8EPjA8MDqgOKA2hjRodHRwOi8vdmFsaWRhdGlvbi5pZGVu dHJ1c3QuY29tL2NybC90cnVzdGlkY2FhMTIuY3JsMCcGA1UdEQQgMB6BHGphbHRtYW5Ac2Vj dXJlLWVuZHBvaW50cy5jb20wHQYDVR0OBBYEFM/QuJwMCA6dvJZmfEpnpbYkoY3iMB0GA1Ud JQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDANBgkqhkiG9w0BAQsFAAOCAQEAuAcupiA1Vgby jH7ldWXvQAHFyI3a2WUfHyPlPkVnFdyRKv8Fo4qwZ6xkHq49lnV6kRKVn88CCFCYb4XOpzUl Q0JXqzD+PYpM90MEixEpFZTVhRnnA9ypB87K16Pq2zEGmC6dyKYFQTS6lWiO5g5/xOPnO6mm mz3lRGXMuLKNSwThnR4fQcFJjV/yuJ0wCdFSHPRflxf3dZ44fkd/AFnA/99w+HpONT94ZR6k foemXuAHnYE9FmOotguxzAIcldwrR795fHTDDyRkiRqwVE7lh5YSkX1kImPMYuDTUw21D7HI mEJsb/+b3HGUpRrnrVOl9UXadEunddldgOp7UB2wUzCCBpEwggR5oAMCAQICEQD53lZ/yU0M d3D5YBtS2hU7MA0GCSqGSIb3DQEBCwUAMEoxCzAJBgNVBAYTAlVTMRIwEAYDVQQKEwlJZGVu VHJ1c3QxJzAlBgNVBAMTHklkZW5UcnVzdCBDb21tZXJjaWFsIFJvb3QgQ0EgMTAeFw0xNTAy MTgyMjI1MTlaFw0yMzAyMTgyMjI1MTlaMDoxCzAJBgNVBAYTAlVTMRIwEAYDVQQKEwlJZGVu VHJ1c3QxFzAVBgNVBAMTDlRydXN0SUQgQ0EgQTEyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEA0ZFNPM8KJzSSrkvpmtQla3ksT+fq1s9c+Ea3YSC/umUkygSm9UkkOoaoNjKZ oCx3wef1kwC4pQQV2XHk+AKR+7uMvnOCIw2cAVUP0/Kuy4X6miqaXGGVDTqwVjaFuFCRVVDT QoI2BTMpwFQi+O/TjD5+E0+TAZbkzsB7krk4YUbA6hFyT0YboxRUq9M2QHDb+80w53b1UZVO 1HS2Mfk9LnINeyzjxiXU/iENK07YvjBOxbY/ftAYPbv/9cY3wrpqZYHoXZc6B9/8+aVCNA45 FP3k+YuTDC+ZrmePQBLQJWnyS/QrZEdXsaieWUqkUMxPQKTExArCiP61YRYlOIMpKwIDAQAB o4ICgDCCAnwwgYkGCCsGAQUFBwEBBH0wezAwBggrBgEFBQcwAYYkaHR0cDovL2NvbW1lcmNp YWwub2NzcC5pZGVudHJ1c3QuY29tMEcGCCsGAQUFBzAChjtodHRwOi8vdmFsaWRhdGlvbi5p ZGVudHJ1c3QuY29tL3Jvb3RzL2NvbW1lcmNpYWxyb290Y2ExLnA3YzAfBgNVHSMEGDAWgBTt RBnA0/AGi+6ke75C5yZUyI42djAPBgNVHRMBAf8EBTADAQH/MIIBIAYDVR0gBIIBFzCCARMw ggEPBgRVHSAAMIIBBTCCAQEGCCsGAQUFBwICMIH0MEUWPmh0dHBzOi8vc2VjdXJlLmlkZW50 cnVzdC5jb20vY2VydGlmaWNhdGVzL3BvbGljeS90cy9pbmRleC5odG1sMAMCAQEagapUaGlz IFRydXN0SUQgQ2VydGlmaWNhdGUgaGFzIGJlZW4gaXNzdWVkIGluIGFjY29yZGFuY2Ugd2l0 aCBJZGVuVHJ1c3QncyBUcnVzdElEIENlcnRpZmljYXRlIFBvbGljeSBmb3VuZCBhdCBodHRw czovL3NlY3VyZS5pZGVudHJ1c3QuY29tL2NlcnRpZmljYXRlcy9wb2xpY3kvdHMvaW5kZXgu aHRtbDBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vdmFsaWRhdGlvbi5pZGVudHJ1c3QuY29t L2NybC9jb21tZXJjaWFscm9vdGNhMS5jcmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUF BwMEMA4GA1UdDwEB/wQEAwIBhjAdBgNVHQ4EFgQUpHPa72k1inXMoBl7CDL4a4nkQuwwDQYJ KoZIhvcNAQELBQADggIBAA3hgq7S+/TrYxl+D7ExI1Rdgq8fC9kiT7ofWlSaK/IMjgjoDfBb PGWvzdkmbSgYgXo8GxuAon9+HLIjNv68BgUmbIjwj/SYaVz6chA25XZdjxzKk+hUkqCmfOn/ twQJeRfxHg3I+0Sfwp5xs10YF0RobhrsCRne6OUmh9mph0fE3b21k90OVnx9Hfr+YAV4ISrT A6045zQTKGzb370whliPLFo+hNL6XzEty5hfdFaWKtHIfpE994CLmTJI4SEbWq40d7TpAjCm KCPIVPq/+9GqggGvtakM5K3VXNc9VtKPU9xYGCTDIYoeVBQ65JsdsdyM4PzDzAdINsv4vaF7 yE03nh2jLV7XAkcqad9vS4EB4hKjFFsmcwxa+ACUfkVWtBaWBqN4f/o1thsFJHEAu4Q6oRB6 mYkzqrPigPazF2rgYw3lp0B1gSzCRj+jRtErIVdMPeZ2p5Fdx7SNhBtabuhqmpJkFxwW9SBg 6sHvy0HpzVvEiBpApFKG1ZHXMwzQl+pR8P27wWDsblJU7Qgb8ZzGRK9l5GOFhxtN+oXZ4CCm unLMtaZ2vSai7du/VKrg64GGZNAKerEBevjJVNFgeSnmUK9GB4kCZ7U5NWlU+2H87scntW4Q /0Y6vqQJcJeaMHg/dQnahTQ2p+hB1xJJK32GWIAucTFMSOKLbQHadIOiMYIDFDCCAxACAQEw TjA6MQswCQYDVQQGEwJVUzESMBAGA1UEChMJSWRlblRydXN0MRcwFQYDVQQDEw5UcnVzdElE IENBIEExMgIQQAFs/imA9lTMhUDgLPN9ZzANBglghkgBZQMEAgEFAKCCAZcwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMjAwNTI2MjE1ODQ3WjAvBgkqhkiG 9w0BCQQxIgQgs64g1Ffn2mFYfkZWdn6hf6cECXN6wsoa0MPgiWUFom0wXQYJKwYBBAGCNxAE MVAwTjA6MQswCQYDVQQGEwJVUzESMBAGA1UEChMJSWRlblRydXN0MRcwFQYDVQQDEw5UcnVz dElEIENBIEExMgIQQAFs/imA9lTMhUDgLPN9ZzBfBgsqhkiG9w0BCRACCzFQoE4wOjELMAkG A1UEBhMCVVMxEjAQBgNVBAoTCUlkZW5UcnVzdDEXMBUGA1UEAxMOVHJ1c3RJRCBDQSBBMTIC EEABbP4pgPZUzIVA4CzzfWcwbAYJKoZIhvcNAQkPMV8wXTALBglghkgBZQMEASowCwYJYIZI AWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUr DgMCBzANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASCAQB5gNh5ry2l1KDsk3ep4gcC 2a92l9QRnPmRfFaKF+yEV/tBw+nWWw3P9OFrA6jHXU7X1UhSXrNRvMFk683eJq5nclbbKbyG JayYMI9u/JzQNM3Ox9m3AGmnEmi2PhSS7kiEf+khVJlPBJcmkGYdYznXJhOXAxu6CVzqznmv D/M9PM6SGN2W3n+0Fir4yYI+V1NmCIxm+8cGrwopcVznfK3Mpt5skAXu31ySm8+uXkELAIDo ygt5mxkImSxaBSjU7SS87Gzpb7yVO49FsCOkFaih5QPavD4ESZj8jlzqdk0BnlpnEDOUhh4R 1P+4hI9WelbSZCBHPd3PYrOcphX60EirAAAAAAAA

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Copy: kerberos@mit.edu

On Tue, May 26, 2020 at 3:56 PM Greg Hudson <ghudson@mit.edu> wrote:

On 5/26/20 5:09 PM, Ken Dreyer wrote:

In public cloud environments or Kubernetes environments, PTR records
are difficult or impossible for administrators to set. We increasingly
have to tell users to set "rdns = fallback" or "rdns = false".

Note that dns_canonicalize_hostname and rdns are separate settings. dns_canonicalize_hostname supports "fallback", but rdns only supports
true or false (and only takes effect when DNS canonicalization happens).

My bad, you're right. I meant dns_canonicalize_hostname=fallback.

I've found some public cloud providers with some very weird PTR
records for IP addresses that they hand out. These records are worse
than NXDOMAIN, and I was confused to see these in my logs.

- Ken

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Copy: kerberos@mit.edu

On Tue, May 26, 2020 at 3:58 PM Jeffrey Altman
<jaltman@secure-endpoints.com> wrote:

2. Before the existence of DNS SRV records, CNAME records were the
only method of offering a service on multiple hosts. However,
its a poor idea to share the same key across all of the hosts.

I'm curious about this. What makes it a poor idea?

It seems like a very convenient way to scale a service up and down
dynamically quickly when you share a key among all instances.

Again, disabling "rdns" by default will break an unknown number
of application clients.

Sure. My point is that it breaks the other way for modern
architectures where PTR records will never be under an application
developer's control. With Kubernetes a service can appear to clients
to move IPs very quickly. I'm not defending Kubernetes or anything
here, I'm wildly speculating that maybe breaking with the past is a
good idea as more applications and developers move in this direction.

- Ken

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Copy: kerberos@mit.edu

On 5/26/2020 6:31 PM, Ken Dreyer wrote:

On Tue, May 26, 2020 at 3:58 PM Jeffrey Altman
<jaltman@secure-endpoints.com> wrote:

2. Before the existence of DNS SRV records, CNAME records were the
only method of offering a service on multiple hosts. However,
its a poor idea to share the same key across all of the hosts.

I'm curious about this. What makes it a poor idea?

It seems like a very convenient way to scale a service up and down dynamically quickly when you share a key among all instances.

Because if you hack into one of the hosts you now have the key for all
of the hosts. The holder of the key can forge tickets for any user.
Since the key isn't unique the entire distributed service has to be
shutdown to address the vulnerability. It is also much harder to trace
where the key was stolen from.

There are scalable approaches to deriving unique keys for Kubernetes but
they aren't pertinent to this thread.

Again, disabling "rdns" by default will break an unknown number
of application clients.

Sure. My point is that it breaks the other way for modern
architectures where PTR records will never be under an application developer's control. With Kubernetes a service can appear to clients
to move IPs very quickly. I'm not defending Kubernetes or anything
here, I'm wildly speculating that maybe breaking with the past is a
good idea as more applications and developers move in this direction.

My point is that Kubernetes is new, and new deployments can add the
appropriate keys to their default configurations as Red Hat already does
on Fedora and Enterprise Linux.

If you change the hard coded default, then the existing deployed
installations that are relying on that default will silently break.
Since the breakage is on the client side that is being altered without knowledge of the service administrators, the administrators cannot fix it.




MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DJowggYBMIIE6aADAgECAhBAAWz+KYD2VMyFQOAs831nMA0GCSqGSIb3DQEBCwUAMDoxCzAJ BgNVBAYTAlVTMRIwEAYDVQQKEwlJZGVuVHJ1c3QxFzAVBgNVBAMTDlRydXN0SUQgQ0EgQTEy MB4XDTE5MDkwNDIxMjM0OFoXDTIyMTEwMjIxMjM0OFowgZUxNTAzBgNVBAsMLFZlcmlmaWVk IEVtYWlsOiBqYWx0bWFuQHNlY3VyZS1lbmRwb2ludHMuY29tMSswKQYJKoZIhvcNAQkBFhxq YWx0bWFuQHNlY3VyZS1lbmRwb2ludHMuY29tMS8wLQYKCZImiZPyLGQBARMfQTAxNDEwRDAw MDAwMTZDRkUyOTgwRTQwMDAwMzlFQjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB ALRdw150e8iZjFFewsrI/Q5nQtYINFrVpOdYR5RnrrNUvwRrBkkYcFwNWP/wzHOPiaFgthaX ydoQXKqFH0gZ6EaipfJ1L/r8NKAELVf1mTY7Yw+M6EuApsT9X8Ix6DPyhRc9D/rZ4KuBaszA gdpqdBYkkNlcogKPuM6jCzCHfOW3l9Hj1P98GjLmvhK7bDV56kz5NP13rFYe8dln9dvAKY/a MS1Ghrmvuu2VudoYgPPMXYWnhtrLhxuvLiGUXrKissrBuh3JedDdmSAPNrKxpgVP2m7TrH3u 4FY+MFO+Vv8Z9aGtz5FRdLObgQpq1IyQfoMBJtgqBeqaCkuQGCSJo/UCAwEAAaOCAqUwggKh MA4GA1UdDwEB/wQEAwIFoDCBhAYIKwYBBQUHAQEEeDB2MDAGCCsGAQUFBzABhiRodHRwOi8v Y29tbWVyY2lhbC5vY3NwLmlkZW50cnVzdC5jb20wQgYIKwYBBQUHMAKGNmh0dHA6Ly92YWxp ZGF0aW9uLmlkZW50cnVzdC5jb20vY2VydHMvdHJ1c3RpZGNhYTEyLnA3YzAfBgNVHSMEGDAW gBSkc9rvaTWKdcygGXsIMvhrieRC7DAJBgNVHRMEAjAAMIIBLAYDVR0gBIIBIzCCAR8wggEb BgtghkgBhvkvAAYLATCCAQowSgYIKwYBBQUHAgEWPmh0dHBzOi8vc2VjdXJlLmlkZW50cnVz dC5jb20vY2VydGlmaWNhdGVzL3BvbGljeS90cy9pbmRleC5odG1sMIG7BggrBgEFBQcCAjCB rgyBq1RoaXMgVHJ1c3RJRCBDZXJ0aWZpY2F0ZSBoYXMgYmVlbiBpc3N1ZWQgaW4gYWNjb3Jk YW5jZSB3aXRoIApJZGVuVHJ1c3QncyBUcnVzdElEIENlcnRpZmljYXRlIFBvbGljeSBmb3Vu ZCBhdCBodHRwczovL3NlY3VyZS5pZGVudHJ1c3QuY29tL2NlcnRpZmljYXRlcy9wb2xpY3kv dHMvaW5kZXguaHRtbDBFBgNVHR8EPjA8MDqgOKA2hjRodHRwOi8vdmFsaWRhdGlvbi5pZGVu dHJ1c3QuY29tL2NybC90cnVzdGlkY2FhMTIuY3JsMCcGA1UdEQQgMB6BHGphbHRtYW5Ac2Vj dXJlLWVuZHBvaW50cy5jb20wHQYDVR0OBBYEFM/QuJwMCA6dvJZmfEpnpbYkoY3iMB0GA1Ud JQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDANBgkqhkiG9w0BAQsFAAOCAQEAuAcupiA1Vgby jH7ldWXvQAHFyI3a2WUfHyPlPkVnFdyRKv8Fo4qwZ6xkHq49lnV6kRKVn88CCFCYb4XOpzUl Q0JXqzD+PYpM90MEixEpFZTVhRnnA9ypB87K16Pq2zEGmC6dyKYFQTS6lWiO5g5/xOPnO6mm mz3lRGXMuLKNSwThnR4fQcFJjV/yuJ0wCdFSHPRflxf3dZ44fkd/AFnA/99w+HpONT94ZR6k foemXuAHnYE9FmOotguxzAIcldwrR795fHTDDyRkiRqwVE7lh5YSkX1kImPMYuDTUw21D7HI mEJsb/+b3HGUpRrnrVOl9UXadEunddldgOp7UB2wUzCCBpEwggR5oAMCAQICEQD53lZ/yU0M d3D5YBtS2hU7MA0GCSqGSIb3DQEBCwUAMEoxCzAJBgNVBAYTAlVTMRIwEAYDVQQKEwlJZGVu VHJ1c3QxJzAlBgNVBAMTHklkZW5UcnVzdCBDb21tZXJjaWFsIFJvb3QgQ0EgMTAeFw0xNTAy MTgyMjI1MTlaFw0yMzAyMTgyMjI1MTlaMDoxCzAJBgNVBAYTAlVTMRIwEAYDVQQKEwlJZGVu VHJ1c3QxFzAVBgNVBAMTDlRydXN0SUQgQ0EgQTEyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEA0ZFNPM8KJzSSrkvpmtQla3ksT+fq1s9c+Ea3YSC/umUkygSm9UkkOoaoNjKZ oCx3wef1kwC4pQQV2XHk+AKR+7uMvnOCIw2cAVUP0/Kuy4X6miqaXGGVDTqwVjaFuFCRVVDT QoI2BTMpwFQi+O/TjD5+E0+TAZbkzsB7krk4YUbA6hFyT0YboxRUq9M2QHDb+80w53b1UZVO 1HS2Mfk9LnINeyzjxiXU/iENK07YvjBOxbY/ftAYPbv/9cY3wrpqZYHoXZc6B9/8+aVCNA45 FP3k+YuTDC+ZrmePQBLQJWnyS/QrZEdXsaieWUqkUMxPQKTExArCiP61YRYlOIMpKwIDAQAB o4ICgDCCAnwwgYkGCCsGAQUFBwEBBH0wezAwBggrBgEFBQcwAYYkaHR0cDovL2NvbW1lcmNp YWwub2NzcC5pZGVudHJ1c3QuY29tMEcGCCsGAQUFBzAChjtodHRwOi8vdmFsaWRhdGlvbi5p ZGVudHJ1c3QuY29tL3Jvb3RzL2NvbW1lcmNpYWxyb290Y2ExLnA3YzAfBgNVHSMEGDAWgBTt RBnA0/AGi+6ke75C5yZUyI42djAPBgNVHRMBAf8EBTADAQH/MIIBIAYDVR0gBIIBFzCCARMw ggEPBgRVHSAAMIIBBTCCAQEGCCsGAQUFBwICMIH0MEUWPmh0dHBzOi8vc2VjdXJlLmlkZW50 cnVzdC5jb20vY2VydGlmaWNhdGVzL3BvbGljeS90cy9pbmRleC5odG1sMAMCAQEagapUaGlz IFRydXN0SUQgQ2VydGlmaWNhdGUgaGFzIGJlZW4gaXNzdWVkIGluIGFjY29yZGFuY2Ugd2l0 aCBJZGVuVHJ1c3QncyBUcnVzdElEIENlcnRpZmljYXRlIFBvbGljeSBmb3VuZCBhdCBodHRw czovL3NlY3VyZS5pZGVudHJ1c3QuY29tL2NlcnRpZmljYXRlcy9wb2xpY3kvdHMvaW5kZXgu aHRtbDBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vdmFsaWRhdGlvbi5pZGVudHJ1c3QuY29t L2NybC9jb21tZXJjaWFscm9vdGNhMS5jcmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUF BwMEMA4GA1UdDwEB/wQEAwIBhjAdBgNVHQ4EFgQUpHPa72k1inXMoBl7CDL4a4nkQuwwDQYJ KoZIhvcNAQELBQADggIBAA3hgq7S+/TrYxl+D7ExI1Rdgq8fC9kiT7ofWlSaK/IMjgjoDfBb PGWvzdkmbSgYgXo8GxuAon9+HLIjNv68BgUmbIjwj/SYaVz6chA25XZdjxzKk+hUkqCmfOn/ twQJeRfxHg3I+0Sfwp5xs10YF0RobhrsCRne6OUmh9mph0fE3b21k90OVnx9Hfr+YAV4ISrT A6045zQTKGzb370whliPLFo+hNL6XzEty5hfdFaWKtHIfpE994CLmTJI4SEbWq40d7TpAjCm KCPIVPq/+9GqggGvtakM5K3VXNc9VtKPU9xYGCTDIYoeVBQ65JsdsdyM4PzDzAdINsv4vaF7 yE03nh2jLV7XAkcqad9vS4EB4hKjFFsmcwxa+ACUfkVWtBaWBqN4f/o1thsFJHEAu4Q6oRB6 mYkzqrPigPazF2rgYw3lp0B1gSzCRj+jRtErIVdMPeZ2p5Fdx7SNhBtabuhqmpJkFxwW9SBg 6sHvy0HpzVvEiBpApFKG1ZHXMwzQl+pR8P27wWDsblJU7Qgb8ZzGRK9l5GOFhxtN+oXZ4CCm unLMtaZ2vSai7du/VKrg64GGZNAKerEBevjJVNFgeSnmUK9GB4kCZ7U5NWlU+2H87scntW4Q /0Y6vqQJcJeaMHg/dQnahTQ2p+hB1xJJK32GWIAucTFMSOKLbQHadIOiMYIDFDCCAxACAQEw TjA6MQswCQYDVQQGEwJVUzESMBAGA1UEChMJSWRlblRydXN0MRcwFQYDVQQDEw5UcnVzdElE IENBIEExMgIQQAFs/imA9lTMhUDgLPN9ZzANBglghkgBZQMEAgEFAKCCAZcwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMjAwNTI2MjI1OTI1WjAvBgkqhkiG 9w0BCQQxIgQgGfXTaZkBVIjjSRfvntmfJsN/DPFEsepKesdPQ6tUM0swXQYJKwYBBAGCNxAE MVAwTjA6MQswCQYDVQQGEwJVUzESMBAGA1UEChMJSWRlblRydXN0MRcwFQYDVQQDEw5UcnVz dElEIENBIEExMgIQQAFs/imA9lTMhUDgLPN9ZzBfBgsqhkiG9w0BCRACCzFQoE4wOjELMAkG A1UEBhMCVVMxEjAQBgNVBAoTCUlkZW5UcnVzdDEXMBUGA1UEAxMOVHJ1c3RJRCBDQSBBMTIC EEABbP4pgPZUzIVA4CzzfWcwbAYJKoZIhvcNAQkPMV8wXTALBglghkgBZQMEASowCwYJYIZI AWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUr DgMCBzANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASCAQAMrFnwwdaWSZa9JSMpHHn0 zByE/03V0Y2Nr/Uz2Y5DPqy49XpJIlYBXNlzCrY3tt0woCLJ/7hBxnU/MFnTF8pyFQwL5xgj cOcFv6kBHCnvJAk3m02McI0u6JUXJhn2pSGXaf2Hc190kCxGqIfWte5bt9cIV0OuRtXy2C+J 8PKS9gHSjoDg9qlR4VKP34B7jSpRQvEHZ8mMURCOGhoROSr+2b/GDBCcttoYZSM6RosmuNbN SX8lU0ubO0B4QELln72bxdg9UJPRzGlAf46R2enjg0bhcFZqg/6n3QsA8W+BG3DTugw5eiFA uO1ItUGJfh665d+vtktk5O/4c4PAeFC2AAAAAAAA

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, May 26 2020 at 18:59:23 -0400, Jeffrey Altman scribbled
in "Re: rdns, past and future":

On 5/26/2020 6:31 PM, Ken Dreyer wrote:

On Tue, May 26, 2020 at 3:58 PM Jeffrey Altman <jaltman@secure-endpoints.com> wrote:

2. Before the existence of DNS SRV records, CNAME records were the
only method of offering a service on multiple hosts. However,
its a poor idea to share the same key across all of the hosts.

I'm curious about this. What makes it a poor idea?

It seems like a very convenient way to scale a service up and down dynamically quickly when you share a key among all instances.

Because if you hack into one of the hosts you now have the key for
all of the hosts. The holder of the key can forge tickets for any
user. Since the key isn't unique the entire distributed service has
to be shutdown to address the vulnerability. It is also much harder
to trace where the key was stolen from.

Also, as another simpler example, it can make key management more
involved, rather than more convenient:

Moving and sharing sensitive material around is awkward, but running
`ktadd` on a new cluster member is trivial -- but if you're using a
shared key across all cluster members, you've broken them all except
the newest member (as `ktadd` does an implicit randkey). I've seen
too many fresh sysadmins break things that way...

Cheers.

Dameon.

--

<> ><> ><> ><> ><> ><> ooOoo <>< <>< <>< <>< <>< <><

Dr. Dameon Wagner, Unix Platform Services
IT Services, University of Oxford

<> ><> ><> ><> ><> ><> ooOoo <>< <>< <>< <>< <>< <><

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Copy: kerberos@mit.edu

On Tue, May 26, 2020 at 4:59 PM Jeffrey Altman
<jaltman@secure-endpoints.com> wrote:

On 5/26/2020 6:31 PM, Ken Dreyer wrote:

On Tue, May 26, 2020 at 3:58 PM Jeffrey Altman <jaltman@secure-endpoints.com> wrote:

2. Before the existence of DNS SRV records, CNAME records were the
only method of offering a service on multiple hosts. However,
its a poor idea to share the same key across all of the hosts.

I'm curious about this. What makes it a poor idea?

It seems like a very convenient way to scale a service up and down dynamically quickly when you share a key among all instances.

Because if you hack into one of the hosts you now have the key for all
of the hosts. The holder of the key can forge tickets for any user.

This is true only if the administrator has enabled constrained
delegation for that key (eg. ok_to_auth_as_delegate) right? Is there
some other scenario I'm missing?

Since the key isn't unique the entire distributed service has to be
shutdown to address the vulnerability.

Ok, that makes sense. I was thinking of a homogeneous environment
where each app server runs the exact same versions of code, so an
attacker entry through a vulnerability on one system means that all
systems almost certainly have the same vulnerability.

It is also much harder to trace where the key was stolen from.

Yeah, that's fair.

- Ken

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

To: jaltman@secure-endpoints.com (Jeffrey Altman)
Copy: kerberos@mit.edu

On Wed, 2020-05-27 at 11:59 -0600, Ken Dreyer wrote:

On Tue, May 26, 2020 at 4:59 PM Jeffrey Altman
<jaltman@secure-endpoints.com> wrote:

On 5/26/2020 6:31 PM, Ken Dreyer wrote:

On Tue, May 26, 2020 at 3:58 PM Jeffrey Altman <jaltman@secure-endpoints.com> wrote:

2. Before the existence of DNS SRV records, CNAME records were the
only method of offering a service on multiple hosts. However,
its a poor idea to share the same key across all of the hosts.

I'm curious about this. What makes it a poor idea?

It seems like a very convenient way to scale a service up and down dynamically quickly when you share a key among all instances.

Because if you hack into one of the hosts you now have the key for all
of the hosts. The holder of the key can forge tickets for any user.

This is true only if the administrator has enabled constrained
delegation for that key (eg. ok_to_auth_as_delegate) right? Is there
some other scenario I'm missing?

If you own a service key, you can forge a ticket from any user to
yourself without any issue. This of course is not an issue, as there is
no point in breaking into yourself.

If multiple services use the same key then you can forge tickets by any
user to any those services if you stole the common key. This is now a
bad thing because you can jump from one system to another at this
point.

That said, in the kubernetes case, the multiple services are *not*
actually distinct services, they are generally a single service
implemented by multiple containers for scaling purposes. For all intent
and purposes in a kubernets environment sharing the key is not as
disastrous. Once you break into one container you already broke into
that service layer as a whole as you usually get access to other shared
keys (database access for example).

Since the key isn't unique the entire distributed service has to be shutdown to address the vulnerability.

Ok, that makes sense. I was thinking of a homogeneous environment
where each app server runs the exact same versions of code, so an
attacker entry through a vulnerability on one system means that all
systems almost certainly have the same vulnerability.

Exactly, in the special case where sharing happens within the confines
of the same security domain essentially for scaling reasons, you can
definitely make the choice of sharing keys.

It is also much harder to trace where the key was stolen from.

Yeah, that's fair.

In kubernetes you usually have better telemetry than classic systems,
and is normally remoted from the stateless container, which means it is
much harder to alter to cover tracks, so perhaps this concern/risk can
also be better managed there, if you care for it.

Simo.

--
Simo Sorce
RHEL Crypto Team
Red Hat, Inc

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)