Subject: [kitten] Critical authorization data in Kerberos

From: Greg Hudson <[email-masked]>
Date: Sat, 02 Aug 2014 11:05:39 -0400

This is intended as an easy-to-find mail thread in the archives which
describes the status quo and possible future directions for the
criticality of authorization data in Kerberos.  This thread is not
specific to any particular work item and does not make any specific
short-term proposals.

RFC 4120 envisions a model for authorization data which is primarily
restrictive, such as a time-of-day restriction on tickets.  KDCs are
required to blindly propagate unknown authdata values in client
requests.  Application servers are expected to treat unknown authdata
types as critical and reject the ticket.  There is an
AD-MANDATORY-FOR-KDC subcontainer for authdata which should be critical
for the KDC.

RFC 4120 contains two provisions for positive authdata.  The
AD-IF-RELEVANT subcontainer gives permission to application servers to
ignore unknown authdata elements.  The AD-KDCIssued subcontainer gives
the same permission, and also has a checksum which proves to the
application server that the contained authdata originated from the KDC
and not from a client request.  The AD-KDCIssued checksum is easily
forged by the application server in a printed ticket; this is not a
problem in the context of RFC 4120 because a service can, at most, fool
itself via a ticket modification request.  S4U2Proxy raises the stakes;
a KDC cannot safely re-sign AD-KDCIssued authdata from an S4U2Proxy
evidence ticket because it might have originated from the intermediate
service.  The PAC's KDC signature and the CAMMAC's KDC verifier are
intended to address this shortcoming of AD-KDCIssued.

I believe that all major implementations of Kerberos (and perhaps all
implementations period) violate RFC 4120 by treating authorization data
as non-critical in application servers.  Moreover, I believe that
implementations don't want to change for fear of breaking existing
deployments.  We generally specify authdata types under the assumption
that some implementations obey this part of RFC 4120 and some don't.  We
cannot really specify an authdata type which needs to be critical for
application servers at this time.

There have been several positive authorization data types implemented or
proposed to date: the PAC[1], the PAD[2], AD-INITIAL-VERIFIED-CAS[3],
AD-LOGIN-ALIAS[4], AD-authentication-strength[5], the authentication
indicator[6], and perhaps others.  I am aware of only two negative
authorization data types implemented or proposed to date:
AD-fx-fast-armor[7] and an informal proposal by David Benjamin[8].  Both
of those types are enforced by the KDC and not application servers.

I can speculate on several future directions for critical authorization
data:

1. The status quo.  Almost all authorization data gets wrapped in
   AD-IF-RELEVANT at a penalty of 13 or more bytes.  Critical authdata
   for application servers is impossible.

2. We somehow determine that all existing Kerberos implementations
   violate this aspect of RFC 4120.  We could then specify that
   AD-IF-RELEVANT is no longer necessary.  Critical authdata for
   application servers remains impossible.

3. We convince all of the major implementations to conform to RFC 4120,
   perhaps after determining that it wouldn't break any existing
   implementations as long as you ignore unwrapped PACs.  We wait for
   all old deployments to fall out of service (i.e. decades pass).
   Criticial authdata becomes possible.

4. We specify a new AD-MANDATORY subcontainer and convince all of the
   major implementations to implement it.  We wait for all old
   deployments to fall out of service.  Critical authdata becomes
   possible using the wrapper.  Can be combined with (2).

Of these, (1) is by far the most likely.  (2) is attractive given the
practical constraints of ticket sizes in some environments, but seems
difficult to accomplish.

[1] http://msdn.microsoft.com/en-us/library/cc237917(PROT.13).aspx
[2] draft-ietf-krb-wg-pad
[3] RFC 4556 section 3.2.3
[4] RFC 6806 section 6
[5] RFC 6113 section 5.5
[6] draft-jain-kitten-krb-auth-indicator
[7] RFC 6113 section 5.4.1.1
[8] David proposed an authdata type which causes the KDC to deny
    renewals of a service ticket if the client's kvno has changed.

---

From: "Nordgren, Bryce L -FS" <[email-masked]>
Date: Sat, 2 Aug 2014 19:59:48 +0000

Thanks for the easy to digest summary!!

I have some residual ignorance, tho:

1] Mandatory auth data sounds to me like something that absolutely everything in the domain (including the KDC) needs to understand consistently, due to the fact that it is essentially broadcast to all domain services. It results in permitting or denying access by the holder of a service ticket (to all services? To some but not others?). Since permitting or denying access based on information possessed by the KDC could be implemented simply by not issuing a ticket, why communicate this to services at all? Are there some cases where the KDC is unaware of a critical piece of information to make the decision?
2] Would the notion of "splitting the difference" be helpful? Keep the auth data processing out on the services, but have the KDC only encode mandatory auth data it expects a particular service to abide by. This approach has the domain-wide effect of "Mandatory if applicable", but the semantics of "Mandatory for you, Service X". It also puts the KDC in control of what is considered applicable to what services. I think this approach may allow service implementations to start obeying "mandatory" ad without fear of breaking all services in the entire domain.
3] What pieces of auth data have presented themselves as uniformly mandatory for all of a domain's web services, file servers, workstations, directory services, etc. to respect?

Thanks again,
Bryce

This electronic message contains information generated by the USDA solely for the intended recipients. Any unauthorized interception of this message or the use or disclosure of the information it contains may violate the law and subject the violator to civil or criminal penalties. If you believe you have received this message in error, please notify the sender and delete the email immediately.

---

From: Greg Hudson <[email-masked]>
Date: Sat, 02 Aug 2014 17:20:05 -0400

> 1] Mandatory auth data sounds to me like something that absolutely everything in the domain (including the KDC) needs to understand consistently, due to the fact that it is essentially broadcast to…

RFC 4120 envisions authdata which is understood by the client and
server, but not the KDC.  Much as you can request a ticket for a shorter
lifetime than the maximum lifetime, you could conceivably request a
ticket that can only be used for specific purposes.

Authorization can be finer-grained than completely denying access to a
service, so it cannot always be implemented as a TGS policy.  You could
have access to an HTTP server but not access to all of its resources,
for instance.

Authorization data does not have to be broadcast to every service in a
domain.  It could be requested by the client in a TGS request or even in
an AP request, or originated by the KDC for some service tickets and not
others.

> 2] Would the notion of "splitting the difference" be helpful? Keep the auth data processing out on the services, but have the KDC only encode mandatory auth data it expects a particular service to…

Making the KDC aware of software capabilities on each server is not
always easy to administer, especially as there is no standard way for
servers to communicate information like that to a KDC.

> 3] What pieces of auth data have presented themselves as uniformly mandatory for all of a domain's web services, file servers, workstations, directory services, etc. to respect?

I think I covered this in my post: nothing so far.  The only
standardized mandatory authdata element I'm aware of is
AD-fx-fast-armor, and that is only intended to be mandatory for the KDC.

---

From: "Nordgren, Bryce L -FS" <[email-masked]>
Date: Sun, 3 Aug 2014 00:47:25 +0000

> RFC 4120 envisions authdata which is understood by the client and server,
> but not the KDC.  Much as you can request a ticket for a shorter lifetime than
> the maximum lifetime, you could conceivably request a ticket that can only
> be used for specific purposes.

This seems to me like a protocol issue between the client and the server. If the access control is vital to the correct functioning of the application, or even constitutes a major feature, it seems unlikely that the protocol would be written to depend on a KDC to convey it. The protocol (NFS, LDAP, WebDAV etc.) is likely designed to work with non-Kerberos authentication methods as well, which may or may not have a parallel conveyance mechanism.

> service, so it cannot always be implemented as a TGS policy.  You could have
> access to an HTTP server but not access to all of its resources, for instance.

Methinks there are two orthogonal granularities embedded in that statement: a spectrum of permissions between permit and deny, which are potentially aggregated into "roles"; and the inventory of resources offered by the service.

Not sure anything other than the server has any business making fine-grained decisions about access to individual resources offered by the service. As you say, this is a hard thing for the KDC to do because it would have to understand the server's inventory of things, as well as its array of available permissions and roles. Potentially, there could be some constrained delegation scenario where I as a client request a limited ticket authorizing some process to access a specific directory as me. I think grid-computing environments support such a notion via PKI. I don't think I've seen anything like this in the desktop world (or the cluster-of-workstations supercomputer world for that matter). Was there any discussion of trying to use Kerberos auth data for constrained delegation (or anything?) when writing NFS 4.x? What were the pros and cons?

The most compelling case I can make for controlling sub-service access by something other than the service would be centralized management of many instances of similar services. Does FreeIPA (domain controller) and sssd (service) use Kerberos auth data to manage fine-grained access (e.g., sudo, ability to login etc.; the spectrum between permit and deny) or does it use some other mechanism? Orthogonally, for access to individual resources, I believe it communicates group membership via LDAP. To what extent does Microsoft leverage Kerberos auth data to manage clients? If these use cases can't leverage mandatory auth data, or can leverage it only partially, it's not very likely that others can. Even if these applications succeed, the centralized manager pretty much has to operate its own KDC, which severely limits the potential application.

This does shine a light on a third potential usage scenario: centralized management of many instances of similar services, by something that is neither a KDC nor a client.  Posit a cluster of machines running database engines, and a centralized management app to keep track of which databases are deployed where, and which keeps track of who may access what. To allow this management app to exercise control over the Kerberos auth data, Kerberos would need a standard means of storing black box auth data, and a standard rule language for determining when a particular black box should be inserted into service tickets. Lacking such a mechanism in the KDC, by far the easiest thing to do is have the management app directly manage permissions on each database engine via SQL. Is there a security benefit to putting auth data in a Kerberos ticket, compared to using the native method? Anything which would motivate developers to demand that Kerberos supply the necessary infrastructure?

The theme with these examples is that it's probably worth finding out if there are reasons not to use mandatory Kerberos auth data in the client->service and KDC->service contexts. Is Kerberos trying to replace a native access control method? What value does Kerberos add over the native access control methods? Identifying cases where it could have been used, but wasn't, is probably important. This differentiates an indifferent response by implementers from a real problem with the concept. I gather that the elephant in the room is the suspicion that there is a real problem with the concept.

Determining why everyone is breaking the rules may give some insight as to whether the rules are ever likely to be followed, and may provide a justification for moving forward with your option #2.

> domain.  It could be requested by the client in a TGS request or even in an AP
> request, or originated by the KDC for some service tickets and not others.

Ah, this obviates my #2. Thanks.

Bryce

---

From: Nico Williams <[email-masked]>
Date: Mon, 4 Aug 2014 11:14:56 -0500

> application servers at this time.

The biggest problem is that criticality must be decided by the
application, not by the Kerberos implementation, but we lack the APIs by
which to give applications access to raw (or processed[*]) critical AD.

In order to fail safe, the Kerberos implementation must know if the
application will understand critical AD; it's not enough to have APIs by
which to convey critical AD to the application.

[*] Processing AD in the Kerberos implementation requires knowing the AD
    type a priori.

> proposed to date: the PAC[1], the PAD[2], AD-INITIAL-VERIFIED-CAS[3],

Arguably AD-INITIAL-VERIFIED-CAS should have been critical.  It's like
transit path, which is critical.  This one is mostly for the Kerberos
implementation to judge, since it's the Kerberos implementation that
applies transit path policy.  Though with my proposed generic naming
attributes for the RFC6680 model the application could check the transit
path itself and apply further policy.

Altogether, it isn't all that important that AD-INITIAL-VERIFIED-CAS be
critical.  It is important that it be signed by the KDC though.

> of those types are enforced by the KDC and not application servers.

Right: we can always introduce AD that are critical for KDC services.
That's fine.

>    AD-IF-RELEVANT at a penalty of 13 or more bytes.  Critical authdata

I am fine with this.

>    for application servers is impossible.

Not necessarily.  RFC6680 gives us the APIs we need by which
applications can judge critical AD, but it doesn't give the mechanism
any way to know if the application will understand and evaluate critical
AD.  We might be able to get critical AD support in APIs but no
fail-safe mechanism in the mechanism.

>    application servers remains impossible.

I think it will be difficult to make that determination.

>    Criticial authdata becomes possible.

See comments above.

>    possible using the wrapper.  Can be combined with (2).

No need to wait in order to start using it.  Right?

> practical constraints of ticket sizes in some environments, but seems

Why couldn't we go with (4).

Nico
--

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 15 Aug 2014 14:06:05 -0400 (EDT)

> Why couldn't we go with (4).

I think I am also fine with (1), but (4) does present a reasonably viable
way forward, should we decide that we're interested in having actually
mandatory/critical authdata at some point in the future.  The new
container would contain things intended to be mandatory, with the
understanding that much time would need to pass before consumers could
rely on all peers actually respecting that intention.

The main question in my mind, deciding between (1) and (4), is: do we
believe that we will want to specify authdata that are treated as critical
by application servers, ever?  (What would such things look like?)  From
the commentary in Bryce's email, it is unclear that we shoul have such an
expectation.

-Ben

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 21 Aug 2014 20:43:48 -0400

> the commentary in Bryce's email, it is unclear that we shoul have such an

The more I think about this, the more I think it's unrealistic to
believe we will ever be able to rely on application servers to treat AD
as critical.  Fortunately, I don't think that will actually be a
problem.  Any sort of restrictive authorization data likely to be
meaningful to an application will almost certainly have to be
application-specific.  The originator of such data, whether client or
KDC (or KDC administrator) will need to have some knowledge of the
service in order to construct it, and thus ought to know whether the
server is likely to be able to accept it.

That said, I can think of one class of uses for which critical AD would
be useful.  Specifically, suppose a user wishes to add AD to a ticket,
informing the server that the ticket should be usable only for a limited
subset of operations, and then forward that ticket to a third party.
The difficulty arises when the ability to do this has been added to an
application, and the user does not know whether the particular server is
new enough to support the new feature.  Resolving this basically
requires some negotiation mechanism within the application protocol.
But then, that's no different from what we have now.

In short, things might be a whole lot easier if we just give up on
critical AD and adopt (1), or a variation thereof.  Particularly, we can
update Kerberos to explicitly state that AD is non-critical, and give
KDC's permission to omit or strip AD-IF-RELEVANT in cases where the
server is known not to require it.  For example, the KDC might have a
per-service flag, or might infer this property for any service which is
known to support enctypes adopted after a particular date.

-- Jeff

---

From: Nico Williams <[email-masked]>
Date: Thu, 21 Aug 2014 19:46:09 -0500

Sold.  Let's make AD non-critical by default.

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 22 Aug 2014 11:18:55 -0400 (EDT)

> Sold.  Let's make AD non-critical by default.

I guess we'll need a separate document to make it so, though...

-Ben

---

From: [email-masked]
Date: Sun, 24 Aug 2014 15:26:14 +0200

Hi All,

sorry about the late reply. It seems to me that the discusion has moved in the right direction.

My feeling is that authentication and authorization go hand in hand, and although it is worthwhile to

efffect a level of interaction between the two, this cannot be as effective as a fully integrated

authentication/authorization system - of which we are still quite a ways off. If pursuing interaction

would encourage enquiry into integrated systems this would be a way forward, otherwise concentrate

on improvement and new developments in the authentication system.

Dean

Gesendet: Freitag, 22. August 2014 um 02:43 Uhr

Von: "Jeffrey Hutzelman" <[email-masked]>

An: "Benjamin Kaduk" <[email-masked]>

Cc: [email-masked], [email-masked]

Betreff: Re: [kitten] Critical authorization data in Kerberos

-- Jeff

_______________________________________________

Kitten mailing list

[email-masked]

https://www.ietf.org/mailman/listinfo/kitten