logo_kerberos.gif

Release Meeting Minutes/2013-03-26

From K5Wiki
< Release Meeting Minutes
Revision as of 15:04, 27 March 2013 by TomYu (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search


Shawn Emery, Will Fiveash, Thomas Hardjono, Greg Hudson, Ben Kaduk, Eric Kozlowski, Simo Sorce, Zhanna Tsitkov, Tom Yu

Shawn
Tom, extra-round-trip draft?
Tom
Haven't looked in detail.
Tom
Solaris -- one function per auditable event type.
Shawn
Event elements not changing that much... last change was maybe 5 years ago. JSON allows flexibility but events won'd change that much. Authorization data might be more volatile. Not sure what other vendors want. Maybe audit authorization data.
Tom
That depends on what customer requirements are.
Tom
Authorization data can't be generically decoded. Not necessarily ASN.1 encoding.
Simo
MS-PAC?
Shawn
Ticket flags, etc.
Tom
Authorization data... nesting of containers
Simo
Maybe authorization data auditing in the authorization data plugins. Defining events on the fly.... useful for plugin to add its own auditing.
Greg
How?
Simo
Key-value interface. Plugins generate events. e.g. how plugin constructs authorization data.
Will
Separate library that plugins can link to? Other plugins e.g. authorization data to audit.
Simo
Some people would like to see authorization data being generated.
Greg
Per-event methods would have access to entire req/rep. Dmitri wanted key/value pairs to have flat numeric or string values. Hard to do that for authorization data.
Shawn
Simo, audit on application server side?
Simo
We might to some degree.
Zhanna
You said events not changed for last 5 years. API stability? not needed? etc?
Shawn
Looking at design 1. Components have been around for ~5 years, e.g. S4U has been here ~5 years (since 1.7).
Tom
No harm in logging flags numerically, because backward compat etc.
Shawn
Common Criteria requirements for authorization data?
Zhanna
Not necessarily. They have preauthentication
Thomas
Verify correctness of policies?
Shawn
Uninterpreted authorization data... would log as blob.
Tom
Simo's idea re plugins making own audit events.

Shawn talks about postprocessing authorization data binary blobs.

Simo
What if something in blob shouldn't be logged? Authorization data plugin would have better idea of what's sensitive.
Zhanna
Have to purge sensitive info e.g. keys from structures. Common Criteria pays lots of attention to policy... might need to extend in future because of new policy capabilities.
Will
Audit... just have some info about what policy is enforced... arguing about storing authorization data as blob, consuming system should log.
Shawn
Simo, do you have generic authorization check calss like gss_userok that we could tie authorization checks into?
Simo
not using generic interfaces. Also could increase size of logs. A ticket is used multiple times.
Shawn
What are concerns about sensitive data?
Simo
PAC has groups etc. Type of authentication: smart card etc. might want to audit.
Shawn
Different interface for auditing authorization data and stick with proposed design otherwise.
Shawn
Requirements for ticket ID, e.g. CAMMAC.
Tom
Didn't think that was in actual document. We'd have to think about what it means.
Shawn
Hash?

Tom describes differences between using a ticket-ID per initial authentication event, versus some simple hash that is possibly implementation dependent and needs correlation by postprocessing.

Shawn
Prefer internal ID.
Simo
If used as authorization data... does it actually bind to a ticket?

Tom will write up more about CAMMAC and types of binding elements. Also will reread MS-PAC.

Will
Do we have consensus?
Tom
Seems to be design 3.
Will
Performance
Greg
Need to check with Dmitri
Zhanna
If enabled
Will
For us, always enabled. We're going to need kadmin auditing.
Zhanna
Next step after KDC auditing
Personal tools