[kitten] Authorization Data Types?

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

[kitten] Authorization Data Types?

Henry B Hotz
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: [hidden email]
Business: [hidden email]

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

Re: [kitten] Authorization Data Types?

Greg Hudson
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.

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten