From leifj at it.su.se Wed May 14 03:29:13 2003 From: leifj at it.su.se (Leif Johansson) Date: Wed, 14 May 2003 09:29:13 +0200 Subject: [Kdc-info] policy-as-code Message-ID: <3EC1F049.3030306@it.su.se> I had a discussion with Love H?rnqvist-?strand who had an interesting point concerning policy-requirements in a kdc which makes me dobout the long-term feasability of modelling policy in the directory. The argument goes something like this (Love: Please correct me on the list if I got you wrong, ok?): Today policy can be described in terms of a fixed set of parameters (password expiry days for instance) but this may be inadequate to describe more complex but necessary policy. For instance try to express: all */admin must have more than 4 iterations in AES or only requests coming from a certain set of hosts are allowed to obtain tickets for foo-service/foo.example.com at EXAMPLE.COM. I would like comments on this -- is it relevant? Do we still model the policy we have today and ignore anything else or do we try to encompass these situations? /leifj From bob_joslin at hp.com Wed May 14 12:19:46 2003 From: bob_joslin at hp.com (Bob Joslin) Date: Wed, 14 May 2003 09:19:46 -0700 Subject: [Kdc-info] policy-as-code In-Reply-To: <3EC1F049.3030306@it.su.se> Message-ID: <000001c31a34$a7589d90$a6820d0f@cup.hp.com> Hi Lief, I think there might be some value in considering a policy info. model that contains the intersection of both LDAP and Kerberos account/password policy requirements. Other more complex or kerberos specifc policies could be up to the implementation. Any thoughts? Bob Joslin -----Original Message----- From: kdc-info-bounces at mit.edu [mailto:kdc-info-bounces at mit.edu] On Behalf Of Leif Johansson Sent: Wednesday, May 14, 2003 12:29 AM To: kdc-info at mit.edu Subject: [Kdc-info] policy-as-code I had a discussion with Love H?rnqvist-?strand who had an interesting point concerning policy-requirements in a kdc which makes me dobout the long-term feasability of modelling policy in the directory. The argument goes something like this (Love: Please correct me on the list if I got you wrong, ok?): Today policy can be described in terms of a fixed set of parameters (password expiry days for instance) but this may be inadequate to describe more complex but necessary policy. For instance try to express: all */admin must have more than 4 iterations in AES or only requests coming from a certain set of hosts are allowed to obtain tickets for foo-service/foo.example.com at EXAMPLE.COM. I would like comments on this -- is it relevant? Do we still model the policy we have today and ignore anything else or do we try to encompass these situations? /leifj _______________________________________________ kdc-info mailing list kdc-info at mit.edu http://mailman.mit.edu/mailman/listinfo/kdc-info From leifj at it.su.se Wed May 14 15:33:45 2003 From: leifj at it.su.se (Leif Johansson) Date: Wed, 14 May 2003 21:33:45 +0200 Subject: [Kdc-info] policy-as-code In-Reply-To: <000001c31a34$a7589d90$a6820d0f@cup.hp.com> References: <000001c31a34$a7589d90$a6820d0f@cup.hp.com> Message-ID: <3EC29A19.5070508@it.su.se> Bob Joslin wrote: >Hi Lief, > >I think there might be some value in considering a policy info. model that >contains the intersection of both LDAP and Kerberos account/password policy >requirements. Other more complex or kerberos specifc policies could be up >to the implementation. Any thoughts? > >Bob Joslin > > > I think you may be right for the reason that there is already an ldap password policy which might (or might not) semantically coincide (more or less) with typical kerberos password policy.... .. On the other hand; future implementations of kdc's may very well include much more complex (stored-as-code) policy object that are as common as password policy is today. In that case I doubt if anyone will store password policy in the directory and every other kind of policy as perl-code (or whatever). So which of these alternatives do we persue: 0. No policy at all in the core information model -- just make room for extensions. 1. Just do password policy and leave it at that. 2. Try to specify a more general policy framework. I am somewhere between 0 and 1. I was almost at 2 after our last meeting but Loves comments made me think twice about the feasability of this. Policy in ldap can get really ugly. Look at the cpim policy framework schema for an example... I'd like to wind up with a relatively simple schema as the result of this, something multiple vendors might actually implement... /leifj From raeburn at MIT.EDU Thu May 15 02:04:46 2003 From: raeburn at MIT.EDU (Ken Raeburn) Date: Thu, 15 May 2003 02:04:46 -0400 Subject: [Kdc-info] policy-as-code In-Reply-To: <3EC1F049.3030306@it.su.se> (Leif Johansson's message of "Wed, 14 May 2003 09:29:13 +0200") References: <3EC1F049.3030306@it.su.se> Message-ID: Leif Johansson writes: > I had a discussion with Love H?rnqvist-?strand who had an > interesting point concerning policy-requirements in a kdc which > makes me dobout the long-term feasability of modelling policy in the > directory. The argument goes something like this (Love: Please > correct me on the list if I got you wrong, ok?): > Today policy can be described in terms of a fixed set of parameters > (password expiry days for instance) but this may be inadequate to > describe more complex but necessary policy. For instance try to > express: all */admin must have more than 4 iterations in AES or only > requests coming from a certain set of hosts are allowed to obtain > tickets for foo-service/foo.example.com at EXAMPLE.COM. The "can't obtain tickets" restriction based on random parameters bothers me. If we don't want the user to be able to use the service, that's an authorization issue. Why are we preventing the user from *authenticating* to it? Maybe there's some perceived "level" of authenticity that's based on the IP address or iteration count? Fine; express it in the tickets, and make an *authorization* decision based on that. But, that aside.... I don't think I'd try to express that as one single policy. It may make more sense to an administrator that way, and it might be nice if the UI would present it that way, but at the KDC level, I see it as at least multiple policies applied at various times: - What iteration counts are acceptable for AES for this principal? This is relevant at password changing time, or whenever it is you allow the user or administrator to tweak the iteration count. It's not part of the change-password protocol, last I checked. And it probably won't be in the LDAP password policy stuff we want to see about building on. - What constraints or privileges are applied to a TGT or other initial ticket issued to a client on a particular host? (can/cannot get foo-service tickets, okay/not-okay for really paranoid services in general, "level" of authenticity, etc) - Is a particular client on a particular server with a particular key type and X parameters allowed to get initial tickets for service Z? Applying restrictions or privileges to the TGT based on the database entry, the PBKDF2 iteration count, the encryption type chosen (you probably wouldn't want to allow access to foo-service using single DES either), the client IP address, and possibly other data, that's hard to express in any general form without a programming language. Maybe it would be better to just allow for additional locally-defined (or not yet standardized) options referenced by name, OID, whatever, and implemented through local code changes, perl scripts stored as data, etc. For the benefit of the UI, perhaps these local policy knobs should have names and/or descriptions accessible in some standardized way, and probably should be collected in a list somewhere so a confused admin can't specify a policy object that doesn't exist. It's not like arbitrary network entities have to be able to apply arbitrary policies, is it? Or does this lead to the cpim mess you mentioned? Ken From leifj at it.su.se Thu May 15 02:59:28 2003 From: leifj at it.su.se (Leif Johansson) Date: Thu, 15 May 2003 08:59:28 +0200 Subject: [Kdc-info] policy-as-code In-Reply-To: References: <3EC1F049.3030306@it.su.se> Message-ID: <3EC33AD0.1070104@it.su.se> Ken Raeburn wrote: >The "can't obtain tickets" restriction based on random parameters >bothers me. If we don't want the user to be able to use the service, >that's an authorization issue. Why are we preventing the user from > Well, it's authentication authorization but yes ... Note that in the case where the service is krbtgt (I only want my windows afs clients to get krb4 tgt's) the authorization policy still belongs in the kdc. >*authenticating* to it? Maybe there's some perceived "level" of >authenticity that's based on the IP address or iteration count? Fine; >express it in the tickets, and make an *authorization* decision based >on that. But, that aside.... >arbitrary policies, is it? > >Or does this lead to the cpim mess you mentioned? > > No This sounds more like you want to provide hooks to describe the *existence* of policy (stored elsewhere) in the directory. I believe it is a way to get around the mess. CPIM tries to model every type of policy as objects/attributes. The number of x-references this requires is what leads to a big mess. Your suggestion avoids that. >Ken > > From raeburn at MIT.EDU Thu May 15 15:13:32 2003 From: raeburn at MIT.EDU (Ken Raeburn) Date: Thu, 15 May 2003 15:13:32 -0400 Subject: [Kdc-info] policy-as-code In-Reply-To: <3EC33AD0.1070104@it.su.se> (Leif Johansson's message of "Thu, 15 May 2003 08:59:28 +0200") References: <3EC1F049.3030306@it.su.se> <3EC33AD0.1070104@it.su.se> Message-ID: Leif Johansson writes: > Well, it's authentication authorization but yes ... Note that in the > case where the service is krbtgt (I only want my windows afs clients > to get krb4 tgt's) the authorization policy still belongs in the > kdc. You're not conditionalizing the issuance of krb5 tickets, so I won't complain about it. :-) If we still considered krb4 good for general authentication, I might disagree with you. > No This sounds more like you want to provide hooks to describe the > *existence* of policy (stored elsewhere) in the directory. Yes. Provide a handle, not a means of specification, for complex policies. Simple ones we can still define fully. > CPIM tries to model every type > of policy as objects/attributes. The number of x-references this > requires is what leads to a big mess. Ouch. Yeah, that'd be a problem. I'd guess it becomes more like a low-level language you don't want to use directly, but instead want to generate using a "compiler" from a more appropriate higher-level language. Which can have its place, if that's what you want. At the moment, I don't think it's what we want. Ken