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.