Kerberos WG (krb-wg) Minutes Meeting : IETF 72, Citywest Hotel, Saggart, Co Dublin, Ireland Chairs : Jeffrey Hutzelman , Larry Zhu Jabber : krb-wg@jabber.ietf.org URL : http://tools.ietf.org/wg/krb-wg/ Time : 1300-1500, TUESDAY, July 29, 2008 Location: Conservatory Audio : http://www.ietf.org/audio//ietf728.m3u Meeting Materials: https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=72#wg-krb-wg AGENDA: Preliminaries - Chairs (5 min) - Introduction - Blue Sheets - Scribe, Jabber - Remote Participation - Agenda Bashing Document Status - Chairs (10 min) Cross-Realm *draft-ietf-krb-wg-cross-problem-statement-02 Lame Chair Set/Change PW *draft-ietf-krb-wg-kerberos-set-passwd-07 PROTO Done GSS Agility draft-ietf-krb-wg-gss-cb-hash-agility-04 WGLC Done Data Model draft-ietf-krb-wg-kdc-model-02 WGLC Done (*) document currently expired; new submission needed Cross-Realm Problems: Chair has not finished write-up for document Set/Change Password - Waiting for new revision after chair review ECC for PKINIT - should be soon scheduled for approval GSS Hash Agility - Chair write-up in progress Data Model Document - Chair write-up in progress Presentation on Data Module: Comments on WGLC that did not occur during regular review Added some its that Shawn said were needed which were originally thought outside of KB domain. Do second WGLC post Shawn Emery - Missing attributes such as pre-auth required. Could be in separate draft - Password Policy Sam - Do these new attributes come in the scope of statement of purpose in document - hoping to use LDAP world password policy Author - things like event tracking of principle. - like password change Sam - Scope issue - Management as oppose to administration in scope. Is auditing in the scope? Start to understand how to model pre-auth. Having configuration is important - single bit was not right answer Leif - most problematic attribute is the attribute/bits field. Other items are auditing. - will summarize Shawn’s discussion to list OTP - in working group last call - 3 week last call - comments from people in the room? - Naming - 5 IETF last call comments - 4 dealt with - - last item should also be straightforward - response needed and done Anonymous - Total of 28 issues raised in IETF last call - Anonymous AS Realm What should client realm be for anonymous PKINIT Larry - proposal sent out - does not match with GSSAPI(?) where anonymous has a fixed name rather than server chosen realm should be anonymous Similar to A016 - gss-display-name on anonymous principal - what do you expect back SAM - newer api - low experience - improvements could be benedictional - removes direct conflict conflict between GSSAPI anon & saying that there are multiple anon realms what to close this model difference - in AS case one name matches GSSAPI expectations does not solve tts case. Does not clarify all of implementation chair - tss more common case? sam - will not get sufficient guidance had right ticket - passed to gssapi - might use credential get models in sync to uncouple from GSSAPI auth without killing ourselves later chair - addresses sufficiently this problem? sam – correct, comment in next few days or resolve Larry - concerned - existing allows any KDC can turn anon into real realm - SAM - yes we should disallow chair - disallow fully anon real to the KDC realm - A028 - AD-INITIAL-VERIFIED-CAS Draft -05 to -07 changed requirement level from MAY to SHOULD working group consensus needed on this change SAM - good change Chair - need to verify no objects - A019 - Anonymous realm in relation with cross-realm policy Partial answer just a second go - anon -> non-anon is bad SAM - I don't know what I meant. May be less of an issue with change in naming draft What are reasonable auth paths from anon principle to my realm - how long of a path do you want? Chair - reads from sam's mail on issue SAM - issue is really messy on API implications. Anon realm is not interchangeable with other realms. Interop needs to be setup correctly here. Chair - do you have a proposed answer - or do we need to mull this over? SAM - Guess liberal policy w/ any on the path between you and anon is fine. Are we trading off GSS model for complexity here? - Low confidence guess Chair - proposal to take to mailing list - A020 - Which KDC? SAM - might be implementation defined - A022 - is anonymous@Realm anonymous for GSSAPI SAM - I think no Chair - not more than one anonymous name - information about client given away - partially anonymous Larry - not the same in GSS-API - can't expose to GSS-API Sam - don't need to say this in document should say - integration between anonymous names and gss-api are out of scope for this document - A023 - GSS Import anonymous chair - suspect sub-text is getting comparisons to work correctly. Don't think it helps here. could compare two names from accepting. SAM - NT-ANON always compares unequal to self Ken - could be checking if the name type is anon. larry - say out of scope for document chair - no - could ignore for non-anon realms - but need to deal with for total anon realms SAM - don't feel qualified to answer questions chair - send to gssapi and to kitten? mrex - don't compare output of gss-display-name SAM - take this to the list -it’s hard chair - will need to determine new last calls after changes have been made Last Call - Chairs (45 min) The following documents are currently in last call or have recently had a last call conclude. This time is set aside for discussion of new or existing issues with these documents. PKINIT ECC draft-zhu-pkinit-ecc-04 IESG Eval Naming draft-ietf-krb-wg-naming-04 IESG Eval Anonymous draft-ietf-krb-wg-anon-06 IESG Eval OTP draft-ietf-krb-wg-otp-preauth-05 WGLC Ready? Technical Discussion (45 min) - Preauth Framework - Larry Zhu and Sam Hartman FAST - discussion from SAM and Larry Title page - slide #3 - Ecrypted challange - worked around of IPR statement - ipr problem is not real - still a simpler item - clearing problems of time sync - Needs security review - found at least one problem to date Slide #4 - Auth sets - solves how client tells server on auth sets - not the agreed on solution - Slide #5 - other changes - must support what you claim to support - had asn.1 that servers would chock on - use well known name instead Slide #8 - What FAST is not - this is not like SSH - does on the request but not for the error and the response. - need to understand what is and is not protected or replace them - error not checked-summed - is this acceptable? Slide #9 - Clarity problems - what was covered in finish - esp - not clear which ticket - service or TGT is being protected - - makes protocol either harder to analysis or may have a new - entity in protocol Slide #10 - roll out and preservation of state management cookie - need cookie even for simple items - can't mix and match KDC since cookie is implementation defined - discourage host printing own tickets. - might have extensibility problems - expect KDC to not accept non0self tickets - need to allow for unprivileged process to get tickets. Slide #11 - currently has a MITM attack Slide #13 - summary of walk though - service tick case - fix encrypted challenge - do we use this not encrypted timestamp - scope of fast protection Slide #14 - other issues - options have confusing names - what tickets use as armor tickets - reply key be changes - limits - errors to use for decryption failure - preauth fail? MITM attack is an issue for OTP as well as FAST. Walk through the MITM attack - discuss initial approaches for solving. Fast provides 3 modes of working - source of encrypted tunnel - host tick of OS, ticket on anon-pkinit, anon-anon-pkinit last requires active attack. - have session key from KCD - take long term key & combine keys to joint to session. send message to KDC - KDC sends back msg proving KDC also has long term key. i.e. its who you think you are. Also sends back key to decrypt ticket. key for tunnel encrypted is chosen by client. MITM can Alice->Eve->BobKDC Eve does not need to commit to keys until Alice has given Eve all of the right information. Alice cannot detect problem Violated channel binding rfc. need to guarantee auth in channel - reply key is coming in different protected channel. can 1) authenticate parties on both sides of the channel. for anon-anon - doing real channel binding and do auth later. - need to meet RFC 5056. can't have same channel name. In current case - attacker controls name of channel. - boils down to KB is symmetric key protocol. Solution #1 - don't depend on the channel. Should update items in the encrypted part of it's message. Do not depend on security of channel for full security. - Makes some of Gareth's factors impossible Solution #2 - strengthening the reply key as combination of existing reply key and the new KDC ey. attacker has to dictionary attack password. - reduces dependency on channel. - Can’t really be only answer - but do need to do this Solution #3 - change anonymous - introduce anon-anon pkc init - must derive session key of ticket by using PRF on the DH key. KDC proves to client that it created key this way. Prevents the problem as attacker cannot solely control the name of the channel. - how is it related to ... new KDC both parties introduce ... new KDF is for DH - Have we defined this? - - part of alg agility for PKINIT - both parties contribute to... SAM - don't care – Love - both parties need to have server contribution one more time. PKINIT does not sign everything. SAM - for anon-anon - need to return it. Not part of reply key - part of session key. Additional KDF step - past PKINIT SAM - Makes PKINIT stronger Love - redo the KDF for PKINIT - should we muck in anon? SAM - can do in anon or alg agility - want to write up a message to look at how much needs to be implemented to do a one round trip fast. Larry - where does the change go - in Anon - framework - PKINIT SAM - not in framework Chair - other comments? Larry - how does this work from an operational perspective. - how does KDC know when to use strength reply key? - does not know if client can auth the KDC. SAM - how does it have anything to do with auth data? Larry - need to know if client has authenticated KDC SAM - why ever use replace reply key if you can use strength reply key factor specification should tell you which you are using Larry - from protocol designer what are choices SAM - Gareth has to use strengthening reply key for some factors SAM - I get it - we could let client tell KDC with fast option bit Larry - would client know early enough to tell KDC? - or doe we need another round trip? SAM - got armor ticket via KDC init - know how got - tell in first FAST w/ option bit. Larry - MITM could lie on client set bits. SAM - let me think about it - Review Milestones (10 min) Hash Agility - Tim Polk - minor comments on KDF for clarity. - still needs a last call - test vectors? they are in - Larry needs to verify. - SEPT 2008 - Tim will try and get NIST cycles to verify as well Preath Framework - last call soon? OTP in last call. - to IESG in Sept 08? data model - to IESG in Sept 08 delete hardware preauth delete Kerberos v5.3 StartTLS - blocked on Chair - then need getting WG consensus. Need to know mandatory to implement in the future - therefore dependency on FAST? SAM - Publish summary - schedule conference call until all are happy. or all really sad. Referrals - Ken - need revisions to use FAST or StartTLS to solve security problems - some editing time and dependency. IAKERB - waiting for review - think document is done. - ready for working group review LDAP Schema - need data model - TBA - do we have an author? Open Mic (whatever is left) DS-AP option - DHCP6 option for KDC - SAM - just read note on list - real conflict seems to be KB w/o DNS. - rather see bonjour standardized rather than DHCP6 option. needs to convince people DNS is the wrong answer in this environment. Love - Don't understand SAM's issues - device cannot use DNS to get info in this environ. need to get KDC address as well. chair - Point of SAM - need to explain in mail why DNS is not acceptable in the environ. love - Kerberos say don't use DNS use something else to get server names - strip off referrals on gss-api - no way to figure out how to do this. - canonicalization - need to solve this. chair - spec does not say do not use DNS - says don't use insecure DNS. love - lets go the real world. chair - not convinced it would not be there even if spec was being followed -