https://k5wiki.kerberos.org/wiki?action=history&feed=atom&title=Release_Meeting_Minutes%2F2013-03-26 2026-04-22T10:35:14Z Revision history for this page on the wiki MediaWiki 1.27.4 https://k5wiki.kerberos.org/wiki?title=Release_Meeting_Minutes/2013-03-26&diff=5109&oldid=prev 2013-03-27T20:04:03Z

<p>New page: {{minutes|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&#039;t...</p> <p><b>New page</b></p><div>{{minutes|2013}}<br /> Shawn Emery, Will Fiveash, Thomas Hardjono, Greg Hudson, Ben Kaduk, Eric Kozlowski, Simo Sorce, Zhanna Tsitkov, Tom Yu<br /> <br /> ;Shawn: Tom, extra-round-trip draft?<br /> <br /> ;Tom: Haven't looked in detail.<br /> <br /> ;Tom: Solaris -- one function per auditable event type.<br /> <br /> ;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.<br /> <br /> ;Tom: That depends on what customer requirements are.<br /> <br /> ;Tom: Authorization data can't be generically decoded. Not necessarily ASN.1 encoding.<br /> <br /> ;Simo: MS-PAC?<br /> <br /> ;Shawn: Ticket flags, etc.<br /> <br /> ;Tom: Authorization data... nesting of containers<br /> <br /> ;Simo: Maybe authorization data auditing in the authorization data plugins. Defining events on the fly.... useful for plugin to add its own auditing.<br /> <br /> ;Greg: How?<br /> <br /> ;Simo: Key-value interface. Plugins generate events. e.g. how plugin constructs authorization data.<br /> <br /> ;Will: Separate library that plugins can link to? Other plugins e.g. authorization data to audit.<br /> <br /> ;Simo: Some people would like to see authorization data being generated.<br /> <br /> ;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.<br /> <br /> ;Shawn: Simo, audit on application server side?<br /> <br /> ;Simo: We might to some degree.<br /> <br /> ;Zhanna: You said events not changed for last 5 years. API stability? not needed? etc?<br /> <br /> ;Shawn: Looking at design 1. Components have been around for ~5 years, e.g. S4U has been here ~5 years (since 1.7).<br /> <br /> ;Tom: No harm in logging flags numerically, because backward compat etc.<br /> <br /> ;Shawn: Common Criteria requirements for authorization data?<br /> <br /> ;Zhanna: Not necessarily. They have preauthentication<br /> <br /> ;Thomas: Verify correctness of policies?<br /> <br /> ;Shawn: Uninterpreted authorization data... would log as blob.<br /> <br /> ;Tom: Simo's idea re plugins making own audit events.<br /> <br /> Shawn talks about postprocessing authorization data binary blobs.<br /> <br /> ;Simo: What if something in blob shouldn't be logged? Authorization data plugin would have better idea of what's sensitive.<br /> <br /> ;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.<br /> <br /> ;Will: Audit... just have some info about what policy is enforced... arguing about storing authorization data as blob, consuming system should log.<br /> <br /> ;Shawn: Simo, do you have generic authorization check calss like gss_userok that we could tie authorization checks into?<br /> <br /> ;Simo: not using generic interfaces. Also could increase size of logs. A ticket is used multiple times.<br /> <br /> ;Shawn: What are concerns about sensitive data?<br /> <br /> ;Simo: PAC has groups etc. Type of authentication: smart card etc. might want to audit.<br /> <br /> ;Shawn: Different interface for auditing authorization data and stick with proposed design otherwise.<br /> <br /> ;Shawn: Requirements for ticket ID, e.g. CAMMAC.<br /> <br /> ;Tom: Didn't think that was in actual document. We'd have to think about what it means.<br /> <br /> ;Shawn: Hash?<br /> <br /> 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.<br /> <br /> ;Shawn: Prefer internal ID.<br /> <br /> ;Simo: If used as authorization data... does it actually bind to a ticket?<br /> <br /> Tom will write up more about CAMMAC and types of binding elements. Also will reread MS-PAC.<br /> <br /> ;Will: Do we have consensus?<br /> <br /> ;Tom: Seems to be design 3.<br /> <br /> ;Will: Performance<br /> <br /> ;Greg: Need to check with Dmitri<br /> <br /> ;Zhanna: If enabled<br /> <br /> ;Will: For us, always enabled. We're going to need kadmin auditing.<br /> <br /> ;Zhanna: Next step after KDC auditing</div>

TomYu