Subject: [kitten] Authorization Data Types?

From: "Henry B (Hank) Hotz, CISSP" <[email-masked]>
Date: Thu, 10 Mar 2016 14:29:30 -0800

AFAIK we’ve never done much with standardizing authorization data. (I have to accept some of the blame for that myself, unfortunately.)

Now I find myself wanting to do a proprietary extension. Any advice (besides “don’t do it”)? I’d at least like to minimize the side effects on standard uses.

Personal: [email-masked]
Business: [email-masked]

---

From: Greg Hudson <[email-masked]>
Date: Thu, 10 Mar 2016 20:03:49 -0500

On 03/10/2016 05:29 PM, Henry B (Hank) Hotz, CISSP wrote:
> AFAIK we’ve never done much with standardizing authorization data.

Well, we did just publish RFC 7751 (CAMMAC) and have a working group
draft for ad-authentication-indicator.  But it's true that we haven't
done a lot with it.

> Now I find myself wanting to do a proprietary extension. Any advice (besides “don’t do it”)? I’d at least like to minimize the side effects on standard uses.

Negative ad-type values are reserved for local use, positive values for
registered use.  (RFC 4120 section 5.2.6.)

Be aware of the security properties of authorization data:

* It's not visible to the client or to third parties because it's in the
encrypted part of the ticket.  It is visible to the service and the KDC.

* Clients can ask for any authorization data they want when requesting a
ticket, and by default the KDC is supposed to include it.  KDCs may
filter out certain ad-types, but only if they know what they are.
AD-KDC-ISSUED or AD-CAMMAC containers can be used to ensure to a service
that authorization data was issued according to KDC policy.

* Services can forge authorization data in the ticket when making a
ticket modification request or S4U2Proxy request to the KDC.
AD-KDC-ISSUED does not change this.  AD-CAMMAC containers can be used to
ensure to the KDC that authorization data was issued according to KDC
policy, as long as the kdc-verifier is present and verifies correctly.

* Authorization data contained in a cross-realm TGT was, at best, issued
according to the policy of the source realm, not the target realm.

* Authorization data is supposed to be critical by default (unless
enclosed in an AD-IF-RELEVANT container), but I don't think any
implementation enforces this, so in practice it's all non-critical.