Kerberos Working Group (KRB-WG) Minutes Meeting : IETF 77, Hilton Anaheim, Anaheim, CA, USA Time : 1300-1500, WEDNESDAY, March 24, 2010 Location: Manhattan Chairs : Jeffrey Hutzelman , Larry Zhu Scribe : Thomas Hardjono ============================================================ (I) AGENDA: (a) Preliminaries. (b) Document Status. (c) Last Call items. (d) Moving Forward. (e) Open Mic. (II) DOCUMENT STATUS (a) Cross Realm Problem statement - Approved, in Editor's queue. (b) Preauth Framework - Will be on IESG Telechat in 2 weeks (April/8/2010). (c) StartTLS - Currently in IESG Review. - Waiting also on outcome on a DISCUSS regarding validating server certs - WG Consensus: layering AS_REQ over TLS is generally a good idea (ie. better than nothing). (d) IAKERB - Completed WG Last Call a few months ago. - Waiting for JHutz for proto eval. (e) Naming/Anonymous - Draft has expired. - Anonymous draft has also expired now. - Sam believes all issues now resolved. - Larry to issue new versions of both drafts. + The Anonymous draft needs a new WG Last Call. + Naming draft just needs update in version-number. (III) LAST CALL ITEMS (a) Kerberos Information Model (v.07) - Update from Leif: + Leif will provide update v.08 + Principal realms must be (will be) single-valued. + Will do English language clean-up. - Q: Should principal realms be single-valued? Sam: Its logical to associate multiple names to the realm. - PrincipalName is multivalued (even in 1 realm). - but Realm is multivalued. GregH: Consensus is that Principal Name must be multi-valued. But does not imply whether principal name includes a realm name. Discussion... seemed to conclude that a principal might have multiple names, each with an associated realm. A principal which exists in multiple realms may not have the same set of names in every realm. - Sense of the room, by hum: + Yes (majority) + No strong objection. + Slight objection from Hank Hotz; he's not sure he understands the implications of allowing multiple principal names which are not all in the same realm. Some others in the room seemed to feel strongly that this should be allowed. (b) Kerberos Information Model: Open Issues - Slides: http://www.ietf.org/proceedings/10mar/slides/krb-wg-1.pdf - Two remaining open items: + Greg Hudson: some implementations don't need canonical principalName for salting keys. + Greg Hudson: no need to separate keys from the rest of the model. - Q: Larry: We still need some semantics to be built into the name for the enterprise case. A: Leif: but this issue is not part of the model. Sam: agrees with Leif. - Consensus checks: (i) Update the text of the draft to clarify that implementations do not necessarilly require the canonical principalName for salting keys ? Consensus call: weak hum, no rejects, 2 Yes on Jabber. Action Item: Leif to update the text to clarifiy this point. (ii) Separating keys from the rest of the model? Discussion: - GregH is not arguing for separating keys, but only that better text is needed to justify this. (Section 6.2.3) - Leif: could people please send suggested text to the mailing-list or to Leif. Note that WGLC ends April 9th 2010. - JHutz: continue discussion on this topic on the mailing-list. Note that although WGLC ended April 9, now that this sub-issue has been raised, it must be answered before we can proceed. (IV) NEW DOCUMENTS (a) Ticket extensions draft - Adopted as WG work item. - Love will modify doc name at next revision/update. (b) Deprecating DES (des-die-die-die) - Adopted as WG work item. - Love says its ready for WGLC. + Sam: just publish it. + Hank: just publish it. - Conclusion: will begin WG Last Call as soon as possible. (c) DHCPv6 Option - Adopted as WG work item. - Will begin WG Last Call as soon as possible. (V) MOVING FORWARD (a) IANA Considerations (draft-lha-krb-wg-some-numbers-to-iana-00) - JHutz: would anyone object to this document? + Sam: Agree that we need to turn over numbers to IANA but uncomfortable in the current registration process. This should not imply level of consensus in the work. + JHutz: "Registration process will be based on WG consensus". - We need to discuss registration procedure on the mailing-list until the next IETF meeting. However, WG will adopt this doc as WG work-item. (b) KDC Schema (ie. Kadmin-by-LDAP) - No documents yet. - JHutz: Anyone interested in this work? Who wants to deploy? Hank: may be Howard Chu (OpenLDAP) would be interested. Leif: lets ask Howard. Love: Howard has already started work (backend store). JHutz: But backend store is not in WG charter. Leif: Ask Simo & Howard to submit their work as draft. - Update the draft-chu-ldap-kdc-schema-00 and resubmit. (c) Camellia Enctype (draft-krb-wg-kanno-camellia-00) - Thomas: Japanese Gov will soon (around 2013) mandate two ciphers to be supported for Japanese government use (namely AES and Camellia). Thus makes sense to address Cammelia now. IPsec WG and TLS WG already have WG work items on Camellia. - JHutz: Should we adopt this as WG work item? - Sam: we should adopt Camellia generally but prefer one Standards Track mode only. Need input from our Standards Track expert (Ken Raeburn). - Shawn: CTS mode is known to have issues. - JHutz: The registration policy for enctypes requires Standards Action or Expert Review. - Consensus check: Should WG adopt Camellia work? + Hank: Yes in favor. + Shawn: What about quality of cipher? - Thomas: same level of quality as AES. + Sam: should just choose one mode of Camellia for Standards Track based on quality. + Tim: Correcting Thomas, Camellia was not one of the 15 candidates for AES competition. + JHutz: Consensus call based on the assumption that if the WG adopts the work at all, it will decide which modes to include and at what level of recommendation; that is, we are not making that decision now. Shall the WG adopt work on Cammelia enctype? - In favor: medium hum. - Against: low hum - Who objects: 1 person (Mike Boyle) objects on the basis of too many enctypes in Kerberos. Fewer algorithms is better. Objection has nothing to do with quality of Camellia. + JHutz: IPR Disclosure from NTT has been received by WG chairs and Security ADs. [ Note - since this disclosure was not yet available for review at the time of the meeting, the previous hum was based on incomplete information. Since the details of the licensing requirements are known to be of significant interest to some WG participants, the chairs do not believe that the results of the hum necessarily reflect what the WG consensus will ultimately be. --jhutz ] (d) Hank Holtz on KX509 - Has a drafty doc on KX509 - Work is based on UMich previous work, thus may have some IP issues. - KX509 is a cert acquisition protocol for a client to get a client-cert. - Questions/comments: (i) GregH: Are these short-term certs ("junk certs")? Hank: Not neccesarilly. Can be used for long life certs. (ii) Hank to all: which WG should this work go into? Tim: Get clearance for the work. And then bring to both PKIX WG and Kerberos WG. (iii) Love: Does not oppose this work, but notes that current KX509 only supports RSA cryptosystem. Hank: Shall update the doc to include other ciphers. (iv) Scott Cantor: Is this an application layer protocol? Hank: - KX509 does not modify Kerberos or PKI. - Provides symmetric opposite of PKINIT. It's a "bridge" protocol. (v) JHutz: It is still within scope of the Kerberos WG. Its not the first time the WG taken-up similar work. - Action Item: Chairs will get together with Hank and Tim to discuss further. (VI) OPEN MIC (b) Comment from GregH on Jabber about GCM-based enc type.