Skip Menu |
 

History Show all quoted text — Show full headers
# Mon Apr 30 16:05:57 2012 Roy Keene <roy.s.keene@us.army.mil> - Ticket created
Date: Sun, 29 Apr 2012 20:38:47 +0000 (GMT)
From: Roy Keene <roy.s.keene@us.army.mil>
To: krb5-bugs@mit.edu
Subject: krb5 1.10.1 PKINIT assumes server certificate has a Subject Alternative Name X.509v3 Extension
Download (untitled) / with headers
text/plain 3.6KiB
To whom it may concern,

I have recently started using MIT Kerberos 5 version 1.10.1 with
PKINIT talking to a Microsoft Active Directory server.

It fails due to verify_kdc_san() not setting *valid_san to a non-zero
value (or pkinit_as_rep_parse() not having any way to set it to a non-zero
value before calling verify_kdc_san()).

Below is the debuging output from "kinit" after modifying
crypto_retrieve_X509_sans() to write the certificate to stdout in PEM
format.

$ kinit
...
PKCS7 Verification Success
verify_kdc_san: pkinit_kdc_hostname values found in config file
crypto_retrieve_X509_sans: Looking for SANs in cert:

Show quoted text
-----BEGIN CERTIFICATE-----
MIIFVzCCBMCgAwIBAgIKR+v9ugABAAAgcTANBgkqhkiG9w0BAQUFADBqMRMwEQYK
CZImiZPyLGQBGRYDbWlsMRQwEgYKCZImiZPyLGQBGRYEYXJteTEVMBMGCgmSJomT
8ixkARkWBXVzYWNlMRIwEAYKCZImiZPyLGQBGRYCZHMxEjAQBgNVBAMTCVVTQUNF
LUNBMjAeFw0xMTEyMDYwNjQ5MTdaFw0xMzA2MjEwMDA0NTNaMCsxKTAnBgNVBAMT
IEVJUy1EQzFJVEwuZWlzLmRzLnVzYWNlLmFybXkubWlsMIGfMA0GCSqGSIb3DQEB
AQUAA4GNADCBiQKBgQCdgVyGYVDF1Hrg6jN0FyrnKqlQv5UiTtbJZnmWH8m4xYGn
m/SCiJyecXzem6VoUUsWH5y4Ro+GkYZTRuNho7bQ5daEDkWCASytJXlk1oC44Voa
oeYvVjVlXPri3iXZ2pgIXHIbUad7Ummip7mGHbsr31NgNM3bcF/ifX5LA225vwID
AQABo4IDQTCCAz0wCwYDVR0PBAQDAgWgMEQGCSqGSIb3DQEJDwQ3MDUwDgYIKoZI
hvcNAwICAgCAMA4GCCqGSIb3DQMEAgIAgDAHBgUrDgMCBzAKBggqhkiG9w0DBzAd
BgNVHQ4EFgQURP+M3QsMOvhBFPoChvfeJaCSlQMwLwYJKwYBBAGCNxQCBCIeIABE
AG8AbQBhAGkAbgBDAG8AbgB0AHIAbwBsAGwAZQByMB8GA1UdIwQYMBaAFPlF6VHp
RFRGukyvLIb+i2GNGnJxMIIBHwYDVR0fBIIBFjCCARIwggEOoIIBCqCCAQaGgcJs
ZGFwOi8vL0NOPVVTQUNFLUNBMigxKSxDTj1FSVMtR0MyQ1BDLENOPUNEUCxDTj1Q
dWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0
aW9uLERDPWRzLERDPXVzYWNlLERDPWFybXksREM9bWlsP2NlcnRpZmljYXRlUmV2
b2NhdGlvbkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRpb25Qb2lu
dIY/aHR0cDovL2Vpcy1nYzJjcGMuZHMudXNhY2UuYXJteS5taWwvQ2VydEVucm9s
bC9VU0FDRS1DQTIoMSkuY3JsMIIBMwYIKwYBBQUHAQEEggElMIIBITCBtAYIKwYB
BQUHMAKGgadsZGFwOi8vL0NOPVVTQUNFLUNBMixDTj1BSUEsQ049UHVibGljJTIw
S2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz1k
cyxEQz11c2FjZSxEQz1hcm15LERDPW1pbD9jQUNlcnRpZmljYXRlP2Jhc2U/b2Jq
ZWN0Q2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTBoBggrBgEFBQcwAoZcaHR0
cDovL2Vpcy1nYzJjcGMuZHMudXNhY2UuYXJteS5taWwvQ2VydEVucm9sbC9FSVMt
R0MyQ1BDLmRzLnVzYWNlLmFybXkubWlsX1VTQUNFLUNBMigxKS5jcnQwHQYDVR0l
BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMBMA0GCSqGSIb3DQEBBQUAA4GBAAi1jQhn
YbuXUpSJeHhQgUY9639mgs75oEwt7yCdNqgdu2ZnItFk9MwePvXyoU1UzSqAKpoh
esXNDP9R1CBNUhgiiWO0ve0vBqjUDE/Rh6uQeZh/leVG03hIAUTKa2+5VuJlsl1G
FkuLo4f/lrWooCQn9KpWziHgTanb2S38dwPo
-----END CERTIFICATE-----
crypto_retrieve_X509_sans: looking for SANs in cert = /CN=EIS-DC1ITL.eis.ds.usace.army.mil
verify_kdc_san: Checking pkinit sans
verify_kdc_san: no pkinit san match found
verify_kdc_san: no certhosts (or we wouldn't accept them anyway)
verify_kdc_san: returning retval -1765328308, valid_san 0, need_eku_checking 1
pkinit_as_rep_parse returning -1765328308 (KDC name mismatch)
pkinit_as_rep_parse returned -1765328308 (KDC name mismatch)
pkinit_client_process: returning -1765328308 (KDC name mismatch)
...

My krb5.conf contains:
[libdefaults]
default_realm = EIS.DS.USACE.ARMY.MIL
pkinit_kdc_hostname = EIS-DC1ITL.eis.ds.usace.army.mil
...

[realms]
EIS.DS.USACE.ARMY.MIL = {
kdc = eis-dc1itl.eis.ds.usace.army.mil
default_domain = eis.ds.usace.army.mil
admin_server = eis-dc1itl.eis.ds.usace.army.mil
}

Given this it should be entirely possible to verify that my KDC is who I
expect it to be as I have explicitly specified it and the certificate
chain has been validated. This would comply with section 3.2.4 of RFC
4556.

I would like for PKINIT to succeed under these circumstances.

Thanks,
--
(U) Roy Keene
(U) US Army Corps of Engineers IT (ACE-IT)
(U) Contractor
# Mon Apr 30 17:29:12 2012 tlyu (Taylor Yu) - Correspondence added
To: rt@krbdev.MIT.EDU
Subject: Re: [krbdev.mit.edu #7122] krb5 1.10.1 PKINIT assumes server certificate has a Subject Alternative Name X.509v3 Extension
From: Tom Yu <tlyu@MIT.EDU>
Date: Mon, 30 Apr 2012 17:29:10 -0400
RT-Send-Cc:
Download (untitled) / with headers
text/plain 2.1KiB
"Roy Keene via RT" <rt-comment@krbdev.mit.edu> writes:

Show quoted text
> crypto_retrieve_X509_sans: looking for SANs in cert = /CN=EIS-DC1ITL.eis.ds.usace.army.mil
> verify_kdc_san: Checking pkinit sans
> verify_kdc_san: no pkinit san match found
> verify_kdc_san: no certhosts (or we wouldn't accept them anyway)
> verify_kdc_san: returning retval -1765328308, valid_san 0, need_eku_checking 1
> pkinit_as_rep_parse returning -1765328308 (KDC name mismatch)
> pkinit_as_rep_parse returned -1765328308 (KDC name mismatch)
> pkinit_client_process: returning -1765328308 (KDC name mismatch)
> ...
>
> My krb5.conf contains:
> [libdefaults]
> default_realm = EIS.DS.USACE.ARMY.MIL
> pkinit_kdc_hostname = EIS-DC1ITL.eis.ds.usace.army.mil
> ...
>
> [realms]
> EIS.DS.USACE.ARMY.MIL = {
> kdc = eis-dc1itl.eis.ds.usace.army.mil
> default_domain = eis.ds.usace.army.mil
> admin_server = eis-dc1itl.eis.ds.usace.army.mil
> }
>
> Given this it should be entirely possible to verify that my KDC is who I
> expect it to be as I have explicitly specified it and the certificate
> chain has been validated. This would comply with section 3.2.4 of RFC
> 4556.
>
> I would like for PKINIT to succeed under these circumstances.

Your certificate doesn't appear to have any SubjectAltName extensions.
I'm fairly sure that our implementation only checks
pkinit_kdc_hostname against the dnsName SubjectAltName extensions,
which explains the "no certhosts" debugging message. (The "certhosts"
comparison is also case-sensitive, but that could be a different issue
that this situation doesn't allow to become relevant.)

I think it also does not check against the CommonName part of the
Subject. It's not completely clear to me from RFC 4556 whether
matching pkinit_kdc_hostname against the CommonName of the KDC
certificate is appropriate. We will consider changing the existing
behavior, but I would first like to confirm that checking the
CommonName in this situation does not cause any additional
vulnerabilities.

Is this certificate one that you created for the purposes of using
PKINIT, or did you create it for some other purpose first? What
method did you use to create this certificate?

Thanks.