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:

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


Previous Comments:
------------------------------------------------------------------------
[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.

------------------------------------------------------------------------
[2017-05-23 10:03:35] mbechler at eenterphace dot org

Absolutely right, that is missing and I had noticed that before and even 
thought that I had added it - but that does not seem to be the case. 

Adding a constructor argument to KRB5NegotiateAuth for overriding the SPN 
sounds good? I think that would be the most obvious choice.

Do you really need to disable "dns_canonicalize_hostname" (except for the 
client if it is run on the same host)? It would really surprise me if the 
library did perform hostname canonicalization on the server name for acceptor 
credentials.

If you provide a patch, I'll be happy to merge that.

------------------------------------------------------------------------
[2017-05-23 09:38:38] chanlists at googlemail dot com

I would actually prefer to be able to set the service principle using a method 
that changes a property, and use the current behavior as the default method....

------------------------------------------------------------------------


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

Reply via email to