logo_kerberos.gif

Difference between revisions of "Release Meeting Minutes/2010-03-16"

From K5Wiki
Jump to: navigation, search
(New page: Steve Buckley, Thomas Hardjono, Zhanna Tsitkova, Tom Yu, Danilo Almeida, Arlene Berry, Will Fiveash, Simo Sorce authorization data type number 142. Simo proposes container for OID-identi...)
 
 
Line 1: Line 1:
  +
{{minutes|2010}}
 
Steve Buckley, Thomas Hardjono, Zhanna Tsitkova, Tom Yu, Danilo Almeida, Arlene Berry, Will Fiveash, Simo Sorce
 
Steve Buckley, Thomas Hardjono, Zhanna Tsitkova, Tom Yu, Danilo Almeida, Arlene Berry, Will Fiveash, Simo Sorce
   

Latest revision as of 19:27, 3 January 2011


Steve Buckley, Thomas Hardjono, Zhanna Tsitkova, Tom Yu, Danilo Almeida, Arlene Berry, Will Fiveash, Simo Sorce

authorization data type number 142. Simo proposes container for OID-identified holes. New code will send non-142. If there is a back end that provides PAC, suppress. Does MIT send signedpath for cross-realm?

Making new enctypes friendlier for validated crypto? Interest from Red Hat, Sun, others.

Arlene was experimenting with gss_set_neg_mechs and ran into some problems. set_neg_mechs operates on a cred handle. Calling acquire_creds for SPNEGO first calls into each mech, which is undesirable, because of popup password prompts, etc. Had to go back and explicitly get creds for each desired mech anyway. Client wants kerberos-only but by using SPNEGO mech. (CIFS might not support direct krb5 mech.) If we call the SPNEGO acquire_creds it would get creds for both krb5 and NTLM. Is set_neg_mechs fundamentally broken? (null cred handle might help but has other issues like thread safety/thread-specific data) Danilo thinks that short-term, the client still needs the "bag-o-creds" approach. Should the server also behave that way? We should reopen the krbdev discussion on set_neg_mechs, etc.