Release Meeting Minutes/2009-08-11

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

Present: Greg Hudson, Tom Yu, Sam Hartman, Zhanna Tsitkova, Robert Silk, HaoQi Li, Will Fiveash

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

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 [failed auth counts?] 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. [across multiple auth technologies]

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 kdc ... does not currently need read/write access to the kdb

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 fail time and 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 Samba 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 Novell. 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 a count of failed attempts 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 AD supports.

T

microsoft in theory provides

[silence?]

T

A lot of the motivation for account lockout with nist SP 800-63 ... apply to gov agencies, will apply to institutions doing business with U.S. govt in the future.

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 enctype and master enctype as single DES

W

We have a default compile time variable which is a default enctype to master key. That compile time variable is set to triple des. which has effect which if you don't enable triple des, 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 des, not the current AES, etc.

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 interpreted. The enctype

S

if you enter the master key password manually

G

If you enter the password we can . single des to triple des ... what are the transition issues then?

T

I think what happened as a transition issue you need to specify master key enc type in config file if you are using a stash file.

Defaults

Z

Defaults. Admin has 1 1.6 installation, 1 1.7, another 1.7.3. The difference between 1.6 and 1.7 is that there is no AES. Hypothetically. Now the administrator should keep track of what defaults is set for 1.6, 1.7 and 1.7.3.

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 AES-256 is not good enough, then the default for 1.7.3 do not have AES-256 but trusts only triple-DES. What administrator to do with all defaults in kerberos 1.6 and 1.7? 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 1.7.3, rewrite 1.6 and 1.7.

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. 1.6 1.7 1.8. 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 krb4, 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

that's a key size problem not an algorithms problem.

G

SSL will support both

Z

a year ago you have DES, triple des, and aes. 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?