[38752] in Kerberos
Re: Replacing master/slave terminology
daemon@ATHENA.MIT.EDU (Jeffrey Altman)
Wed Jun 10 20:03:45 2020
X-Envelope-From: jaltman@secure-endpoints.com
X-MDaemon-Deliver-To: kerberos@mit.edu
To: "Nate Coraor (nate@bx.psu.edu)" <nate@bx.psu.edu>,
Greg Hudson <ghudson@mit.edu>
From: Jeffrey Altman <jaltman@secure-endpoints.com>
Message-ID: <e75c9bce-fc28-3f34-3671-06639e87b396@secure-endpoints.com>
Date: Wed, 10 Jun 2020 20:00:38 -0400
MIME-Version: 1.0
In-Reply-To: <CALT861Fwi=XpK2pW=nc0ZDzMePLBwoA_JrQW2F_i2nOGdishjA@mail.gmail.com>
Cc: kerberos@mit.edu
Content-Type: multipart/mixed; boundary="===============7691683585581263711=="
Errors-To: kerberos-bounces@mit.edu
--===============7691683585581263711==
Content-Type: multipart/signed; protocol="application/pkcs7-signature";
micalg=sha-256; boundary="------------ms090601090703060408080603"
--------------ms090601090703060408080603
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
On 6/10/2020 5:26 PM, Nate Coraor (nate@bx.psu.edu) wrote:
> On Wed, Jun 10, 2020 at 5:04 PM Greg Hudson <ghudson@mit.edu> wrote:
>=20
>> MIT krb5 switched to using "replica" for non-primary KDCs as of releas=
e
>> 1.17. This was an easy change technically, as the old term was only
>> used in a user-visible way in documentation and in the name of one
>> profile relation. The pull request for that change was here:
>> https://github.com/krb5/krb5/pull/851
>=20
>=20
> Hi Greg,
>=20
> This is fantastic and encouraging news, thanks! I'm not sure how I miss=
ed
> this. If I can find the time I'll see if it'd be as simple for Heimdal,=
or
> perhaps someone from the Heimdal side will chime in. In specific, iprop=
> uses "slave" even more prominently than kprop did, I believe.
For Heimdal, the term "slave" is part of the both the iprop process name
and command line switches for the iprop_master. Changing these could
adversely impact end user deployments that are not expecting their
configuration scripts and packaging to break.
>> Replacing the term "master" is a larger technical challenge. We use
>> that term in a DNS SRV record label (_master_kdc), and migrating that
>> would come with a cost in network traffic and latency. Aside from the=
>> kprop architecture, we also use the term "master key" to describe the
>> key used to encrypt long-term keys in the KDC database.
>>
Changing the name in DNS SRV records is really untenable. The impact on
end user organizations would be significant. The support for master_kdc
lookups and configuration parsing could not be removed because doing so
would result in interop failures. Likewise end user organizations would
be required to publish both the new record and the old.
> Technical considerations are certainly factors. I wonder if it'd be
> reasonable to allow clients to specify a preference when performing the=
SRV
> record lookup?
Not really. It doesn't change anything other than adding a new
configuration option that must reference the "master_kdc" service name
in its documentation.
As a real world example, in 2011 the IETF deprecated the use of AFSDB
records in favor of SRV records for AFS services. This was an official
standardization action that took more than a year to complete. It has
been nearly a decade and by my most recent inventory nearly 2/3 of AFS
cells are still configured with AFSDB records and only 40% have SRV
records. Approximately five percent support both. As a result it has
been impossible to even consider removing the support for AFSDB records
and the additional delays that result from trying one and falling back
to the other.
> I have rationalized to myself that the term "master" is the less
>> problematic of the two terms, as it is used in a lot of different
>> contexts (such as physical master keys, martial arts masters, master
>> plumbers, and master recordings of records). But I don't know if that=
>> rationalization is adequate; from recent discussion I know that git's
>> use of "master" for the initial default branch name has become a point=
>> of contention.
>>=20
> I largely agree here, it's less problematic. I do think it'd be prefera=
ble
> to refer to the "master" server as e.g. "primary", but master key seems=
> fine as it has an established unencumbered meaning.
The term "master" applies to the database not the server. The question
is whether or not the answer to a query is definitive. All of the KDCs
can serve data from the "master" database. The client needs to know
that it should retry against another server when it can determine that
the database isn't a "master" as a noun; its "master" as an adjective.
Where the use of "master" indicates being an expert, principal or
instructor.
Heimdal's documentation should be rewritten to remove the master-slave
relationship. If and when there is ever a volunteer to perform that
work along with all of the other changes that Heimdal's documentation
requires I will happily merge the pull request.
Jeffrey Altman
--------------ms090601090703060408080603
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
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
AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMjAwNjExMDAwMDQwWjAvBgkqhkiG
9w0BCQQxIgQge74blke2HufMrtZBx6oMamfbnRM1Gv4hd1rCUde0k7EwXQYJKwYBBAGCNxAE
MVAwTjA6MQswCQYDVQQGEwJVUzESMBAGA1UEChMJSWRlblRydXN0MRcwFQYDVQQDEw5UcnVz
dElEIENBIEExMgIQQAFs/imA9lTMhUDgLPN9ZzBfBgsqhkiG9w0BCRACCzFQoE4wOjELMAkG
A1UEBhMCVVMxEjAQBgNVBAoTCUlkZW5UcnVzdDEXMBUGA1UEAxMOVHJ1c3RJRCBDQSBBMTIC
EEABbP4pgPZUzIVA4CzzfWcwbAYJKoZIhvcNAQkPMV8wXTALBglghkgBZQMEASowCwYJYIZI
AWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUr
DgMCBzANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASCAQAxsouorYiMBQgJ0r/3Vcy5
JOLYXC3F203gCoaMvJ/eRF1Am/21G9wgXzTkRhvlX/X3g3JvzLCfqH4/B3vQjXKAmycEc+Y7
aTLDpjbNY/aBvp+OP8uUTwb+bCKNFeySa2H8lqueE0j8zFuVa5dtVGb1uoG3KKS2/W20jf+E
LmCk4PfXXyGG4YkTP9sVjoKUbcbaOygXEQ2w+ZfrymHc+RRJwLBQZ46Jdwt+J55IJIHxtnuE
m5DvO+oi2Vz4KnuFJMwou2mUdWV3Le02GH4TFBlzIHg6aKjNU44UkJerwXaEjccLX/i6h++T
k7oI3iO7Dr7lYawTpCPCd65+qbwYO3/UAAAAAAAA
--------------ms090601090703060408080603--
--===============7691683585581263711==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
--===============7691683585581263711==--
