[08:54:16] --- tlyu has joined
[08:55:24] --- hartmans has joined
[08:55:43] --- warlord has joined
[08:55:55] --- lha has joined
[08:56:36] --- leifj has joined
[08:56:37] --- jis has joined
[08:56:43] <jis> Morning...
[09:01:29] --- wyllys has joined
[09:02:00] <jis> clarifications has been approved is in RFC editor queue
[09:02:07] <jis> RFC3961 Published
[09:02:16] <jis> RFC 8962 (AES) Published
[09:02:30] <jis> gssapi-cfx is in RFC Editor queue
[09:02:54] <jis> OCSP for PKINIT is waiting for PKINIT for ballot
[09:02:58] <jis> PKINIT still not done
[09:03:13] <jis> (is anyone seeing my typing?)
[09:03:28] <tlyu> i see you
[09:03:30] <jis> tnx
[09:03:43] <jis> wasn't sure if I was typing into a black hole (or not)
[09:03:58] <jis> Call for PKINIT discussion...
[09:04:17] <jis> Russ(AD): Just get it done
[09:04:29] <jis> no further discussion
[09:04:36] <jis> Tom Yu at bat
[09:05:24] <jis> Update on Kerberos Extensibility
[09:05:36] <jis> draft-ietf-krb-wg-rfc1510ter-00.txt
[09:06:07] <jis> Typed Hole Assignments
[09:06:26] <jis> Should we use relative OID's? Or should we use Absolute OIDS?
[09:06:45] <jis> Absolute OIDs permit organizational OID self assignments
[09:06:53] <jis> Nico: Do we care about the size of OIDs
[09:06:56] --- jhutz has joined
[09:07:25] <jis> Sam: We should talk to SNMP Community, should we be using OIDs for this sort of thing (Enterprise OIDS)
[09:07:53] <jhutz> /help
[09:08:03] <jis> Sam: If OID assingment requires standards action, we should use absolute OIDS
[09:08:11] <jis> /no-help-available-here
[09:08:21] <jhutz> [argh; gaim won't let me change the topic]
[09:08:40] <jis> Authorization data is the only typed element that is "critical" (ap must fail if it doesn't understand it)
[09:08:59] --- jhutz2 has joined
[09:09:35] * jhutz2 has changed the subject to: Kerberos working group - rfc1510ter
[09:11:05] <jis> Anyone else want to scribe, I'm being distracted
[09:11:18] <jis> Sam: We might want to use absolute OIDS for authorization data
[09:11:31] <jis> Easier to ensure no conflicts
[09:12:13] <hartmans> Everyone in the jabber room is physically here and jaltman is scribing for minutes
[09:13:06] <jis> ok
[09:14:23] --- jhutz2 has left: Logged out
[09:14:23] --- jhutz2 has joined
[09:14:24] --- jhutz2 has left: Logged out
[09:16:06] --- Stefans has joined
[09:16:26] <hartmans> Jeff Altman: It would be a good idea for us to use utf8 for anything new.
[09:16:32] <hartmans> tlyu: require utf8?
[09:16:36] <hartmans> jaltman: if possible
[09:17:36] <wyllys> not true, Im on jabber and not physically there.
[09:18:11] --- Stefans has left
[09:18:34] <hartmans> Oops.
[09:18:38] <wyllys> no problem.
[09:18:40] --- stefans has joined
[09:18:41] <hartmans> Are you listening to audio or only on jabber?
[09:18:48] <wyllys> only on jabber. where is audio?
[09:19:10] <jhutz> audio: http://videolab.uoregon.edu/events/ietf/ietf62.html
[09:19:31] <hartmans> http://videolab.uoregon.edu/events/ietf/ietf628.m3u
[09:19:45] <jhutz> slides: http://grand.central.org/krb-wg/ietf62
[09:20:13] <wyllys> Ah, OK. I hear it now.
[09:20:23] <wyllys> thanks
[09:21:14] <wyllys> who is talking now?
[09:21:22] <hartmans> Love
[09:21:40] <wyllys> I think the mic needs to be moved, very hard to hear him
[09:22:42] <warlord> We should tell him to speak louder.
[09:22:53] <lha> I'll do that nex time
[09:23:50] <lha> the comment was that in reality no-really enforceable constraint should only be there if they help the human that reads the structure
[09:25:13] --- raeburn has joined
[09:26:00] <wyllys> Ahh, the problem is that I was listening to the wrong room. The correct URL ietf627.m3u.
[09:26:26] <wyllys> I didnt recognize any of the voices.
[09:27:55] --- DougEngert has joined
[09:28:09] <hartmans> Oooops.
[09:36:11] --- BrianTung has joined
[09:37:29] --- lukeh has joined
[09:37:58] <BrianTung> <poke poke> Is this thing on?
[09:37:58] --- DougEngert has left: Lost connection
[09:38:03] --- tanupoo has joined
[09:38:07] <warlord> brian: no
[09:38:08] <warlord> ;)
[09:38:22] <BrianTung> Darn. Thanks, Derek; I'll try again later.
[09:39:08] --- larry has joined
[09:40:07] <BrianTung> tlyu: We are in the uncomfortable position where ASN.1 features that would aid the protocol developers are not going to be available in free tools.
[09:41:42] <BrianTung> tlyu: Another modification to increase readability--encrypted parts defined separately and then included in tickets by name, rather than in-lined.
[09:42:23] --- leifj has left
[09:42:23] <BrianTung> tlyu: (Polling preference between in-lined and pulled out separately.)
[09:42:40] <BrianTung> tlyu: Detect mild preference for pulling out.
[09:42:58] --- Melinda has joined
[09:44:30] <BrianTung> tlyu: Future plans: Need clarification on how capability negotiation is going to happen between a 1510 implementation and an Extensions implementation.
[09:44:46] <BrianTung> tlyu: We've talked about this, but it needs to go into document.
[09:45:16] <BrianTung> tlyu: Please e-mail me or the list with comments/suggestions on reworking the ASN.1 module.
[09:45:30] <BrianTung> nico: What was the resolution wrt transited field formatting?
[09:46:45] <BrianTung> nico: Especially transiting realms that do not support UTF-8.
[09:47:42] <BrianTung> tlyu: Things might be less painful if we require realm administrators to configure into the KDCs knowledge of what extensions their peer realms are capable of.
[09:47:42] <BrianTung> nico: That's already been done.
[09:48:39] <BrianTung> nico: Shouldn't permit path starting with extensions-capable realms and then progressing to extensions-incapable realms.
[09:49:22] <warlord> doug: what's your opinion?
[09:49:53] <BrianTung> tlyu: Is it sufficient to require KDCs to know about peer support for UTF-8, and also to require that once you transit a UTF-8-capable realm, you no longer transit UTF-8-incapable realm.
[09:50:02] <jhutz> Are people reading here also listening to the audio?
[09:50:25] <wyllys> I am doing both.
[09:50:36] <lukeh> jhutz: I am
[09:50:36] <BrianTung> nico: We can relax this by permitting future transiting of UTF-8-incapable realms if none of the previous UTF-8-capable realms had a non-ASCII character in their names.
[09:50:40] <wyllys> but, I might be the only one not in the room.
[09:51:07] <warlord> wyllys: you are not. At least Doug is also remote.
[09:51:13] <wyllys> ah, ok.
[09:51:24] --- lha has left
[09:51:29] --- lha has joined
[09:51:31] <warlord> (but no idea if he's paying attention or listening to the audio)
[09:55:00] --- sommerfeld has joined
[10:01:49] --- briantung has joined
[10:01:52] --- Melinda has left: Lost connection
[10:02:57] <briantung> jhutz: It's worth noting that there are two different questions.
[10:03:17] <briantung> jhutz: One is regarding vendor extensions, and the other regarding private--that is to say, site-specific--extensions.
[10:03:34] --- larry has left: Lost connection
[10:03:34] --- BrianTung has left: Lost connection
[10:03:34] --- lukeh has left: Lost connection
[10:03:34] --- tanupoo has left: Lost connection
[10:04:36] --- nicow3k has joined
[10:04:45] <briantung> jhutz: In the current specification, there is a restriction that auth-data types cannot be negative.
[10:04:52] <nicow3k> yay, gaim finally worked
[10:04:58] <briantung> jhutz: Q: Do we want to continue in that direction, or change the policy?
[10:05:18] <briantung> jhutz: This is orthogonal to the question of who gets to have positive numbers.
[10:05:34] --- DougEngert has joined
[10:05:36] <briantung> jhutz: I'd like to have a poll on the private use issue, but first...
[10:05:48] <briantung> jhutz: Do people agree that the issues are orthogonal?
[10:05:50] --- Melinda has joined
[10:06:50] <briantung> jhutz: Q1: What is the policy for assignment of coordinated typed-hole numbers?
[10:07:16] <briantung> jhutz: Q2: Will there be a portion of the name space reserved for site-specific extensions?
[10:07:29] <briantung> jhutz: Do we or do we not have to answer Q1 before we can answer Q2?
[10:08:05] <briantung> hartmans: The only argument I can see that links them is that if the policy in Q1 is very liberal, then we may not have abuse of the private-use space.
[10:08:14] <wyllys> I think there is a dependency.Answer Q1 then decide Q2.
[10:08:34] <briantung> jhutz: Conversely, if we have a very strict policy, then we may likely have abuse.
[10:09:21] --- lukeh has joined
[10:09:30] <wyllys> I think they are!
[10:09:35] <briantung> jhutz: It seems pretty even.
[10:09:37] <nicow3k> I think so too
[10:09:53] <briantung> jis: They may be linked; that doesn't necessarily dictate the order in which they must be discussed.
[10:09:56] <lukeh> from what Sam says it sounds like they are dependent
[10:10:17] --- larry has joined
[10:10:27] <lukeh> what is the existing policy? vendors are already using positive numbers for, eg, preauth types
[10:11:24] <lukeh> eg. protocol transition in W2K3
[10:11:27] * hartmans Wonders how many people will choose not to come to meetings because the audio/jabber is good enough
[10:11:35] <lukeh> hey, it is 3am here
[10:11:44] <briantung> jhutz: The current policy is that if their coordinated numbers, you go through Cliff.
[10:11:57] <wyllys> I'd prefer to be there, not necessarily for the actual meetings, but for the offline interactions.
[10:12:15] <briantung> jhutz: For negative numbers, the policy is for auth-data, don't use them; for the other typed-holes, use them, but only site-specific.
[10:12:15] <lukeh> is there a registry somewhere?
[10:12:18] <hartmans> Sure but I'm wondering about attendance numbers etc.
[10:12:30] <DougEngert> Its a mater of travel funding, I agree with wyllys.
[10:12:34] <briantung> jhutz: I don't know of anyone who does this (aside from the magic negative checksum).
[10:12:40] <nicow3k> it's better to come
[10:12:44] <lha> lukeh: yes there is registery
[10:12:45] <nicow3k> but if you can't travel
[10:12:54] <nicow3k> then chat is great
[10:12:56] <lha> lukeh: I asked you question in the room
[10:13:01] <lukeh> thanks, I heard
[10:13:07] <briantung> raeburn: negative numbers for enctypes/checksums are for private use only.
[10:13:35] --- nov has joined
[10:13:56] --- nov has left
[10:13:57] <briantung> tlyu: We have a general direction for where the ASN.1 module should go, but some details need to be hashed out. Anyone disagree?
[10:13:59] <briantung> (stunning silence)
[10:14:04] --- nov has joined
[10:14:12] --- Melinda has left: Replaced by new connection
[10:14:12] <raeburn> rfc3961 says "private use; local and experimental algorithms should use these values"
[10:14:20] <briantung> jhutz: These will go to RT tickets and discussion on the mailing list.
[10:14:20] <raeburn> (and then there's Microsoft...)
[10:14:20] --- Melinda has joined
[10:14:49] <briantung> larry: This is on referrals.
[10:14:59] <briantung> larry: No updates since last meeting. I encourage people to review it.
[10:15:16] <briantung> larry: Will update to introduce smart-card (?) into next version.
[10:15:54] <briantung> larry: Now on to enctype negotiation.
[10:16:12] <briantung> jhutz: This was mentioned on the mailing list a couple of weeks ago.
[10:16:25] <briantung> jhutz: Please hold praise/blame until after the presentation.
[10:16:51] <briantung> larry: draft-zhu-kerb-enctype-nego-00.txt
[10:17:08] <briantung> larry: Purpose is to allow enctype negotiation without involving KDC. (?)
[10:17:36] <briantung> larry: implementation lukeh in Heimdal.
[10:17:40] <jhutz> I actually said "objections, whining, and also intelligent and insightful questions"
[10:18:19] <briantung> I know, Jeff, but my fingers aren't quite that fast.
[10:18:48] <jhutz> :-)
[10:18:58] <briantung> larry: The client sends a list of enctypes in an authorization-data in the AP-REQ.
[10:19:18] <briantung> larry: Enctypes in decreasing order of preference. Wrapped in an AD-IF-RELEVANT.
[10:20:35] <briantung> larry: Server selects an enctype from the list; this is then sent in the subkey field of the AP-REP.
[10:21:06] <briantung> (Insert nonsensical question from me due to lack of sleep, omitted.)
[10:21:34] <briantung> hartmans: I would recommend this only be used in conditions where server subkey "wins"; won't work otherwise.
[10:22:45] <briantung> nico: It seems clear that it doesn't break anything.
[10:22:50] <briantung> nico: Unclear who will use it.
[10:23:34] <briantung> nico: How would applications decide to use this?
[10:23:54] <briantung> hartmans: If your application supports it, and it makes sense in the current environment, then use it.
[10:25:56] <briantung> hartmans: You might want to have some text (GIANT POUNDING): If you end up negotiating something like AES, you'll need CFX tokens.
[10:26:09] <briantung> (Did I mishear this?)
[10:26:38] <briantung> jhutz: The negotiation is safe to use whenever a server subkey wins.
[10:26:50] <hartmans> If we suddenly go off net, it's probably a giant crushing us all not a network problem
[10:26:52] <briantung> jhutz: This includes CFX, and also selected application protocols.
[10:26:58] <raeburn> someone remind me, is this data (the enctype list) protected in this extension, or subject to substitution?
[10:27:08] <jhutz> No, you didn't mishear that.
[10:27:08] <hartmans> It's protected
[10:27:19] <jhutz> It's authorization data, so it's protected
[10:27:22] <raeburn> ok.
[10:27:23] <jhutz> I'm pretty sure.
[10:27:28] <nicow3k> (the pounding was on the floor above)
[10:27:48] <briantung> larry: Can this be accepted as a working-group item, and if so, do I need to resubmit it?
[10:28:31] <briantung> hartmans: Which implementors would find this useful? Who generally would find this useful?
[10:28:46] <lukeh> I think it's probably more useful to customers than implementors
[10:28:52] <nicow3k> right
[10:29:27] <briantung> jhutz: Several hands for useful.
[10:29:32] <briantung> nico: Modestly useful.
[10:29:45] <briantung> jhutz: Some hands for no effect.
[10:29:55] <briantung> jhutz: No hands for harmful.
[10:30:26] <briantung> Matt Peterson: Would you be able to replay lists to encourage selection of a weaker key?
[10:30:53] <briantung> larry: The replay should be taken care of by virtue of it being sent in the authenticator of the AP-REQ.
[10:31:43] <briantung> jhutz: It's worth noting that this is authorization data in an AP-REQ, meaning that it is encrypted, and therefore (in Kerberos) integrity-protected.
[10:32:00] <briantung> jhutz: So, unless you can't detect a replay of an authenticator, you should be OK.
[10:33:28] <briantung> hartmans (as AD): You should look at the charter and make sure it fits. Otherwise, if people find this useful (and it seems they do), and you want it, then it should be a standards-track document in this WG.
[10:34:18] <briantung> jhutz: By the letter of the charter, it doesn't seem to fall in, but precedence would seem to suggest otherwise.
[10:34:38] <briantung> jhutz: Do people think that it would be beneficial for this work to proceed along the standards track?
[10:34:44] <briantung> jhutz: One-sided in favor.
[10:35:05] <briantung> jhutz: Should the group adopt this as work item?
[10:35:09] <briantung> jhutz: Also one-sided in favor.
[10:35:26] <lukeh> does one-sided mean that only larry put his hand up?
[10:35:40] <briantung> jhutz: So adopted. No need to use a new file name until the IETF discussion thread on file name changes concludes (if it concludes).
[10:35:45] <warlord> no.. lots of people had hands up
[10:36:11] <briantung> nico: I have no slides, because nothing has changed in set-passwd.
[10:36:33] <briantung> nico: We had a milestone for consensus on whether this was the right direction. Is this document the right direction for this protocol?
[10:36:42] <briantung> jhutz: Rather, how many people have read this document?
[10:36:54] <lukeh> yes, but not closely
[10:37:06] <briantung> Some ten people have read this document.
[10:37:11] <lukeh> it seems quite complicated
[10:37:17] <wyllys> hand!
[10:37:27] <warlord> how many people believe this is the right way to go?
[10:37:28] <briantung> jhutz: Now, how many people think this is the right direction?
[10:37:43] <wyllys> hand!
[10:37:45] <briantung> Mild consensus for.
[10:38:11] --- tanupoo has joined
[10:38:18] <briantung> Luke, which part seems complicated?
[10:38:19] <wyllys> one for reading it and one for in favor.
[10:38:27] <briantung> Yeah, we figured that out.
[10:39:03] <briantung> nico: The ASN.1 part is more complicated, especially the part that deals with how errors are handled.
[10:39:15] <briantung> nico: I'd like feedback on this, on how complicated this is. (Too complicated?)
[10:39:41] <lukeh> I don't have a concrete response
[10:39:53] <briantung> leif: The protocol is probably *necessarily* complicated.
[10:40:02] <lukeh> concur with Leif
[10:41:19] <briantung> leif: Does localization have to happen?
[10:42:44] <briantung> nico: The localization stays unless we are willing to burn in specifics into the draft.
[10:44:01] <briantung> hartmans: I think a lot of cases where server errors are not intended for the user, but I agree with nico: not in this case. You must be able to tell the user directly, or to have a representation with the client who can then pass on the significance to the user.
[10:44:16] <briantung> jhutz: I like to be able to set policy based on what my policies are, rather than what a spec dictates.
[10:45:48] <briantung> larry: We may have problems implementing this if we do server localization, but we'll deal with it if we have to.
[10:46:03] <briantung> larry: Is this the way of the IETF now?
[10:46:04] --- tanupoo has left: Disconnected
[10:46:38] <briantung> jhutz: We can choose to have a set of numbers, or a set of strings. And if we have a set of strings, and they're intended for users, then they need to be localized.
[10:47:31] <briantung> hartmans: Larry, if I read you correctly, in most cases, errors aren't meant for users, and we do localization on the client.
[10:47:40] <jhutz> leif points out those aren't the only two options; we could have some more complex structure
[10:48:46] <briantung> hartmans: One possible approach is to have a list of errors going from most general to most specific, where the first item in the list must be understandable by the client.
[10:50:30] <briantung> hartmans: Some errors might be local codes.
[10:50:34] <briantung> jaltman: NOOOOO!
[10:52:30] <briantung> nico: In Unix, we don't have a good interface for doing localization with locale as an argument. But the code exists; creating the interface is not a huge problem.
[10:53:02] <briantung> hartmans: In practice, you probably wouldn't have site-specific error codes.
[10:53:36] <briantung> hartmans: Although you might have vendor-defined codes that can apply broadly.
[10:54:46] <briantung> leif: There are many contexts where this kind of problem exists; solving it for set-passwd may be just a drop in the ocean.
[10:55:50] <briantung> jhutz: It might be the case for password policy that users frequently figure out what the policy is based on what the server will and will not allow.
[10:56:01] <briantung> jhutz: I say this from personal experience in cases where the policy is not made public.
[10:56:50] <briantung> jhutz: The point is, if I have to submit a new password Friday, I shouldn't have to wait until Monday to find out why it didn't go in.
[10:57:05] <briantung> leif: My main point is that this is too large a problem to be solved effectively with just server-side localization.
[10:57:51] <briantung> jaltman: One other possibility is that we could have error codes that point into a policy list held locally.
[10:58:04] <briantung> love: I don't like error codes that just say "invalid argument."
[10:59:10] <briantung> love: But passing strings doesn't always work because localization may break at the user.
[10:59:22] <briantung> jhutz: Here's something that is either better or hideous, or possibly both.
[10:59:54] <briantung> jhutz: Could we have standardized error codes that are parameterized?
[11:00:20] <briantung> jhutz: Relatively small and stable set of error codes, and greater flexibility.
[11:01:03] <briantung> nico: The draft currently has both server-localized strings and an enumerated error code.
[11:01:09] <briantung> nico: I would like to eliminate one of them.
[11:01:22] <hartmans> ed has a great solution to this problem.
[11:01:38] <briantung> jhutz: We declare end of discussion on this topic in about ten minutes.
[11:01:54] <briantung> Sam, who?
[11:02:08] <hartmans> ed - the standard text editor
[11:02:14] <lha> >
[11:02:16] <lha> ?
[11:03:03] <jhutz> Isn't ed's solution to emit cryptic machine-readable errors directly to the user?
[11:03:58] <warlord> ed's error is '?' for all errors..
[11:04:21] <warlord> not very cryptic, but certainly not user-friendly, either.
[11:04:34] <warlord> but it's not locale-specific, and you don't have to worry about localization issues.
[11:06:02] --- briantung has left
[11:06:15] --- BrianTung has joined
[11:07:15] <BrianTung> ping
[11:07:25] <warlord> hi brian
[11:07:35] <BrianTung> I lost network connectivity for a moment.
[11:09:36] --- wyllys has left: Disconnected
[11:10:52] <BrianTung> leif: When would a multiple client situation actually happen?
[11:11:17] <BrianTung> nico: Clusters. (Much as one might say "plastics.")
[11:12:05] <BrianTung> jhutz: Now on to milestones.
[11:12:31] <nicow3k> brian: good interpretation!
[11:12:31] <BrianTung> We have last-called OCSP. (Deadline was for November 2004.)
[11:13:37] --- Melinda has left
[11:13:42] <BrianTung> We have not last-called PKINIT. (It was due November 2004.)
[11:14:08] <BrianTung> larry: We have solutions to the issues, we just don't have consensus on those solutions.
[11:14:12] --- jis has left
[11:15:36] <BrianTung> jhutz: I have two concerns as chair. One, there are issues that have not reached consensus in the mailing list that have nonetheless made it into the draft. Two, we have the potential for creeping featurism.
[11:15:55] <BrianTung> love: I think it is moving forward.
[11:16:58] <BrianTung> jaltman: The rate of change and the rate of consensus declaration has been too fast.
[11:19:44] --- stefans has left
[11:19:48] <BrianTung> jhutz: I'm going to propose April for last-calling PKINIT.
[11:20:37] <BrianTung> jhutz: Consensus on direction for set-passwd can be done for this month.
[11:20:47] <BrianTung> jhutz: Tom, where are you on extensions?
[11:20:52] --- stefans has joined
[11:20:59] <BrianTung> tlyu: It is optimistic to assume we can resolve all major issues by end of March.
[11:21:55] <BrianTung> hartmans: I would advocate May for issue resolution, August for last-call.
[11:22:06] <BrianTung> jaltman: I recommend June for issue resolution.
[11:22:24] <BrianTung> hartmans: Larry's negotiation draft needs a milestone if we add it.
[11:23:27] <BrianTung> larry: Move last-call on referrals to August?
[11:24:23] <BrianTung> jhutz: enctype negotiation to IESG in May?
[11:24:25] <BrianTung> larry: OK.
[11:24:54] <BrianTung> jhutz: last-call on set/change passwd in September OK?
[11:25:02] --- hartmans has left
[11:25:24] <BrianTung> nico: Need review on synchronization between clients and clusters, and deal with localization.
[11:26:24] --- tlyu has left
[11:26:26] <BrianTung> jhutz: We're done!