Authz on the KDC itself - check_kdcpolicy_tgs can't inspect client?

[Alexander Bokovoy]

On Пан, 16 сне 2024, Greg Hudson wrote:
>On 12/16/24 15:36, Felix Friedlander via krbdev wrote:
>>I was hoping to prototype this in a kdcpolicy plugin; however, 
>>check_kdcpolicy_tgs doesn't receive the "client" parameter that 
>>check_kdcpolicy_as does, so a plugin (currently) can't inspect the 
>>requesting principal at ticket-granting time. Is there a reason this 
>>information isn't exposed? As far as I can tell, it /is/ available 
>>at the relevant location in process_tgs_req.
>
>Historically, the KDC never looked up the client principal entry 
>during a TGS request, relying only on information present in the 
>ticket issued during the AS request.  That ticket contains the client 
>principal name, of course, but not the database entry.
>
>Today we almost always look it up, because we want to pass it to the 
>KDB module's issue_pac() method.  The exceptions are cross-realm 
>requests (where the client principal entry is in another database) and 
>when the principal is marked NO_AUTHDATA_REQUIRED (in which case the 
>KDC doesn't call issue_pac()).
>
>The kdcpolicy interface was patterned after the KDB methods 
>check_policy_as() and check_policy_tgs().  Those methods were 
>specified back in an era when the KDC generally did not look up the 
>client database entry.  Nothing stops a kdcpolicy module from 
>performing its own DB lookup of the client principal with 
>krb5_db_get_principal(), except for the mild inefficiency that the KDC 
>already did it (unless you routinely set NO_AUTHDATA_REQUIRED on 
>service principals, which you could do if your realm doesn't need any 
>S4U2Self or S4U2Proxy support).

May be we can have a 'cache' of the DB entries tied to an instance of
krb5_kdc_req struct and add a function that returns an entry from this
'cache'? This way all code would be able to reference any entry already
retrieved during processing of this request? 

This wouldn't require changes to kdcpolicy APIs as both functions
already get the request instance and can query that 'cache' for a client.

A problem here is that krb5_kdc_req struct is public, so its change
would still be an API change..

>>Any other thoughts on the concept? I'm not trying to say that this 
>>is the best way to do authorisation, just that it seems possible, 
>>and might be useful in some contexts.
>
>You've covered several of the common ways to do authorization: the 
>application server knows who is authorized (local ACLs), the server 
>asks someone else (LDAP), and the KDC decides at authentication time.  
>There is also Microsoft's PAC approach, which is that the ticket 
>includes information relevant to authorization (such as group 
>membership) as part of the ticket.
>
>Historically the Kerberos protocol community has been moderately 
>opposed to the KDC performing authorization decisions.  Firstly, it's 
>a pretty blunt tool--it can prevent authentication to the service 
>entirely, but it can't provide any level of partial access.  Second, 
>when a KDC starts making authorization decisions in this manner, it 
>encourages application servers to ignore this advice from RFC 4120:
>
>   Applications should not accept the mere issuance of a service ticket
>   by the Kerberos server (even by a modified Kerberos server) as
>   granting authority to use the service, since such applications may
>   become vulnerable to the bypass of this authorization check in an
>   environment where other options for application authentication are
>   provided, or if they interoperate with other KDCs.
>
>>(If it is safe to add, I'm happy to submit a patch to allow a new
>>major version of kdcpolicy - which I think would be needed to change
>>krb5_kdcpolicy_check_tgs_fn.)
>I currently lean towards thinking that there isn't enough reason to 
>amend the kdcpolicy interface.  Although we could do it with only a 
>minor version bump (like in <https://github.com/krb5/krb5/commit/2928f4f1682ee6245cec1f3c6d9d4b9bf30f8ee1>), 
>we'd still be carrying some extra complexity.

I agree. On the other hand, if there is a request-associated 'cache' of
retrieved DB entries, we don't need an API change for kdcpolicy plugin.

-- 
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland