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:
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...
Previous Comments:
------------------------------------------------------------------------
[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.
------------------------------------------------------------------------
[2017-05-24 09:32:21] chanlists at googlemail dot com
Thinking a bit more about it - now that dns_canonicalize_hostname is no longer
required on the server, we cannot really control what the client has set. Right
now, gss_acquire_cred is called like
status = gss_acquire_cred(&minor_status,
object->servname,
0,
GSS_C_NO_OID_SET,
GSS_C_ACCEPT,
&server_creds,
NULL,
NULL);
It would be great if there were an option to replace obj->servname in the call
by GSS_C_NO_NAME. My understanding is that in this case, any principal in the
keytab should work. So I could stick HTTP/<vhost_name> and HTTP/<real_hostanme>
and HTTP/<short_name> in the keytab, and all should work... What do you think?
Happy to test...
Christian
------------------------------------------------------------------------
[2017-05-23 22:33:46] chanlists at googlemail dot com
Arrgh... I mean principal, not principle...
------------------------------------------------------------------------
[2017-05-23 22:32:24] chanlists at googlemail dot com
I can confirm that previously dns canonicalization had to be turned off. With
your new code, if I specify the service principle as an argument to the
constructor, it works regardless of the dns_canonicalize_hostname setting in
/etc/krb5.conf. This seems to resolve the issues I raised. Thanks a lot for
fixing it! Cheers,
Christian
------------------------------------------------------------------------
[2017-05-23 11:28:33] mbechler at eenterphace dot org
Regarding the canonicalization, really looks like GSS_C_NT_HOSTBASED_SERVICE
name types may be canonicalized.
Can you verify that it is fixed by using GSS_KRB5_NT_PRINCIPAL_NAME and passing
"HTTP/%s" instead. Downside might be that domain->realm is probably not applied
(therefor always uses the default realm), so I would probably leave it as is
for the "magic" case.
Just commited a change adding the argument and parsing the name in that case
with GSS_KRB5_NT_PRINCIPAL_NAME, that way the default would be the best guess
we are able to make while allowing total control when overriding it.
------------------------------------------------------------------------
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
--
PECL development discussion Mailing List (http://pecl.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
