Bug #74636 [Asn]: [krb5] negotiate auth broken for vhosts because of hostname canonicalization

Edit report at https://bugs.php.net/bug.php?id=74636&edit=1 ID: 74636 User updated by: chanlists at googlemail dot com Reported by: chanlists at googlemail dot com Summary: [krb5] negotiate auth broken for vhosts because of hostname canonicalization Status: Assigned Type: Bug Package: PECL Operating System: debian 8 PHP Version: 5.6.30 Assigned To: mbechler Block user comment: N Private report: N New Comment: Great. Works for me just fine whether dns_canonicalize_hostname is set on the client or not (if I stick all relevant principals in the keytab). Thanks, Christian Previous Comments: ------------------------------------------------------------------------ [2017-05-25 14:10:30] mbechler at eenterphace dot org Just commited another version in which you can pass GSS_C_NO_NAME instead of the SPN to achieve that. Also includes support for gss_acquire_cred_from (krb5_import_cred turned out to be unusable for SPNEGO). ------------------------------------------------------------------------ [2017-05-25 12:08:04] chanlists at googlemail dot com OK, what I have tried now is the following patch relative to your latest version: 248,249d247 < } else if(spn[0] == '@') { < object->servname = GSS_C_NO_NAME; The effect of this is that if I set the service name to '@', it will use GSS_C_NO_NAME... and therefore accept all principals in the keytab. ------------------------------------------------------------------------ [2017-05-25 09:56:02] mbechler at eenterphace dot org Yes, in that case it should be safe. Just saying that there are some implications to it. Generally, it would be wise to switch to gss_krb5_import_cred anyhow (if available) as currently this is a bit of a hack (the keytab set with register_acceptor_identitity really is process state, if you use multiple instances or something else fiddles with it you are in trouble). I think that might just have that behavior (loading all keys from the given keytab) anyways. ------------------------------------------------------------------------ [2017-05-24 12:40:58] chanlists at googlemail dot com Hm... But if I use a separate keytab file for the PHP script, I can control which principals I stick in there, and so it should not try whatever is in /etc/krb5.keytab, and only those in my dedicated keytab, say /etc/apache2/my_httpd_keytab_file.keytab? In that case adding an option should be safe... ------------------------------------------------------------------------ [2017-05-24 10:51:10] mbechler at eenterphace dot org Passing GSS_C_NO_NAME or GSS_C_NO_CREDENTIAL to accept_context respecively has some (possible acceptable) downsides: a) it invokes implementation dependant behavior (spec essentially says implementations can choose whichever keys they like) - but the common and more recent implementations (e.g. mit since 1.7 - which is pretty old) seem have the desired behavior (trying all keys). b) this supposedly will also try the default keytab, which means that anyone with access to one of these other keys (if there are any) can forge tickets for your service. That might be an subtle security issue in some setups. If I were using that personally, I would probably rather go for either redirecting to a canonical host or constructing and passing the proper SPN. But I think I would be okay with adding an option to enable that behavior. ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=74636 -- Edit this bug report at https://bugs.php.net/bug.php?id=74636&edit=1