[20516] in Kerberos_V5_Development
Re: Authz on the KDC itself - check_kdcpolicy_tgs can't inspect
daemon@ATHENA.MIT.EDU (Greg Hudson)
Mon Dec 16 17:54:32 2024
Message-ID: <b198f973-435d-4f79-829d-ff71db591875@mit.edu>
Date: Mon, 16 Dec 2024 17:54:09 -0500
MIME-Version: 1.0
To: Felix Friedlander <felix.friedlander@anu.edu.au>, krbdev@mit.edu
Content-Language: en-US
From: "Greg Hudson" <ghudson@mit.edu>
In-Reply-To: <cf173125-8514-4735-8028-d23be336737b@anu.edu.au>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Errors-To: krbdev-bounces@mit.edu
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).
> 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.
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
