[08:55:20] --- jaltman has become available
[09:12:40] <jaltman> Today there will be a meeting of Kitten at 3:30EST
[09:38:10] --- jaltman has left
[11:36:32] --- jaltman has become available
[12:04:57] --- mrichardson has become available
[12:17:38] <mrichardson> I'm confused.
[12:17:44] <mrichardson> what meeting are you doing Ken?
[12:24:24] --- wyllys has become available
[12:35:18] --- jaltman has left: Disconnected
[12:36:09] --- raeburn has become available
[12:41:58] --- jas has become available
[12:44:59] --- raeburn has left: Disconnected
[12:54:50] --- DougEngert has become available
[13:16:45] --- jaltman (chair) has become available
[13:17:33] --- jaltman (chair) is now known as Jeffrey Altman (Chair)
[13:20:51] <Jeffrey Altman (Chair)> Presentations to today's working group meeting are available at http://web.mit.edu/jaltman/Public/Kitten/ietf61/
[14:09:45] --- wyllys has left: Disconnected
[14:14:15] --- Jeffrey Altman (Chair) has left: Replaced by new connection
[14:14:17] --- Jeffrey Altman (Chair) has become available
[14:14:17] --- Jeffrey Altman (Chair) has left
[14:14:38] --- Jeffrey Altman (chair) has become available
[14:15:56] --- kenh has become available
[14:17:05] <kenh> mike, what you've see is my scribing from the _last_ kitten meeting.
[14:18:07] <mrichardson> ah.
[14:18:09] <mrichardson> ah.
[14:18:12] <mrichardson> ahah.
[14:18:16] <mrichardson> curious.
[14:25:41] --- tlyu has become available
[14:26:02] --- raeburn has become available
[14:26:02] --- hartmans has become available
[14:27:50] --- mike has become available
[14:27:58] --- ludomp has become available
[14:28:26] --- lha has become available
[14:29:08] --- perry has become available
[14:29:13] <perry> mew
[14:29:14] <kenh> Looks like I'm the stuckee again :-)
[14:29:32] <kenh> Start of the 1st official kitten WG
[14:29:46] <kenh> intro: IESG approval of WG
[14:29:53] <DougEngert> Thnaks Ken.
[14:29:54] <kenh> much active discussion on the list
[14:30:01] --- jhutz has become available
[14:30:18] <kenh> Progress made on defining gss-naming problem; SPNEGO; PROF, C# bindings
[14:30:22] --- sommerfeld has become available
[14:30:26] <kenh> excellent roadmap document by Nico Williams
[14:30:28] --- larry has become available
[14:30:39] <hartmans> Do we have a Martin here?
[14:31:09] --- jlcjohn has become available
[14:31:26] <jhutz> martin is not present at the meeting, and does not appear to be in this room
[14:31:40] <kenh> Recap of charter.
[14:32:07] <kenh> Revise GSSAPI v2 RFC (100% backwards compatible).
[14:32:23] <kenh> Create new GSSAPI v3 specification (not backwards compatible)
[14:33:03] <kenh> (many items flying by, see presentation for details)
[14:33:38] <hartmans> Do we have a URL for the presentation? I thought Jeff was going to make that available
[14:33:43] <kenh> Goals & Milestones:
[14:34:13] <raeburn> http://web.mit.edu/jaltman/Public/Kitten/ietf61/ietf61-kitten.pdf and .ppt
[14:34:55] <kenh> Nov 04 - First meeting
[14:35:12] <kenh> Mar 05 - First drafts of clarifications/update 2
[14:35:26] <kenh> Nov 5 - Submit naming document to IESG
[14:35:37] <kenh> July 06 Submit GSSAPIv3 to IESG
[14:36:00] <kenh> July 06 - C, Java, and C# language bindings.
[14:36:43] <jhutz> mailing list: kitten@ietf.org
[14:37:02] <kenh> Roadmap: draft-williams-gssapi-v3-guide-to
[14:37:12] <jhutz> to subscribe: https://www1.ietf.org/mailman/listinfo/kitten
[14:37:27] <jhutz> archives: http://www1.ietf.org/mail-archive/web/kitten/index.html
[14:37:34] <kenh> First presentation - PRF Function - Nico Williams
[14:38:33] <kenh> Nico: Many applications would like to get key from GSSAPI context
[14:38:45] <kenh> Nico: Dangerous/breaks abstractions
[14:39:32] <kenh> Nico: Proposal: use a PRF seeded with internal keying material.
[14:39:56] <kenh> Nico: Calls to GSS_Pseudo_Random() by the initiation with same context & input result in same output.
[14:40:08] <kenh> Nico: Kerberos V5 GSS Mech PRF
[14:40:33] <kenh> Construct PRF based on Kerberos V crypto framework PRF
[14:40:46] <kenh> Use acceptor subkey for new mechanism
[14:40:52] <kenh> Key usage TBD
[14:41:22] <hartmans> Is the key usage for the 1964 mech or the general mechanism at the GSSAPI layer?
[14:41:45] <jhutz> hrm. good question; I shall go look
[14:42:27] <kenh> Nico: Domain-based names
[14:42:39] <kenh> Three part names: service, domain, host
[14:42:44] <jhutz> clarifications reserves 22-25 for "GSSAPI mechanisms derived from RFC1964"
[14:42:57] <jas> any thoughts on the prf_ready flag, btw? (see recent post to mailing list)
[14:43:16] <raeburn> (getting comments between presentations would be a good idea, instead of rushing from prf to domain-based names...)
[14:43:16] <kenh> Purpose: To allow for simple validation by initiators of acceptors authority to serve domain-based resources.
[14:43:26] <kenh> Sample Uses:
[14:43:31] <jhutz> IMHO that means CFX and other successors But I don't think we want to use one of those numbers for PRF, since we're using all of them
[14:43:57] <kenh> LDAP - Make sure you're talking to an LDAP server that can serve the directory data you care for
[14:44:16] <kenh> NFSv4 - finding namespace roots
[14:44:36] <kenh> In either cases, clients may use DNS SRC records to find servers for some domain, but perhaps not DNSSEC
[14:45:21] <hartmans> Keep in mind kcrypto doesn't take a keyusage for prf (reasonable) so you need to stick into prf input if you want the feature
[14:45:37] <kenh> Domain based naming for Kerberos V5 mechanism: service/hostname/domain
[14:46:05] <kenh> I-D status: Must fold in edits, need more review, security considerations section.
[14:46:19] <kenh> No questions from Nico.
[14:46:25] <kenh> err, "for" Nico.
[14:47:55] <kenh> Presenter for C# bindings couldn't be here, so presentation is being given by Jeff.
[14:48:46] <kenh> C# bindings would be very similar to Java bindings, so was able to use most of the java work.
[14:49:28] <raeburn> draft-morris-java-gssapi-update-for-csharp-00.txt
[14:49:59] <kenh> Note from Jeff: Sun Microsystems org.ietf.jgss is not quite the same as RFC, authors will be submitting a new draft.
[14:50:13] <kenh> SPNEGO bis: Larry Zhu.
[14:50:30] <kenh> Goals: clarifications for RFC 2748
[14:51:07] <kenh> Backwards compatible with existing Windows SPNEGO implementation.
[14:51:30] <kenh> Initial draft published: draft-zhu-spnego-2478bis-00
[14:51:42] <jhutz> For the record, I believe it is entirely reasonable to update RFC2748 to correct those places in which it is not consistent with the actual Windows implementation, for the same reason that it was reasonable in kerberos-clarifications to fix bugs in RFC1510
[14:52:55] <kenh> Significant issues: Safe-to-omit MIC rules: what are they? and when can they be used?
[14:53:57] <kenh> should we protect reqFlags?
[14:54:56] <kenh> SHOULD or MAY use optimistic token? How is the MIC token computed? Do we need out -of-band negotiation with down-level clients and servers?
[14:58:44] <kenh> Sam: The current SPNEGO document assumes that the mech ID is enough to decide whether or not you want to use that mechanism (that's the only thing that is protected)
[14:59:30] <kenh> Sam: We're making things more complicated, because people want to do more complicated things.
[15:00:29] <kenh> Sam: We want to do some sort of negotation, and we should be able to protect it. Also note that if we don't get it right now, we might need to replace it later, and that would be incredibly painful.
[15:01:59] <hartmans> In particular we want to be able to negotiate more than just the mech oid
[15:02:17] <hartmans> Or more like we may want to consider multiple factors besides mech OID in deciding which mech we negotiate
[15:03:36] <kenh> Nico: We need to figure out now if we consider backwards compatibility important (if we realize that we need to break backwards compat, we should do it now).
[15:04:52] <kenh> Love: Don't we have this problem already? How many people are shipping SPNEGO implementations other than Microsoft?
[15:05:04] <kenh> Nico: Sun does (when Solaris 10 ships)
[15:06:15] <kenh> Bill Sommerfeld: If you break backwards compat, you'll have a blank sheet of paper that everyone will want to jump on.
[15:06:53] <kenh> jaltman: Do people think that maintaining backwards compatibility is more important than adding new features?
[15:07:39] <kenh> poll of room showed that out of people that expressed opinion, everyone said maintaining backwards compat was more important.
[15:10:27] <kenh> jaltman: Out of the people who read the draft, should we use SHOULD or MAY for optimistic token?
[15:10:33] <kenh> No consensus reached.
[15:14:19] <kenh> Note that there was strong feelings about not relaxing the MUST NOT.
[15:15:38] <kenh> Larry: Sam raised issue that it's not clear how the MIC token is computed.
[15:16:10] <kenh> Sam: The concern is whether or not the MIC is computed over the OCTET-STREAM, with or without the OID, etc etc.
[15:18:39] <kenh> Sam: gssapi naming draft
[15:18:47] <tlyu> oh right that issue... i think it was because the RFC said "computed over MechTypes", which is a misspelling of the mechTypes member of NegTokenInit. that made it ambiguous as to whether it was supposed to be a MIC over an encoding of MechTypeList or over an encoding of [0] MechTypeList.
[15:19:03] <kenh> Goals: Support authentication of internal identities (uuids)
[15:19:13] <kenh> Allow applications to work with parts of composite names
[15:19:26] <kenh> query available credentials and presented names based on components
[15:19:42] <kenh> Find most appropriate credential for a target.
[15:21:08] <kenh> want to describe problems that we're trying to solve to prevent scope creep.
[15:22:37] <kenh> (Martin Rex points out that you can't do authentication of internal identities portably today)
[15:23:30] <kenh> We think it can be portable, and Nico and I think at least we can do a lot better than we can do today.
[15:26:15] <kenh> Sam: Several levels of GSSAPI v2 compat we need to look at.
[15:26:47] <kenh> New mechanisms used by old applications (should they be visible? Or only do GSSAPI v2 features?)
[15:27:14] <kenh> File formats for ACLs containing names
[15:28:33] <kenh> Possible Solutions: name attributes, GSSAPI credential extensions, client given ability to assert a name, facility for enumerating the credentials that we have, choose different credential depending on the party that they're talking to.
[15:29:10] <kenh> name attributes: names are composed of attributes
[15:29:26] <kenh> attributes are OID label plus something else which I missed
[15:29:40] <kenh> client aserted names: allow clients to assert part of a name to be exported.
[15:29:53] <kenh> tell implementation what part of the name that it gets.
[15:30:15] <kenh> this would provide better compatibility with older applications
[15:30:39] <kenh> credential extensions: add labelled extensions to credentials
[15:30:57] <kenh> similar in functionality to name attirubutes, but requires more changes to contexts.
[15:31:45] <kenh> credential enumeration: Basically a "GSSAPI klist"
[15:32:03] <kenh> facility to find credentials that are available.
[15:33:12] <kenh> sam: Do we want to pick one, or have a document describing solution space?
[15:33:39] <kenh> jaltman: consensus has been reached that we will have a document describing the solution space.
[15:36:17] <kenh> jaltman: Discussion items.
[15:37:03] <kenh> Should mechanism specifications of new GSS extensions such as krb5 prf and Domain based names be done in this group?
[15:37:55] <kenh> sam: I think that Kerberos stuff should happen in the Kerberos space, but I don't care that much (I'd care a lot more if the kitten person wasn't active in the Kerberos WG).
[15:38:23] <kenh> jaltman: That's how I see it as well.
[15:39:03] <kenh> jhutz: in my mind, it's important that the discussion take place in one place, but I don't care where that place is.
[15:39:36] <kenh> jhutz: but if changes to the krb5 mechanism happen here, then it should be last-called in krb-wg as well.
[15:40:47] <kenh> Nico flipped a coin, it was decided that the work should take place in kitten (but last-called in both)
[15:42:44] <kenh> with regards to other mechanisms, we will deal with them as they come up.
[15:44:19] <kenh> with that, jaltman closed the meeting
[15:44:37] --- kenh has left: Disconnected
[15:44:44] --- ludomp has left
[15:45:25] --- tlyu has left
[15:45:59] --- jlcjohn has left
[15:48:36] --- DougEngert has left
[15:48:36] --- raeburn has left: Disconnected
[15:48:49] --- mike has left: Disconnected.
[16:14:07] --- jas has left
[16:17:12] --- mrichardson has left
[16:18:17] --- jhutz has left
[16:19:19] --- Jeffrey Altman (chair) has left
[16:21:10] --- lha has left: Disconnected
[16:27:09] --- hartmans has left
[16:48:44] --- perry has left: Disconnected
[18:27:26] --- mike has become available
[18:33:22] --- mike has left