[19543] in Kerberos_V5_Development
Re: Canonical clients in AS-REQ for non-TGS server principals
daemon@ATHENA.MIT.EDU (Jeffrey Altman)
Tue Feb 7 11:14:45 2017
X-Envelope-From: jaltman@secure-endpoints.com
X-MDaemon-Deliver-To: krbdev@mit.edu
To: krbdev@mit.edu
From: Jeffrey Altman <jaltman@secure-endpoints.com>
Message-ID: <7f4e6581-e6f2-0529-a630-986f3f0fb0f6@secure-endpoints.com>
Date: Tue, 7 Feb 2017 11:14:27 -0500
MIME-Version: 1.0
In-Reply-To: <c9627b93-6db6-f956-db81-b796ae0f2afa@one.com>
Content-Type: multipart/mixed; boundary="===============8285935951845761045=="
Errors-To: krbdev-bounces@mit.edu
This is a cryptographically signed message in MIME format.
--===============8285935951845761045==
Content-Type: multipart/signed; protocol="application/pkcs7-signature";
micalg=sha-256; boundary="------------ms000600000607030809080302"
This is a cryptographically signed message in MIME format.
--------------ms000600000607030809080302
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
On 2/7/2017 9:58 AM, Jakob Uhd Jepsen wrote:
> I have run into a limitation of the AS-REQ protocol, when used with=20
> canonical clients, that I am not sure why exists. Our code is using v=20
> 1.12.1 kerberos, though from what I can tell, this bit has not been=20
> changed in a long time and is still present in the latest release=20
> version. It was introduced back in 2009 in commit=20
> 589ad211b633c9319a074c032c47db6b7bd62237
>=20
> The relevant method is verify_as_reply in get_in_tkt.c
>=20
> What I am attempting to do, it use an AS-REQ/AS-REP exchange to get a=20
> ticket from an NT-ENTERPRISE client to a service, that is *not* the TGS=
=20
> service. I do not want a TGT, but a direct service ticket. I also want =
> the client to be the canonical client. It seems this is not allowed, an=
d=20
> I am trying to understand why. There are no cross-realm shennanigans in=
=20
> out setup to complicate matters.
>=20
> (For context, I've pasted in the relevant code at the bottom of this).
>=20
> Specifically, the canon_req field is set for a canonicalize request or =
> an enterprise client. In the case of client canoncialization, both of=20
> these will be true. Yet due to the stipulation that the server principa=
l=20
> be a TGS for canon_ok to be true, we end up in the if branch following =
> this. Here, the AS-REP is checked to see if the request client and the =
> as_reply client are identical. If the KDC canonicalized the client, thi=
s=20
> may not be the case, and the whole exchanged ends up with a=20
> KRB5_KDCREP_MODIFIED error.
>=20
> It doesn't seem that the intent of the comment to prevent servers to=20
> change, matches the full effect of the code, when used in this manner. =
> Is there are reason I'm not seeing, why canonicalizing client names in =
> this instance should not be allowed?
>=20
> /*
> * We only allow the AS-REP server name to be changed if the
> * caller set the canonicalize flag (or requested an enterprise
> * principal) and we requested (and received) a TGT.
> */
> canon_req =3D ((request->kdc_options & KDC_OPT_CANONICALIZE) !=3D =
0) ||
> request->client->type =3D=3D KRB5_NT_ENTERPRISE_PRINCIPAL ||
> (request->kdc_options & KDC_OPT_REQUEST_ANONYMOUS);
> if (canon_req) {
> canon_ok =3D IS_TGS_PRINC(request->server) &&
> IS_TGS_PRINC(as_reply->enc_part2->server);
> if (!canon_ok && (request->kdc_options &=20
> KDC_OPT_REQUEST_ANONYMOUS)) {
> canon_ok =3D krb5_principal_compare_any_realm(context,
> as_reply->client,
> krb5_anonymous_principal());
> }
> } else
> canon_ok =3D 0;
>=20
> if ((!canon_ok &&
> (!krb5_principal_compare(context, as_reply->client,=20
> request->client) ||
> !krb5_principal_compare(context, as_reply->enc_part2->server=
,=20
> request->server)))
> || !krb5_principal_compare(context,=20
> as_reply->enc_part2->server, as_reply->ticket->server)
> ....
> <SNIP>
> .....
> } return KRB5_KDCREP_MODIFIED;
I have not looked at the history but it sounds to me that the test
should be whether or not the ticket returned from the KDC is an initial
ticket, not whether or not it is a TGT.
That said, there may be a historical reason why the behavior was
restricted to TGTs.
Jeffrey Altman
>=20
--------------ms000600000607030809080302
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
DJswggYCMIIE6qADAgECAhBAAVgjEN7WFoCIXylZ1uvSMA0GCSqGSIb3DQEBCwUAMDoxCzAJ
BgNVBAYTAlVTMRIwEAYDVQQKEwlJZGVuVHJ1c3QxFzAVBgNVBAMTDlRydXN0SUQgQ0EgQTEy
MB4XDTE2MTEwMjAzMjQxOFoXDTE3MTEwMjAzMjQxOFowgZYxNTAzBgNVBAsMLFZlcmlmaWVk
IEVtYWlsOiBqYWx0bWFuQHNlY3VyZS1lbmRwb2ludHMuY29tMSswKQYJKoZIhvcNAQkBFhxq
YWx0bWFuQHNlY3VyZS1lbmRwb2ludHMuY29tMTAwLgYKCZImiZPyLGQBARMgN0YwMDAwMDEw
MDAwMDE1ODIzMTBERUE3MDAwMDA3QjQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB
AQDPaPDUdwWkzLcNsJjjlDs5lo4ySDKmCgzQsuDt+VY3wP0IZBbu8f/LM3zWCH7zVRJ/XuY5
qN44jFEXwj5fGY71Esm5pKv5sUpys6Q3c6BKXiHv/IUusI3qTJ46QBEAiHu2lxB75UnIYgm+
ZbKmcAR48Z1Sl/Ku86e9GPuts9R51SeHW1pjq89LAi6C0ERuAUIK0rVZGDmKWtRNs9EykXzk
mU2Z1ZLuPL0jIggFPeT8TyH6TH/XvapbC+7rHJrzuBY4NDqLgqDJUf0JidL9JeK9+IxxPCab
EbVmOf5sBgO5mg92l4+f+Q4xefZcI4C7RPFdRTRWsQs7Z3DpE28BDbjDAgMBAAGjggKlMIIC
oTAOBgNVHQ8BAf8EBAMCBaAwgYQGCCsGAQUFBwEBBHgwdjAwBggrBgEFBQcwAYYkaHR0cDov
L2NvbW1lcmNpYWwub2NzcC5pZGVudHJ1c3QuY29tMEIGCCsGAQUFBzAChjZodHRwOi8vdmFs
aWRhdGlvbi5pZGVudHJ1c3QuY29tL2NlcnRzL3RydXN0aWRjYWExMi5wN2MwHwYDVR0jBBgw
FoAUpHPa72k1inXMoBl7CDL4a4nkQuwwCQYDVR0TBAIwADCCASwGA1UdIASCASMwggEfMIIB
GwYLYIZIAYb5LwAGCwEwggEKMEoGCCsGAQUFBwIBFj5odHRwczovL3NlY3VyZS5pZGVudHJ1
c3QuY29tL2NlcnRpZmljYXRlcy9wb2xpY3kvdHMvaW5kZXguaHRtbDCBuwYIKwYBBQUHAgIw
ga4agatUaGlzIFRydXN0SUQgQ2VydGlmaWNhdGUgaGFzIGJlZW4gaXNzdWVkIGluIGFjY29y
ZGFuY2Ugd2l0aCAKSWRlblRydXN0J3MgVHJ1c3RJRCBDZXJ0aWZpY2F0ZSBQb2xpY3kgZm91
bmQgYXQgaHR0cHM6Ly9zZWN1cmUuaWRlbnRydXN0LmNvbS9jZXJ0aWZpY2F0ZXMvcG9saWN5
L3RzL2luZGV4Lmh0bWwwRQYDVR0fBD4wPDA6oDigNoY0aHR0cDovL3ZhbGlkYXRpb24uaWRl
bnRydXN0LmNvbS9jcmwvdHJ1c3RpZGNhYTEyLmNybDAnBgNVHREEIDAegRxqYWx0bWFuQHNl
Y3VyZS1lbmRwb2ludHMuY29tMB0GA1UdDgQWBBSP11Voh/Sg9hmecftn2BV5ZQd9OTAdBgNV
HSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwDQYJKoZIhvcNAQELBQADggEBAC9cnqRj+ViE
efFsiYNMUC8tZf6PXcWDecOR5Pdv/Vd/O6y10mYyilPrcd0sJux1idTZIOzHAsh36BfBdNSt
BFAuBZD66L649U3XqBnh9nbuzmCwNc3tWjOaY/Xe7R90lqrXaW0Dw0U++zwmNyCO2CRgBdrU
8cTqFpOtpe/gCAMhjajrUfb+m8Vcd5R0RVIvdljblqv2t9IXQIHwWSm8E7v302z7yW4o4iPH
kegez5vq37ICikQjkkVyAJr0wtirJyQuFzMgpoWVpm0CKBiMwJPki2kiHlNiMHBr2ch4fC+H
SjbMg4OzTZJCz1xhKvpyRDOM8JRb2BNSU8JjmrxZgFIwggaRMIIEeaADAgECAhEA+d5Wf8lN
DHdw+WAbUtoVOzANBgkqhkiG9w0BAQsFADBKMQswCQYDVQQGEwJVUzESMBAGA1UEChMJSWRl
blRydXN0MScwJQYDVQQDEx5JZGVuVHJ1c3QgQ29tbWVyY2lhbCBSb290IENBIDEwHhcNMTUw
MjE4MjIyNTE5WhcNMjMwMjE4MjIyNTE5WjA6MQswCQYDVQQGEwJVUzESMBAGA1UEChMJSWRl
blRydXN0MRcwFQYDVQQDEw5UcnVzdElEIENBIEExMjCCASIwDQYJKoZIhvcNAQEBBQADggEP
ADCCAQoCggEBANGRTTzPCic0kq5L6ZrUJWt5LE/n6tbPXPhGt2Egv7plJMoEpvVJJDqGqDYy
maAsd8Hn9ZMAuKUEFdlx5PgCkfu7jL5zgiMNnAFVD9PyrsuF+poqmlxhlQ06sFY2hbhQkVVQ
00KCNgUzKcBUIvjv04w+fhNPkwGW5M7Ae5K5OGFGwOoRck9GG6MUVKvTNkBw2/vNMOd29VGV
TtR0tjH5PS5yDXss48Yl1P4hDStO2L4wTsW2P37QGD27//XGN8K6amWB6F2XOgff/PmlQjQO
ORT95PmLkwwvma5nj0AS0CVp8kv0K2RHV7GonllKpFDMT0CkxMQKwoj+tWEWJTiDKSsCAwEA
AaOCAoAwggJ8MIGJBggrBgEFBQcBAQR9MHswMAYIKwYBBQUHMAGGJGh0dHA6Ly9jb21tZXJj
aWFsLm9jc3AuaWRlbnRydXN0LmNvbTBHBggrBgEFBQcwAoY7aHR0cDovL3ZhbGlkYXRpb24u
aWRlbnRydXN0LmNvbS9yb290cy9jb21tZXJjaWFscm9vdGNhMS5wN2MwHwYDVR0jBBgwFoAU
7UQZwNPwBovupHu+QucmVMiONnYwDwYDVR0TAQH/BAUwAwEB/zCCASAGA1UdIASCARcwggET
MIIBDwYEVR0gADCCAQUwggEBBggrBgEFBQcCAjCB9DBFFj5odHRwczovL3NlY3VyZS5pZGVu
dHJ1c3QuY29tL2NlcnRpZmljYXRlcy9wb2xpY3kvdHMvaW5kZXguaHRtbDADAgEBGoGqVGhp
cyBUcnVzdElEIENlcnRpZmljYXRlIGhhcyBiZWVuIGlzc3VlZCBpbiBhY2NvcmRhbmNlIHdp
dGggSWRlblRydXN0J3MgVHJ1c3RJRCBDZXJ0aWZpY2F0ZSBQb2xpY3kgZm91bmQgYXQgaHR0
cHM6Ly9zZWN1cmUuaWRlbnRydXN0LmNvbS9jZXJ0aWZpY2F0ZXMvcG9saWN5L3RzL2luZGV4
Lmh0bWwwSgYDVR0fBEMwQTA/oD2gO4Y5aHR0cDovL3ZhbGlkYXRpb24uaWRlbnRydXN0LmNv
bS9jcmwvY29tbWVyY2lhbHJvb3RjYTEuY3JsMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEF
BQcDBDAOBgNVHQ8BAf8EBAMCAYYwHQYDVR0OBBYEFKRz2u9pNYp1zKAZewgy+GuJ5ELsMA0G
CSqGSIb3DQEBCwUAA4ICAQAN4YKu0vv062MZfg+xMSNUXYKvHwvZIk+6H1pUmivyDI4I6A3w
Wzxlr83ZJm0oGIF6PBsbgKJ/fhyyIzb+vAYFJmyI8I/0mGlc+nIQNuV2XY8cypPoVJKgpnzp
/7cECXkX8R4NyPtEn8KecbNdGBdEaG4a7AkZ3ujlJofZqYdHxN29tZPdDlZ8fR36/mAFeCEq
0wOtOOc0Eyhs29+9MIZYjyxaPoTS+l8xLcuYX3RWlirRyH6RPfeAi5kySOEhG1quNHe06QIw
pigjyFT6v/vRqoIBr7WpDOSt1VzXPVbSj1PcWBgkwyGKHlQUOuSbHbHcjOD8w8wHSDbL+L2h
e8hNN54doy1e1wJHKmnfb0uBAeISoxRbJnMMWvgAlH5FVrQWlgajeH/6NbYbBSRxALuEOqEQ
epmJM6qz4oD2sxdq4GMN5adAdYEswkY/o0bRKyFXTD3mdqeRXce0jYQbWm7oapqSZBccFvUg
YOrB78tB6c1bxIgaQKRShtWR1zMM0JfqUfD9u8Fg7G5SVO0IG/GcxkSvZeRjhYcbTfqF2eAg
prpyzLWmdr0mou3bv1Sq4OuBhmTQCnqxAXr4yVTRYHkp5lCvRgeJAme1OTVpVPth/O7HJ7Vu
EP9GOr6kCXCXmjB4P3UJ2oU0NqfoQdcSSSt9hliALnExTEjii20B2nSDojGCAxQwggMQAgEB
ME4wOjELMAkGA1UEBhMCVVMxEjAQBgNVBAoTCUlkZW5UcnVzdDEXMBUGA1UEAxMOVHJ1c3RJ
RCBDQSBBMTICEEABWCMQ3tYWgIhfKVnW69IwDQYJYIZIAWUDBAIBBQCgggGXMBgGCSqGSIb3
DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE3MDIwNzE2MTQyN1owLwYJKoZI
hvcNAQkEMSIEIJUuCvLMRRAQAtxcRiEf1sFIwYNkARZGYLpqb98rXysWMF0GCSsGAQQBgjcQ
BDFQME4wOjELMAkGA1UEBhMCVVMxEjAQBgNVBAoTCUlkZW5UcnVzdDEXMBUGA1UEAxMOVHJ1
c3RJRCBDQSBBMTICEEABWCMQ3tYWgIhfKVnW69IwXwYLKoZIhvcNAQkQAgsxUKBOMDoxCzAJ
BgNVBAYTAlVTMRIwEAYDVQQKEwlJZGVuVHJ1c3QxFzAVBgNVBAMTDlRydXN0SUQgQ0EgQTEy
AhBAAVgjEN7WFoCIXylZ1uvSMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCG
SAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYF
Kw4DAgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEggEApA152Dy1xmGut5AiuQev
3P9LPuCKjeT9q6S/KG7gX3fiuc1/pdsgEbe6x+Gf1z/SEY21lImbe+nMVoplYm7n1LthqtmP
YGITad1nNNtTdgcGtxLxJcKR0eOkTNAuhi+OPGT5NUliCwF6EJRTTrNwEoRhARLKzVqYiTyu
yNExYcUajuK6Ynph4YN08z9k8a8+hoBWhs1ET8uC7dwNRBOpovotCXdgyjzA0iuACCfjle1W
FsNJGwm477fJrunTTfGgnLe4xNzE//lCAqt6h8nk8VE8En4KGel5rIadmRi+SzUk0LRwsPNr
0vwZjvFp/PUB5AZJgJCI/5tOtIBGCMBuIwAAAAAAAA==
--------------ms000600000607030809080302--
--===============8285935951845761045==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
--===============8285935951845761045==--
