Difference between revisions of "Release Meeting Minutes/2009-08-11"

Revision as of 14:07, 12 August 2009

For reference only. NOT a complete transcript. The names of people might be messed up.

LDAP backend is broken. kdb5_ldap_util is getting invalid syntax. MIT will figure it out.

1. Account Lockout Greg: Want to talk about account lockout? Tom: We have some amount of sponsor interest in getting account lockout support. There are several ways to do it right. Multiple KDC . I don't know how easy it is to use Greg: if you do attempts against many servers should be same as one. Simpler structure if k Is it any better or worse to store in memory. G: assumption that KDC only read consumer db. [Something] is not run for a while. Will: back in early 07 i have requested a report for login policy for kdc. Idea that kdc should issue S: one of the samba requirements as well. when kerberos is used in a complicated environment, want some consistent lockout. G: some sort of lockout daemon. lockout daemon can have access to db and set flags. S: to be compiled: 1. have administrative effect 2. it actually implements a lockout policy. I think there is not a huge concern to have kdc to write in database. G: The bind dn for the ... does not need S: want to have different attributes G: can you set an openldap to particular write attributes? S: allows to change pw, but not name G: write support to account lockout ourselves, how complicated of a policy do we want to support? Know timestamps of fail accesses, bounded by number of times of. All we have is number of fails in last auth? T: Last success time in failed auth count. G: in failures within a certain window and is disabled temporarily. State we need to hold and what kinds of lockout S: in jamba and active directory env, you want policy and state to not be like kerberos. Just want kdc. for novell, update lockout tracking state in kdb calls. don't want to break that. for ldap environment that is not the best, want an integrated ... G: implement communication S: 3 decompositions. S: does Z: draft that is 5 years old. It describes all attributes to decide if login is acceptable. Draft describes policy for ldap that we may consider to adopt. It's initated from Novel. Password Policy for LDAP Directories. G: What it uses to store the state? Z: can decide what is current state if you don't want to store timestamps. T: currently we keep account failed and timestamp of most recent failure. Z: if you have login attempts every 5 minutes, you can't block the person. If it is 1 second between attempts it's one thing, G: Howard Chu has timestamp of last ... Do we want to stick with what we have and allow policies that can operate on these state. Or do we want to extend to allow timestamps? S: Other databases do completely different things? T: KDB layer itself in the record S: That's not how people do it in active directories. Different sets of entry points are... . Don't break what people are doing in active directories. The requirements seems to be using kerberos small or multiple. Luke's email on policy entry points. I support his email. I think you should avoid breaking policies by making possible to turn off parts of the policy that adds to kdc. The email Luke's long list of responses to Andrew. Don't break what we have today G: great to know what ab supports. (ab or ad?) T: microsoft in theory provides silence T: A lot of the motivation for account lockout with nist 800-3 (sp?) ... apply to gov agencies,

2. Changes T: The thing about allow weak crypto change into default set antypes? It seems like make it operate at a different level. So when we flip switch, can disallow it. A more dramatic way. S: Not at a default level G: if we were to change it on the trunk, it would remove [] T: Make completely disable apps G: I don't see a lot of value to W: Don't have access profiles. Krb5 doesn't have profiles. T: test suite has to be modified. A lot of defaults to support angtype and master angtype to single W: We have a default compile time variable which is a default angtype to master key. That compile time variable is set to triple dez. which has affect which if you don't enable triple dez, can't create db or overwrite in config file unless you specify. S: it is easy to specify G: nvmd you can specify it. Interesting it's using triple dez, not the current W: the new stash is keytab. I think the old one has the key G: it does! It has. depending on byte order, the key stash would be interperted. The angtype S: if you enter the password G: If you enter the password we can . single dez to triple dez ... what are the transition issues then? T: I think waht happened as a transition issue you need to specify master key in enc file if you are using a stash file.

3. Defaults Z: Defaults. 1 16, 1 17, another 13. The difference between 16 and 17 is that there is no AS. Hypothetically. Now the administrator should keep track of what defaults is set for 16, 17 and 173. T: I hope it wouldn't have to care Z: Configure such that he accepts all defaults, but all three are defaulted differently. How to deal with the same set of algorithms? W: why? Z: I think it's a logical question if at a particular moment you think AS 256 is not good enough, then the default for 173 do not have AS 256 but trusts only triple 8. What administrator to do with all defaults in kerberos 16 and 17? He needs to configure everything to forget about all defaults? The idea of default becomes weird. It's not default anymore. You use it in 173, rewrite 16 and 17. G: If want results to depend on defaults, specify defaults. Z: He needs to keep track of defaults in different versions. ... He thinks that they are the same and might be confused, becuase it's not default for kerberos, but is instead a default for this release. Z: I was proponent of default e types. but now I think it's more accurate for administrator what type I want to use. T: problem with encouraging admins to explicitly list algorithms is that it's not future proof. Can't upgrade. Z: He needs to go to see what is default list W: Not explained why visibilty and transparency is good. Z: 3 cases, admin relies on default cases. 16 17 18. In 2010 there is algorithm that is not good enough. But admin assumes defaults are not good. S: Why should think defaults are not good? Z: Because there is some alert in year 2010 to say an algorithm is not good. We are issue security updates for 1.6 and 1.7? S: When we encountered an algorithm problem in 1.4, we issued an update. If it were too severe, we would Z: Do security updates for default sets in all cases. Good. T: Higher security in most recent installations, and lower security in older installations. It's okay. S: bye. T: Also kerberos make this less of a problem. Because whatever algorithm kdc supports and generates by default is going to determine what algorithms to use. Z: What i'm saying is for an administrator. I'm afraid that when we try to simply his life, we add confusion. T: admins are accustomed to the idea that defaults can change over time. Z: Will they be aware of this variable. In a version it will have "default plus this and this.." T: The actual release matters here. Z: Let's talk about 1.8.1 and 1.8.2 T: Not gonna happen until the future, people will have kerberos that is many years old. G: Administrator sees default for 1.7, it doesn't specifies. A new release comes, and the aministrator is surprised by the change of default. But if we add support for new algorithm, the administrator will want their installations to automatically have support for the new algorithm. S: That disables ... enc type. That is disconcerning if default breaks env. T: we want default to break env with warning. G: Is it ever appropriate to force people to like password once a while. In theory if you keep env up to date. AT least triple dez. T: Problem very old kerberos software stop interacting new software. Do we ever remove encryption that is too weak to support? Should we ever remove something from default. Zhanna says we shouldn't have defaults? We should say what algorithms are supported, we shouldn't have defaults. Z: I don't like this idea, but something tells me that confusion will be there. T: THere is no question we will add enc types. G: It might take a lot to remove something from default Z: I'm saying default set is moving target. T: THe administrator is accustomed to that problem G: Treat problem with crypto agility. The old software keeps working with new software with knowledge that its not secure. I don't think we will remove support to enc type for 1.7 type unless it's really really bad. Z: What's the definition of default? Is it the strongest encryption? G: The encryption type that is strongest currently. It's a set that is reasonable for use. Z: My understanding is that default is to enforce the strongest level. Currently default is everything except DES. G: could you use a larger key with an existing public library? T: Not an algorithms problem. G: SSL will support both Z: a year ago you have DES, triple des, and oss. suppose that is the default set. This year, we don't want this default set. The administrator should write in default -des ... for example osds i in 1.6. So he has config file for 1.7 is default, for 1.6 is default -a few things. G: Why would he want to have the exact same things on the 2 versions. Z: It seems to be reasonable T: He already is getting new versions. T: A lot of this is policy. We are software. G: on board: 1.8 3DES RC4 AES. permitted = default 1.9 3DES AES. permitted = default and he goes back to 1.8, he writes permitted = DEFAULT -rc4 This is future proof, I don't have a problem with it. G: Swith true faulse. ...

T: make sure people are generating keys stronger. G: MIT is not creating triple des keys?