logo_kerberos.gif

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

From K5Wiki
Jump to: navigation, search
 
(2 intermediate revisions by the same user not shown)
Line 1: Line 1:
  +
{{minutes|2009}}
 
For reference only. NOT a complete transcript. The names of people might be messed up.
 
For reference only. NOT a complete transcript. The names of people might be messed up.
   
<pre>
 
  +
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.
 
LDAP backend is broken. kdb5_ldap_util is getting invalid syntax. MIT will figure it out.
   
1. Account Lockout
+
=== 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: Want to talk about account lockout?
Greg: if you do attempts against many servers should be same as one. Simpler structure if k
+
;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
Is it any better or worse to store in memory.
+
;Greg: if you do attempts against many servers should be same as one. Simpler structure if k
G: assumption that KDC only read consumer db. [Something] is not run for a while.
+
: Is it any better or worse to store [failed auth counts?] in memory?
Will: back in early 07 i have requested a report for login policy for kdc. Idea that kdc should issue
+
;G: assumption that KDC only read consumer db. [Something] is not run for a while.
S: one of the samba requirements as well. when kerberos is used in a complicated environment, want some consistent lockout.
+
;Will: back in early 07 i have requested a report for login policy for kdc. Idea that kdc should issue
G: some sort of lockout daemon. lockout daemon can have access to db and set flags.
+
;S: one of the samba requirements as well. when kerberos is used in a complicated environment, want some consistent lockout. [across multiple auth technologies]
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: some sort of lockout daemon. lockout daemon can have access to db and set flags.
G: The bind dn for the ... does not need
+
;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.
S: want to have different attributes
+
;G: The bind dn for the kdc ... does not currently need read/write access to the kdb
G: can you set an openldap to particular write attributes?
+
;S: want to have different attributes
S: allows to change pw, but not name
+
;G: can you set an openldap to particular write attributes?
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?
+
;S: allows to change pw, but not name
T: Last success time in failed auth count.
+
;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?
G: in failures within a certain window and is disabled temporarily. State we need to hold and what kinds of lockout
+
;T: Last fail time and failed auth count.
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: in failures within a certain window and is disabled temporarily. State we need to hold and what kinds of lockout
G: implement communication
+
;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 ...
S: 3 decompositions.
+
;G: implement communication
S: does
+
;S: 3 decompositions.
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.
+
;S: does
G: What it uses to store the state?
+
;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.
Z: can decide what is current state if you don't want to store timestamps.
+
;G: What it uses to store the state?
T: currently we keep account failed and timestamp of most recent failure.
+
;Z: can decide what is current state if you don't want to store timestamps.
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,
+
;T: currently we keep a count of failed attempts and timestamp of most recent failure.
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?
+
;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,
S: Other databases do completely different things?
+
;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?
T: KDB layer itself in the record
+
;S: Other databases do completely different things?
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
+
;T: KDB layer itself in the record
G: great to know what ab supports. (ab or ad?)
+
;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
T: microsoft in theory provides
+
;G: great to know what AD supports.
silence
+
;T: microsoft in theory provides
T: A lot of the motivation for account lockout with nist 800-3 (sp?) ... apply to gov agencies,
+
[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.
   
2. Changes
+
=== 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.
+
;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
+
;S: Not at a default level
G: if we were to change it on the trunk, it would remove []
+
;G: if we were to change it on the trunk, it would remove []
T: Make completely disable apps
+
;T: Make completely disable apps
G: I don't see a lot of value to
+
;G: I don't see a lot of value to
W: Don't have access profiles. Krb5 doesn't have profiles.
+
;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
+
;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 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.
+
;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
+
;S: it is easy to specify
G: nvmd you can specify it. Interesting it's using triple dez, not the current
+
;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
+
;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
+
;G: it does! It has. depending on byte order, the key stash would be interpreted. The enctype
S: if you enter the password
+
;S: if you enter the master key password manually
G: If you enter the password we can . single dez to triple dez ... what are the transition issues then?
+
;G: If you enter the password we can . single des to triple des ... 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.
+
;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.
   
3. Defaults
+
=== 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.
+
;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
+
;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?
+
;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?
+
;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.
+
;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.
+
;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: 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.
+
;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.
+
;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
+
;Z: He needs to go to see what is default list
W: Not explained why visibilty and transparency is good.
+
;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.
+
;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?
+
;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?
+
;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
+
;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.
+
;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.
+
;T: Higher security in most recent installations, and lower security in older installations. It's okay.
S: bye.
+
;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.
+
;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.
+
;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.
+
;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.."
+
;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.
+
;T: The actual release matters here.
Z: Let's talk about 1.8.1 and 1.8.2
+
;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.
+
;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.
+
;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.
+
;S: That disables ... enc type. That is disconcerning if default breaks env.
T: we want default to break env with warning.
+
;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.
+
;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.
+
;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.
+
;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.
+
;T: THere is no question we will add enc types.
G: It might take a lot to remove something from default
+
;G: It might take a lot to remove something from default
Z: I'm saying default set is moving target.
+
;Z: I'm saying default set is moving target.
T: THe administrator is accustomed to that problem
+
;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.
+
;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?
+
;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.
+
;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.
+
;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?
+
;G: could you use a larger key with an existing public library?
T: Not an algorithms problem.
+
;T: that's a key size problem not an algorithms problem.
G: SSL will support both
+
;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.
+
;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.
+
;G: Why would he want to have the exact same things on the 2 versions.
Z: It seems to be reasonable
+
;Z: It seems to be reasonable
T: He already is getting new versions.
+
;T: He already is getting new versions.
T: A lot of this is policy. We are software.
+
;T: A lot of this is policy. We are software.
G: on board:
+
;G: on board:
1.8 3DES RC4 AES. permitted = default
+
: 1.8 3DES RC4 AES. permitted = default
1.9 3DES AES. permitted = default
+
: 1.9 3DES AES. permitted = default
and he goes back to 1.8, he writes permitted = DEFAULT -rc4
+
: and he goes back to 1.8, he writes permitted = DEFAULT -rc4
This is future proof, I don't have a problem with it.
+
: This is future proof, I don't have a problem with it.
G: Swith true faulse. ...
+
;G: Swith true faulse. ...
   
T: make sure people are generating keys stronger.
+
;T: make sure people are generating keys stronger.
G: MIT is not creating triple des keys?
+
;G: MIT is not creating triple des keys?
</pre>
 

Latest revision as of 23:56, 3 January 2011


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?