Meeting : IETF 79, Shangri-La Hotel Beijing, Beijing, China Chairs : Larry Zhu and Jeffrey Hutzelman Jabber : krb-wg@jabber.ietf.org Note Taker: Jim Schaad URL : http://tools.ietf.org/wg/krb-wg/ Time : 1300-1515, FRIDAY, November 12, 2010 Location: Jade 1 Audio : http://videolab.uoregon.edu/events/ietf/ietf794.m3u Meeting Materials: https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=79#wg-krb-wg Reading List: draft-kanno-krbwg-kanno-camellia-ccm-03.txt RFC4120 Section 7 RFC 5226 IANA considerations Agenda ======== Preliminaries - Chairs (5 min) - Introduction - Blue Sheets - Scribe, Jabber - Remote Participation - Agenda Bashing Document Status and Discussions - Chairs (15 min) Technical Discussion - Camellia-CCM (10 min) - IANA Considerations (30) - PAC (5 min) -optional Mesh Kerberos (10 min) Charter and Milestone Updates (5 min) Open Mic (whatever is left) Doc status. Referrals - Sam - problem is that missing parts of init message. Msft code has lots of variants Problem in modern kbr simple Recommand - relook @ code - should be easier now. Talked about adding fast negotiation May recommend that some referrals need FAST or STARTTLS to get good error handling Comments by Jan to working group on amount of work required. Please comment on general approach. Document pre-dates working group. Reason of long process is that new things keep getting added. tom: would suggest splitting the document into an informational bit that describes what MSFT does now and a std-track one for the additional work. Sam - I think that what msft does is probably where we are going - don't want to split documents echo list tom: would suggest splitting the document into an informational bit that describes what MSFT does now and a std-track one for the additional work. Sam - I think that what msft does is probably where we are going - don't want to split documents Set/Change Password sam - should make document go dormant - remove milestone but not from charter. If somebody wants to implement - then revise and push on Give inteoper-able way to rekey host and add new key to environment - This + ldap schema would allow std way of doing admin system. SNMP (ISMS) Sam - large system want to pull cable modems w/o keeping state on manager. Proposal is to use KBR messages directly Sam??? Puzzled – that’s a lot of tickets. Would go forward in ISIS - would use raw KB not GSS - could not sell them on using KB-GSS - really want to keep it in one packet -- has not read the document Tim - Main driver appears pre-existing kb implementations SAML Kerberos Attribute profile (OASIS SSTC) see mail list Sam - last called a profile - asked for review - CMU has use case - move kb credentials in SAML assertions. Wanted to extend last-call. But not a std way to represent a credential w/o key. Two approaches - generate a fake key and key wrap. Depend on SAML congeniality. Might be issues w/ crypto boundaries -- otherwise have things unencrypted. Ask we standardized way of doing unencrypted kb creds - do for GSS-API - some implementations - might need a charter update. Work is basically done. ABFAB - *********************************** IANA discussions Love write registry proposal draft w/ one excepting - have one registry for pre-auth framework. Allocates part for first-come and part for ietf review Sam comment - uncomfortable for registration policies. Can get into a situation where a number has been double used for different things. or implemented w/o telling anybody what it has. KB Error codes (may be scare resource), Auth data types - 32-bit space - address types, name types, cross-realm transit compression types message types?, key usage types - 32 bit space- Liberal policy allows venders to get numbers in time to ship. Can't get assignment for Camilla for MIT. Community wants to promote clean architecture and interop. - couple of examples of things that might be problems or good things IETF has number of different policies - RFC has IANA consideration document RFC 5226 - Different options: Std action - must write a std track RFC IETF review - IETF stream and last call IESG review - IESG can do it on it's own Expert review - designated review by individual based on possible criteria from the working group Specification Required - need a clear document published First Come First Serve - ask and receive. Private use Experimental - both have special constraints Reserved current draft - Encryption types - need expert review - may or may not need specification first time specification errors were found by reviewer. had some architectural inconsistences as well. For pre-auth framework - expert review - two criteria specified. If says yes it does one of them - then approved. Will get bounced to IETF review if problems found and authors want to extend. Sam has opinions on registration Key Usage - FCFS large range Need to look at error code side - if large then open Transitive - must be std action address registry - reasonably open - but most people would not care Authorization - ??? - do we need to make a higher review - some questions. example PKINIT had security problems discussion: Jeff's personal opinion My proposal, as an individual; please take to the mic when appropriate: Transited Encoding, Protocol Version, Message Numbers - Standards Action Address types, name types, AD types all Expert Review like PA data Key Usage numbers - FCFS Error codes - probably FCFS Alexy - says yes Camellia ciphers ================ following link in the document ^Jeff: = really just wanted technical discussion not talk about this? Sam - for GCM - would like to move from CTS if people are unable - would like to have few number of protocols. No independent hash for digital signatures. So just for the MAC. could have very large explicit id. so counter re-issue should be solvable in some fashion. Look at exploring a counter mode cipher. got something implemented and somewhat happy. Debate on question if 96-bit nonce was large enough. Do a KDF for more info to lengthen the nonce. From a performance standpoint - could control how often people are required to re-key the session - could probably just done once KDC might need to do it along. Problem is - CCM has a potential length limit - 2^27 blocks (128 bits) At the abstraction could break some corner cases. Would be fine for common use some ways around. such as chaining CCM messages some people have implemented things on top of kb - such as scatter gather encryption - assume expansion of a message is constant. If the message was too long - might get multiple auth tags chained in. Larry - just required an upper bound sam - spec allows - applications probably do dumb things here could have constant by chaining auth tags forward make decryption performance issues? Implementation is message as boundaries of cryptographic message was shifting - block alignments kept getting worse- bad Currently no happy way - Could just do a counter mode that looked similar - has some problems but not worried about crypto analysis issues - probably be fine Publication issues much worse. Could just use a different mode - such as CTS w/ cipher based mac. Need a larger length than 2^28 - ok to break around 2^35 want it to work will with scatter/gather want it to work well w/o a hash Sean - disadvantage of CTS is feedback nature in hardware Tim Polk: Concerned about tweaking modes from crypt analysis and politics - wheels turn slowly @ NIST on some of these things. Happy to have the guy @ NIST who wrote the mode spec could do review if desired. sam= what are all of the sane modes used today tim/sam: CBC, GCM, CCM, SAM - if we want the message size to have no addition padding --- don't want to have CBC additional padding Tim : no additional mode which is purpose build for that toM; CCM and GCM have more modes attached Sam: can work around the caveats - got messed up on stupid internal details. Sam: Should re-look @ Larry's idea - not necessarily bad. Need to work through and make sure we hate it before we finish. Action item: Does the charter update Camellia proponents do something PAC Sam: who does not like the general idea of this. Or summarize the thread for Sam. Leif: I have read the draft what is the reason for defining a new set of attributes rather than using an attribute bag such as SAML assertion? Larry: encoding efficiency Leif - can respect not having XML parser - need to have an open set of attribute definitions - use existing attribute semantics w/o hard coding a small set inside of setup Sam: existing attribute fore group list Leif - several groups have done that type of thing Sam: use case here is for a posix platform doing what MS does. Leif: cheap to add attribute definition layer underneath. Then mapping layer as needed. Sam: needs to be extensible - use small integers - IANA registry. ================= Mesh wireless networks sam: - look @ MULTIcast security working group sam - teach about the IPR - any IPR disclosures to date (no) should be filed? (not at this time) ============= SAM for ABFAB = create 4121 token types registry = doing kitten and abfab work - iakerb needs to use the iakerb OID even if you already have kb tokens. Leif - should abfab do this or krb-wg Larry - you can do it. sam - should also publish iakerb jhurtz - review in kb-wg and kitten should probably be done. iakerb status is chair-wait =============== Charter updates: Larry: Consensus on adding new/update enctypes - update charter? tim - yes - informational sam - jeff wants to do a general addition of this to the charter tim - may not be good to be open-ended sam - factors for camellia - international std, many people want to implement - should we have criteria in the charter? tim - would be better sam - I suggest - std track enc types that met the following: openly implementable - iakerb - in proto writeup gss-hash - proto writeup otp - in proto writeup cross-realm setup easier? sam: support it but don't call out specific approaches Authorization data types? no enough experts in the room - is it moot? sam - no important to support nsfv4 and other implementers desirable to have appropriate credential types progressing Kerberos to draft standard what is needed sam: for 4121 - just need a report for 4120 - need to drop the crap out 3962 - would be feasible Don't want to be the editor Leave as general OPEN MIC Tim: You will have a new AD in march - get them to Tim early if you want tim to publish or go to a new AD. sam - esp for the three in the proto-writeup state Shoichi - just posted draft