Difference between revisions of "Release Meeting Minutes/2013-03-26"

Latest revision as of 15:04, 27 March 2013

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