69th IETF - Kitten Working Group Minutes =============================== Location: Chicago, IL - Palmer House Hilton - Room Salon 3 Time: 7/25/07 at 1:00pm Chairs: Alexey Melnikov Shawn Emery Scribe: Jeffrey Hutzelman Security Area Director: Sam Hartman Action Items: ========== Help the kitten-wg solve the IDN problem: krb-wg Update milestones (remove pseudo-mechs and add IANA draft): chairs Update charter (remove C#-bindings requirement if no response from wg list): chairs Review draft-ietf-kitten-extended-mech-inquiry-02: Larry Zhu, Ken Raeburn, Jeffrey Hutzelman, and Sam Hartman Review draft-ietf-kitten-gssapi-extensions-iana-01: Jeffrey Hutzelman, Kurt, and Philip There was consensus that draft-josefsson-password-auth-00 was more in scope with the sasl-wg and requires further investigation: sasl-wg Submit an informational draft to cover export partially-complete contexts: Leif Johanssen People that would review said document: Sam Hartman, Ken Raeburn, Nicolas Williams, Philip, and Alexey Melnikov Conference Session: ============== Agenda was presented with no bashing. Active Work Items ------------------------ See presentation. In regards to draft-ietf-kitten-gssapi*domain-based-names-03: ------------------------------------------------------------------------------ Nicolas Williams: We have to specify which is a domain-name slot and which isn't. Jeffrey Hutzelman?: We specify that both the "domain" and "hostname" are. Sam Hartman: i18n can be broken down into two issues: 1. What does a particular mech use on the wire? 2. What do I pass to the API? Once you answer (2) for GSS_Import_name_UTF8, the answer is obvious for other APIs Nico: ToUnicode is the identity function when input is unicode, and ToACE [toASCII?] is identity when the input is all ASCII, not ACE, and appropriate for use in DNS labels. Sam: I think this is a case where "be liberal in what you accept" makes a lot of sense; we should say implementations must accept either a-labels or u-labels. Nico: When importing names, mechanism must call ToASCII or ToUnicode as appropriate; cannot pass it along unmodified unless the next API has the same propery. For display names, we use UTF-8. Sam: Callers must pass in ASCII or ACE to gss_import_name. Sam: Returning ACE or Latin-1 for display names are reasonable therefore we can say that implementations SHOULD return ACE, but not MUST. Nico: Non-internationalized interfaces take ASCII or ACE; SHOULD output ACE. Nico: Internationalized interfaces MUST accept UTF-8 or ACE; should output UTF-8. Sam: We should tell the Kerberos WG what that we need an answer now on what they are going to do in regards to host names. Sam: The issues is that 4120 has idna-unaware [hostname] slots. Jhutz: I don't believe 4120 contains domain-name slots Sam: Host-based principal names. In regards to draft-ietf-kitten-gssapi-channel-bindings-02: ------------------------------------------------------------------------- Nico: Needs to align and depend on draft-williams-on-channel-binding. Nico: Needs to be aligned with updates to TLS channel bindings I-D's. Martin Rex: Has thought about channel bindings and hopes to review said documents. In regards to draft-ietf-kitten-stackable-pseudo-mechs-02: ------------------------------------------------------------------------ Nico: Needs a lot of work and needs description of how to figure out possible composite mechs. Nico: However, applications know how to negotiate mechanisms better than negotiating mechanisms. For example, ssh, SASL, etc. chairs: So, should it be put on hold until... Nico: ...until a consumer comes along. Will affect milestones (removal of current). Sam: [does not object]. In regards to draft-ietf-kitten-extended-mech-inquiry-02: ---------------------------------------------------------------------- Nico: Needs intro and sec cons text. Nico: If we drop stackable pseudo-mechs, we drop a bunch of attributes, but this is still useful. In regards to draft-ietf-kitten-gssapi-naming-exts-02: ----------------------------------------------------------------- Nico: needs some work - how do we handle...AD-AND-OR, negative auth data, ...? PKIX stuff...? Sam: I think the PKIX stuff is important, but it's important to get it review. Sam: In the long term, I think this is one of the most important docs in the sec area, if it ever gets implemented. Sam: May need to be prepared to split out the API from the attributes. What might happen is someone needs the API urgently, can't wait for us to specify all the attributes. Nico: So, should I split into multiple documents? Sam: I wouldn't object if you did. Martin: There are two conceivable approaches: being able to query particular attributes, or being able to query all attributes (getting back an attribute value pair of whatever there is). There are several possible containers, though: Issuer, Subject, SubjectAltName, PolicyConstraints. In regards to draft-ietf-kitten-gssapi-extensions-iana-01: --------------------------------------------------------------------- Nico: Needs review of registration form/procedure, initial prefix registrations, and initial contents. Jhutz: We need to collect registrations from existing documents. chairs: We need a milestone. Nico: WGLC end of October? chairs: Anyone to volunteer for reviewing this (iana)? [kurt, philip raise hands] In regards to draft-ietf-kitten-gssapi-csharp-bindings-00: ---------------------------------------------------------------------- chairs: need an editor for the C# bindings draft. any volunteers? [no answer from room or jabber] Sam: Check the list before dropping. In regards to C-bindings (v2u1): ----------------------------------------- chairs: We need an editor for the C-bindings draft (v2u1)? Jhutz: jaltman says he is no longer editing the c-bindings update, and does not have partially-complete text to hand off. Nico: I kind of really want app context handles, but don't have time to edit another doc. In regards to draft-josefsson-password-auth-00: ----------------------------------------------------------- Sam: I was looking at simon's password auth draft. It is similar to what sasl is doing, and would be unacceptable overlap for this group to take it on. I will talk to sasl chairs; make sure it got sufficient consideration there. In regards to draft-zhu-pku2u: -------------------------------------- jhutz: PKU2U is hopefully ready to go to IESG soon as an individual submission. Now would be a good time to review and send comments to larry. Open Mic: ------------- Leif Johansson: We need to able to export partially-complete contexts, in order to be able to do HTTP negotiate with more than half-round-trip mechs [right?] Martin: It may work by chance/coincidence for one particular implementation (and for a similar specific platform architecture), but I don't believe that transferring gssapi security contexts can (or should) be made in an implementation-independent fashion. Nico: You can assume the importing implementation will be the same, so the token can be implementation-dependent. chairs: People interested in reviewing this document? [volunteers to review: hartmans, ken, nico, philip, alexey] chairs: Who will volunteer to edit? [volunteers to edit: leifj] Leif: Do people prefer a separate function? Sam: I think you will, because currently the OID in an export token is required to be the mech OID, and you want to be able to distinguish tokens emitted by this from tokens coming from export_context or other things. Sam: ... you probably want tokens emitted by this to have an implementation-specific OID, and a requirement that if the token format changes, so does the OID. Sam(AD): I think this requires a charter change. Martin: Informational document:yes, standards track document if that feature is a requirement, probably not. Nico: Which track it goes into won't have any impact on whether you're required to implement it. Sam: ...or you could do it in an old function, and have it return an error as today if not supported. Nico: I prefer a separate function [me too: Sam, Jhutz] Sam: I'm assuming that is an application matter. In Leif's case in a symmettric key shared among all the servers in a cluster. Leif: Right - in the use-cases for this ad-hoc key distribution is probably not a big deal and may already be in place. Martin: One of the issues of proto-contexts: they may contain a reference to a hardware crypto token (open file handle or else) which may be needed for processing specific context level tokens, and that may not be easily transferable. Leif: You're right, it won't be a solution which works everywhere. Martin: There already were complaints about not being able to extract a delegated credential from a exported&imported security context. The semantics are more difficult if the security context isn't even fully established. ----------------- Session over.