Kerberos WG IETF 81 Quebec * Meeting starts, Sam displays Note Well, and sends out bluesheets * Scribe: Leif * Agenda walk-through, no agenda updates * Document status 4 RFCs published since last meeting: Naming, Anonymous, Preauth fwk, StartTLS Submitted OTP preauth, GSS hash agility, clear text credentials Ongoing: - DHCPv6 options additional WGLC needed, coordinate with DHC chair to do a joint WGLC with that WG - KDC model needs PROTO writeup - Generalized PAD adopted without presumption of consensus. Prioritize the work - Pkinit hash agility consensus call needed, re-issue draft - DES Deprecation need to address open issues from sam and simon - IANA resolve registration policy, discuss during meeting - Ticket extensions keep on back burner for a while until other things finishes * Technical discussion - IANA registries Love proposed a draft to move all registries to IANA. Several registries are non-controversial but 3 require more discussion. Notably: preauth types, auth data types, ticket extensions. Thomas Narten (TN) invited to talk about what the IETF has done for IANA registries in the past. TN: IANA is a place to run registries, IANA doesn't hold authority over registries. TN goes through IANA registration policy, including expert review. Adivce: think carefully about setting up registries from the start. TN: it is reasonable for IANA to run the registries for kerberos. "Write down the policy now so it makes sense 6 years from now.". Sam: clearly IANA will be better that what we have today. The issue is that for some things we want a low bar - do we want expert review or just first-come-first-serve? Sam: experience from 6113 say that we should not be too prescriptive when it comes to expert review. Can we evolve instructions for the expert review? TN: yes the expert can do anything that the community is fine with. Sam: do we want to encourage public review and security review for extensions? TN: you can write expert instructions to the effect that extensions that follow the intent of the protocol is fist-come first-serve but other things require standards action. Stephen Farell (SF): there are other examples of this. TN: add escape clause for IESG approval. Sam displays 6113 on beamer (section 7.1). Sam: this is misleading to the person making a registration request - you need a public spec in order to get a security review. Sam: do we want to encourage public specifications and security review of registrations? TN: you can make expert review under NDA but that isn't used often. Sam: I would never take on liability under NDA. Jim Schad (JS): registries are important - Private experimental is better than nothing. TN: don't understand that. JS: sometimes being able to tell why an extension is dropped on the floor is better than not knowing anything. TN: but you have to handle unknowns all the time... Greg Hudson (GS) from jabber: Prefer looser registration guidelines when there is no shortage of values. Cost of conflicts higher than the cost of having bogus assignments. Another jabber channel: also believe restrictive conflicts would be detrimental. Sam: concrete proposal: expert review space but say that the factors that go into the decision will evolve over time and that the bar at the start will be very low basically only excluding registrations that substantially change the protocol. We should be very open but we don't really know where we want to be. Alexei Melnikov (AM): can you envision a situation where the state-mashine of the protocol changes? Sam: yes. In that case a draft should be submitted to the krb-wg. TN: the appeals process would lead to the IESG and then the WG would be consulted. Sam: there will be a pool of experts. TN: give experts clear guidance in terms of principles and not in process. I will be happy to review any proposed text. Sam: I will volonteer to propose text. Jeff H or Larry will judge consensus in this respect. Sam thanks TN for helping out with the IANA discussion. * Generalized PAD Not a lot of list discussion. Thomas Hardjono (TH) leads discussion. TH: Nico posted a list of suggestions and questions. Some relate to SAML - that wasn't part of our design. TH: lets look at Nicos questions. https://lists.anl.gov/pipermail/ietf-krb-wg/2011-July/009342.html Sam: what is the PAD-Short-Domain short domain used for? Discussion on jabber at this point. TH: we need a tighter definition of this. TH: next - Session ID attribute. Sam: handle as ticket extension (?) TH: next - format of home directory. Sam: there has been discussion of this - URI or local path. As implementor you need local path. How much do we want to be following Luke Howards POSIX schema? URIs allow automounter-like semantics but you need to explain what the local path looks like anyway. How uniform do we want the environment to be? Simo Sorce: you always need a local path, URIs would be in addition to the local path. Sam: more comments please? Leif: keep it tight to POSIX schema. Shawn Emmory (SE): more information is better - more to base authorization on. Simo: homeDirectory is optional. TH: multiple values for pad-posix-shell. Leif: that would be confusing for the user. Sam: yes and it is also a question of extensibility. Sam: do we want to exten the posix schema or do we want to do something general later based on SAML or other claims-y thing? Simo: fine sticking to 2307 fields too. Leif: mutliple value fields in LDAP isn't order preserving so in 99% of the case the KDC won't be able to treat this as a list of preferences. Simo: yes loginshell is single value in 2307. Leif: prefer to stick to 2307 tightly. Sam: consensus call: single value or mutliple value. Single value holds consensus. TH: PAD-fullname. Sam: what does 2307 do. Simo: CN. Leif and Sam talk about weather to use the gecos field from 2307. Leif: when in doubt be consistent with 2307. Sam: consensus call: absent any consensus otherwize we should be consistent with 2307. Consensus holds. TH: PAD-alternativeNames. Simo: optional attribute. Sam: making it a URI seems wrong. Sam: will investigate further. TH: PAD-Posix-GID. Nico suggests to remove. Leif: this won't work because order preserving from LDAP won't work. WG consensus to leave it in. TH: Nico: PAD-Groups -> PAD-Posix-Groups. TH: Does this only mean naming? Simo: oppose this. It could be used for non-posix groups too. Not enough support to change this. TH: Groups that don't have GIDs,eg netgroups. Simo: need more discussion on the list. TH: ID mapping. Sam: suggest we don't have this discussion here. Leif: suggest we prune the list based on todays discussion. TH: will do that. Leif: offer to review this document and 2307. * Future Work Sam: Cross-realm keying. Automated keying for cross-realms. This has been around for a while going back to PK-CROSS. PK-CROSS died because it needed ticket extensions. Sam: who is interested in working, writing text, reviewing etc proposals in this space. TH: we've had multiple presentations in this space from notably japanese participants. Sam: yes we even have a problem statement document. Tom Yu (TY): why did PK-CROSS die? Sam: perhaps because of ticket extensions. Leif: it needs PKI bridges etc right? Sam: yes. Leif: that is unlikely to materialize. Sam: There are other approaches. TY: Love has suggested using PK-CROSS without PKI infrastructure but using X.509 certs. Ca 4 hands went up. Sam: who will implement? MIT raises hands. Sam: we are light in the room today. Perhaps we need a call for proposals on the list by end of February - eg the 00 deadline for the Paris IETF. Sam will do a call for proposals along those lines on list. * Camellia Sam: the WG has been asked to adopt draft-hudson-krbwg-camellia-cts as a WG item. Sam: this is subject to IANA registration but there are reasons to do the work in the WG anyway. Also there has been discussion around having a "hot-spare" for AES. This relates to security-directorate around fall-back/hot-spare for AES. The WG can go ahead but we need to comply with the consensus in the IETF when/if it materializes around camellia. TH: describes status of work. We are shooting for standards track but not mandatory for implement. TH outlines the case for camellia. Sam: Tom made a recommendation to adopt specifically as a fall-back to AES. TY: makes case for having a "warm-spare" for AES - as Schneier sais: "attacks only get better". SE: channeling jabber (missed the details). SF: new modes will get reviewed carefully (?) SF: Sam sent questions to the list why not review them. Sam: yes! Sam: lets talk about Toms suggestion. Leif: why talk about hot-spare status before adopting wg document. Sam: we might have more enthusiasm for camellia as a hot-spare. JS: I am in favor of having a fallback for AES but camellia should not be the one just because it was the first in the door. Sam: is the AES fallback question important for the desision to adopt the document as WG item? Consensus seems to be that these are independent questions. Sam describes insanely complicated process for figuring out what to do. JS: don't support adopting now. Leif: supports. SE: conditions for adopting? Room talks about which other mechanisms might appear. SF: lists a few of them. 7-2 for adopting draft-hudson-krbwg-camellia-cts. Sam: against but would support if we made it for AES fallback. Sam: who will implement? Sam: should this be standards track? 4-2. Sam: that is rough. Leif: why not standards-track. JS: only stuff core to Kerberos should be standards track. Sam: yes - standards track means this is a great algorithm to use. Leif: why not expermental. Sam: authors won't accept that. SE: which of the candidates are reasonable? Sam: GHOST is out as being broken. Basically only AES, Camellia and possibly SEED has broad international support. TY: SEED is ISO std. Sam: who will review if we adopt other than authors? Jeff Hutz (JH) from jabber: the question of the standards track status of the document is of minimal interest. The question should be if the WG wants to spend time on the document or not. Lack of support is a concern to me. Sam: Lets move on to the AES question - should we have a fallback or not? Leif: I would assume that the best approach is to have as many as possible ready to go at short notice. Sam: consensus call pretty clear in favor of having fallbacks. Sam: possible alternatives: 3DES or RC4? SF: this will probably not happen "overnight". Leif and SF talks a bit about how long time to expect for a transition to new algorithms. Sam: do we need fallbacks? ~5 hands up for the need for fallbacks. None against. Sam: weak consensus. Sam: how do we want to choose fallbacks (suggested by SF). JS: the only existing fallback is RC4 today. How well are the implementors doing with other crypto today? TY: we should not be doing crypto alg evaluation of our own. TY: we should just standardize all the winners of reasonable contests. SF: don't do a contest. Just pick a reasonable set of criteria. Jeff (channel) Lets frame some questions to the list. Sam: out of time. Open mic issues? SF: if you get consensus on a backup that may increase the likelyhood of a broader consensus. If you _do_ find something then different IPR considerations might apply. I'm sceptical that it will happen that way. Sam: asking for volunteers to get a few documents out the door as editors.