[10:12:45] --- mg has joined
[10:12:51] --- mg has left
[11:31:21] --- mrex has joined
[17:11:42] --- ietf-meeting has joined
[17:14:23] --- ietf-meeting has left
[18:06:06] --- ietf-meeting has joined
[18:13:25] --- mrex has left: Disconnected
[18:19:06] --- jhutz has joined
[18:20:03] <jhutz> Thanks for posting the audio URL, Martin.
[18:31:30] --- semery@jis.mit.edu has joined
[18:32:44] <jhutz> Meeting materials for today's session can be found online at https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=69
[18:42:40] --- hartmans@jis.mit.edu/owl has joined
[18:42:57] <hartmans@jis.mit.edu/owl> test
[18:42:59] --- Simon Josefsson has joined
[18:43:53] --- tlyu has joined
[18:44:26] --- raeburn☺ has joined
[18:46:14] --- shpark has joined
[18:46:49] --- lzhu has joined
[18:47:01] --- stefan.santesson has joined
[18:47:18] <hartmans@jis.mit.edu/owl> Hi, shpark. Welcome. I don't think I've seen you before
[18:48:31] --- mrex has joined
[18:48:33] --- stefan.santesson has left
[18:48:43] --- stefans has joined
[18:52:57] --- nico has joined
[18:53:20] <mrex> awww- can't get audio to work...
[18:55:54] --- kasumigaura has joined
[18:58:19] <jhutz> Who here is not at the meeting/
[18:58:40] <Simon Josefsson> is there a draft available for what Sam is talking about?
[18:58:56] <Simon Josefsson> jhutz: i'm not physically present
[18:59:01] --- kasumigaura has left: Replaced by new connection
[18:59:02] <raeburn☺> Not yet afaik.
[18:59:23] <lzhu> it is the KERB-FAST document
[18:59:33] <lzhu> it has most of the elements but not all
[18:59:40] <jhutz> Well, draft-ietf-krb-wg-preauth-framework-06.txt describes FAST
[19:00:12] <jhutz> But the present proposal is for how to do v5.3 using FAST. The slides appear to capture the essence of it.
[19:00:14] <raeburn☺> Yes, FAST is documented, but AFAIK not some of the other stuff Sam's getting into today.
[19:01:06] <Simon Josefsson> right, ok. i'm aware of the fast draft, but some of this seems to go beyond that
[19:02:18] <nico> basically
[19:02:29] <nico> this is FAST + I18N aspects of rfc1510ter
[19:02:38] <nico> FAST provides:
[19:02:49] <tlyu> most of the new stuff is conceptual and not yet worked into specs yet.
[19:02:51] <nico> - a way to negotiate I18N and other enhancements
[19:03:31] <nico> - tunelling (integ and even conf prot of things that are currently unauthenticated plaintext)
[19:06:04] <mrex> which names will be/become visible above GSS-API? how will an application know which target name to supply ?
[19:06:55] <nico> the negotiation of new vs. old is, effectively, the same as in rfc1510ter: PA-DATA is used in the KDC protocols, the type of Ticket and hints in KDC-REP are used to for negotiation between clients and target servers
[19:07:21] --- kasumigaura has joined
[19:08:19] <mrex> what about i18n Domain names and hostbased service names?
[19:08:42] <mrex> is the gssapi mech going to do the punycode?
[19:09:11] <nico> mrex: effectively -- that was something we concluded quite a while back
[19:09:27] <nico> mrex: that consensus could be revisited
[19:09:41] <nico> Tom, Sam, Larry and I are not proposing to do that
[19:09:47] --- onakayu has joined
[19:10:22] <nico> mrex: again, this proposal doesn't change anything from rfc1510ter writ large
[19:10:33] <Simon Josefsson> going with IDNA for this causes kerberos to be stuck at Unicode 3.2 since that is where IDNA is today. FYI, Unicode is up to 5.0 now...
[19:10:36] <nico> er, not anything related to I18N anyways
[19:10:54] <nico> simon: for things that are domainname slots, yes
[19:10:57] <mrex> an interoperability matrix might be helpful, listing which gss-api calls ("legacy" and utf8-aware) and client software (old, mixed, new) would need which kind of (preprocessed) input
[19:11:09] <jhutz> can people hear tom?
[19:11:12] <nico> simon: but since those things are stuck with 3.2 because of IDNA already...
[19:11:34] <nico> mrex: well, yes, but we're not actually changing anything w.r.t. GSS here
[19:11:42] <nico> things that used to work should continue to
[19:11:53] <nico> things that didn't work should continue not to work
[19:12:07] <Simon Josefsson> nico: the approach in the idna community is to break backwards compatibility in the next idna version. that would cause problems in this context...
[19:12:11] <nico> if you feed only Latin-1 to GSS_Import_name() then things will work
[19:12:52] <mrex> nico: I understand, but you're adding the feature to support non-ascii, and it will be interesting to know how and under which circumstances this feature will be available to the application and how it must be used in the various cases
[19:13:11] <nico> if you feed non-ASCII, non-Latin-1 to GSS_Import_name(), then if your implementation of GSS passes that through to the mech unchanged and the mech interprets the string in the current locale, then things will work, just as they used to (though they weren't supposed to)
[19:13:47] <mrex> nico: we know that the existing implementation are entirely locale-agnostic, NOT current-locale
[19:14:11] <nico> mrex: when using gss__import_name_utf8() then all UTF-8 will work just as well as if using raw krb5 interfaces directly
[19:14:16] <hartmans@jis.mit.edu/owl> The IDNA community is maintaining certain kinds of backward compatibility. We're having an i18n discussion of security implications of stringprep and other changes Thursday in saag. Let's not do that here
[19:14:25] <nico> mrex: no!
[19:14:27] <mrex> certainly MIT Kerberos has in the past never converted from current locale to some canonical network representation
[19:14:32] --- onakayu has left
[19:14:34] <nico> well, OK
[19:14:40] <nico> they are locale aware
[19:14:50] <nico> they do NOT enforce Latin-1 (except yours)
[19:14:58] <nico> because they are just-use-8
[19:15:55] <nico> this proposal does its best to preserve behaviour of old implementations that used non-ASCII and non-UTF-8 (just-use-8)
[19:16:07] <nico> but such things were always able to break
[19:16:18] <nico> alright Jeff
[19:16:22] <nico> :)
[19:16:33] --- rlbob has joined
[19:28:26] <jhutz> Any clarifying questions on this proposal?
[19:29:54] <mrex> for mutual authentication, the service name must be interpreted
[19:31:11] <mrex> well, Microsoft decided to make use of user2user in order to save replay cache on the server side
[19:37:18] --- ShoichiSakane has joined
[19:38:18] <Simon Josefsson> do people want to solve the non-ascii problem _now_? if so, there seems to be possible to come up with a simpler proposal that only solves that problem. i don't think FAST will be back-ported to old versions of kerberos implementations. but minor tweaks to accomodate utf-8 service names may be back-ported.
[19:39:07] <nico> simon: any proposal to solve the I18N issues requires a method to negotiate
[19:39:17] <nico> that method must start with PA-DATA
[19:39:31] <nico> and we must solve the I18N issues (it's part of our charter)
[19:40:01] <nico> now
[19:40:19] <jhutz> We've been looking at i18n for some time, and the reason that we haven't done it yet, and didn't do it in 4120, is because no one believes it can be done with a few minor tweaks.
[19:40:23] <nico> given that FAST adds a PA-DATA, it's easier to add just one than to add two, so we can bundle I18N in
[19:40:45] <nico> what jhutz said
[19:41:05] <jhutz> actually, it's not part of our charter yet (the IESG is discussion whether to roll back its charter approval for process reasons), but it will be.
[19:41:14] <nico> there is no way to do minor tweeaks for I18N and get something good as a result
[19:45:08] <Simon Josefsson> isn't the problem with i18n to handle the deployed non-confirming i18n approaches? if we ignore those, and let them solve there own mess, and simply replace all ascii-fields with utf-8-fields, that seems to be a simple fix. to solve the negotiation problem, let's bump the pvno
[19:46:38] <nico> simon: do you want us to discuss that in the room?
[19:46:52] <Simon Josefsson> nico: no need
[19:47:53] --- lzhu has left
[19:50:32] <mrex> the question isn't really whether we should also allow utf8. It's about on which encoding are we going to settle after noticing that there are already implementations out there sending all different kind of things. Some do just-send-8, one particular widespread implementation sends utf-8
[19:51:45] --- miyahiro has joined
[19:51:47] <nico> mrex: if you mean the implementation that I think you mean do note that it's just-don't-normalize-utf-8
[19:52:04] <nico> and it doesn't do normalization-insensitive string comparison
[19:52:28] <nico> (and even if it did, string inputs to string2key() really have to be normalized)
[19:53:05] <nico> (particularly when there are/may be OSes that have different preferences for pre-composition or not in their input methods)
[19:53:29] <Simon Josefsson> generally, i'd like to see the details in how negotiation would work in sam's proposal. preferrably in draft form.
[19:53:45] <nico> (and beyond normalization there's unassigned codepoints to think about -- all stringprep kinds of things)
[19:54:29] <nico> simon: it's the same as in rfc1510ter, replacing the rfc1510ter PA-DATA negotiation elements with FAST's PA-DATA
[19:54:45] <jhutz> negotation of new vs old messages, or i18n specifically/
[19:54:54] <Simon Josefsson> nico: i was thinking about the ticket encoding
[19:55:00] <nico> löve mentions that this proposal doesn't add typed-holes
[19:55:24] <nico> simon: yes, but the outer form of Ticket changes anyways
[19:55:29] <nico> in both cases
[19:56:54] <Simon Josefsson> nico: right, but the details how they change seems important. the rfc1510ter approach seems future-proof, this one seems unsure
[19:57:34] <nico> that's Löve's point
[20:03:13] <Simon Josefsson> regarding extensibility: we don't know today which typed-holes will be critical in the future
[20:03:33] <nico> simon: it turns out that having new PDUs for everything as in rfc1510ter is not going to get it implemented
[20:04:02] --- lzhu has joined
[20:04:21] <nico> I think the question being asked is "have you heard enough to make up your mind?"
[20:05:11] <nico> (personally: yes)
[20:05:13] <Simon Josefsson> i think i understand the rfc1510ter proposal, which seems complex but future-save, but i don't understand this proposal enough. my initial reaction is that 1510ter seems cleaner.
[20:07:18] <nico> simon: as an erstwhile proponent of rfc1510ter, I'd agree, except that
[20:07:31] <nico> we'll want a tunnel scheme anyways
[20:07:43] <nico> and noone signed up to implement rfc1510ter
[20:09:35] --- lzhu has left
[20:10:09] <Simon Josefsson> another alternative is to specify a new pa-data tunnel for each new critical feature we need (i18n, ...)
[20:11:02] <nico> simon: so separate FASt from I18N? but what does that get us?
[20:11:28] <Simon Josefsson> nico: simplicity? modularity? if someone doesn't want i18n, they don't have to implement that particular pa-data
[20:11:32] <nico> the way in which this proposal is better than rfc1510ter is in the complexity of the impact on PDUs
[20:11:51] <nico> simon: see my next message
[20:12:57] <nico> what's simplifying about FAST is not which PA-DATA is used or how many
[20:13:11] <Simon Josefsson> nico: an i18n-specific solution could be simpler than both 1510ter or fast
[20:13:14] <nico> the simplifying thing is that we no longer have new versions of all PDUs
[20:13:30] <nico> instead we modify existing ones in minor ways, as if by a diff patch
[20:13:40] <nico> simon: I don't think so
[20:14:13] <nico> simon: the complexity with I18N is not in how rfc1510ter was written or how FAST was written
[20:14:22] <nico> it has to do with the complexity of the problem
[20:14:34] <Simon Josefsson> nico: perhaps only in names. the goal of FAST doesn't seem to solve i18n. if we pull out what's needed for i18n from fast, perhaps it will be simpler
[20:15:14] <tlyu> simon, we are proposing to nail the i18n solution to FAST
[20:15:22] <nico> any simpler solution would of the form "just start using UTF8String tagged UTF-8 and to hell with old software"
[20:15:26] <Simon Josefsson> nico: right, the i18n problem is complicated. it deserves a separate document, not tacked onto either fast or 1501ter
[20:15:45] <nico> simon: actually, I think we just decided that we'll have separate documents
[20:15:55] <nico> the issue isn't separate docs or not
[20:16:04] <nico> or even tied to FAST or some other PA-DATA
[20:16:16] <nico> the issue is: new PDUs or deltas to existing PDUs
[20:16:28] <nico> that's the real issue with rfc1510ter
[20:19:18] --- lzhu has joined
[20:21:41] --- =JeffH has joined
[20:21:59] <Simon Josefsson> tom's (?) proposal to do simple new pdu's seems to be inline with my wish to find a simpler i18n solution
[20:23:58] <nico> simon: simple new PDUs is akin to patching the existing ones
[20:24:22] <nico> changing things like moving Ticket into the KDCEncPart is a significant change
[20:24:43] <nico> (though it'd be a very good one, assuming we don't do any tunelling)
[20:25:17] <tlyu> part of the reason 1510ter was taking so long was people turning up with objections to each of my attempts to produce PDUs they would find acceptable.
[20:27:07] <Simon Josefsson> what is lacking may be justification behind each change. if we make the minimal set of pdu changes required for i18n, then it would be easy to dismiss objections to the new pdus
[20:27:28] <nico> tom: indeed
[20:28:13] <nico> simon: if we do new PDUs with new app tags then I definitely want to fix all the other problems besides I18N
[20:28:48] <Simon Josefsson> nico: maybe we shouldn't do that now, unless you have a very critical problem?
[20:29:02] <nico> if we do new PDUs where context describes what's different, then I still feel very strongly about typed-holes, but less so and less so about other problems in general
[20:29:21] <nico> simon: adding new PDUs with new tags sucks
[20:30:07] <Simon Josefsson> true
[20:31:05] <nico> if we do it we do it _once_
[20:31:14] <nico> so we do everything at once
[20:31:19] <nico> and we never finish
[20:33:59] <Simon Josefsson> and adding new pa-data's without changing pdu's won't be sufficient?
[20:35:47] <tlyu> nailing as many capability negotiations together as possible is probably more robust
[20:36:18] <nico> simon: no, the PDUs must change
[20:37:08] <nico> tom: I agree, but I don't think that's the big deal
[20:37:32] <nico> I think the big deal is what violence we apply to the PDUs
[20:38:12] --- lha has joined
[20:38:23] <Simon Josefsson> my focus is to solve i18n
[20:38:31] <Simon Josefsson> i don't care strongly about fast vs 1510ter
[20:38:56] <Simon Josefsson> but i prefer simpler solutions
[20:39:29] <nico> simon: do you care about backwards interop?
[20:39:30] <Simon Josefsson> i don't care about backwards interop
[20:39:38] <nico> (that's my question)
[20:39:48] <tlyu> there's simple and then there's simple. FAST+i18n is in many ways just as complicated as 1510ter, just parts of it are hidden differently.
[20:39:48] <Simon Josefsson> (with non-standards conforming implementations!)
[20:40:16] <Simon Josefsson> (and anything non-ascii is not conforming)
[20:43:44] <Simon Josefsson> i didn't get the question, sorry. (lagging here)
[20:43:55] --- miyahiro has left
[20:44:15] <mrex> from what I understood about the discussion was that FAST is interesting because of protecting the authentication exchange, and this is what will be driving the FAST implementations primarily . Solving i18n was just proposed as an added value to FAST
[20:44:26] <jhutz> The question is, are people OK with taking the FAST approach to Kerberos V spec 3? (yes/no/don't-care/need-more-info)
[20:45:19] <semery@jis.mit.edu> yes
[20:45:32] <hartmans@jis.mit.edu/owl> Well I want i18n too. I actually think some of my customers care more about i18n than fast. I in many ways view i18n as a way to get funding for fast. The issue is that 1510ter is so complicated for me to get i18n that I can't justify it.
[20:45:34] <Simon Josefsson> i'm not sure what to vote. i think we need to know what we must solve in v3 and evaluate the simplest way to do so. i'm probably 'don't-care' or need-more-info
[20:45:54] <nico> mrex: yes, I see two questions: a) do we want FAST because it's a tunnel (but this applies to StartTLS as well), b) which violent option to we want to apply to the PDUs in order to get backwards interoperable I18N (sub-question: do we want backwards interoperable I18N)
[20:46:24] <Simon Josefsson> i want to solve i18n. i don't see either 1510ter or fast as compelling solutions for i18n.
[20:46:36] <jhutz> "do we want FAST" is not really part of the question. The question is do we want the FAST-based approach to solving krb5.3
[20:46:39] --- mrex has left: Replaced by new connection
[20:46:56] <jhutz> I think the charter proposal captures what we need out of 5.3
[20:46:58] <nico> jhutz: I don't agree
[20:47:28] --- mrex has joined
[20:47:31] <tlyu> if really needed i could try to write up a recap I-D about what our 5.3 goals were as i recall them.
[20:48:52] <nico> I think the "FAST-based" approach to I18N is not related to FAST -- it's "deltas to the PDUs negotiated via some PA-DATA" vs "big choice arms to PDUs negotiated by PA-DATA" (rfc1510ter) vs. something else
[20:49:32] <nico> ^deltas^small deltas^
[20:51:11] <nico> ok, meeting over :)
[20:51:16] <Simon Josefsson> tlyu: i think what's relevant here is what the WG is chartered to do. it would be nice to solve all problems, but we'll never finish that
[20:52:03] <nico> simon: we have to address I18N, we should address security problems too (off-line dict. attacks, unauthenticated plaintext, ...)
[20:52:14] <nico> ^should^have to^ (really)
[20:52:20] <nico> charter or no
[20:52:40] <nico> together or separately is not a big deal
[20:52:53] <Simon Josefsson> just-send-utf8 and starttls solves both and is simple (for me, although perhaps not for others).
[20:53:10] <nico> simon: only if we have consensus to just send utf-8
[20:53:20] --- shpark has left
[20:53:25] <nico> that is, to not have backwards interop for non-ASCII
[20:54:18] <nico> we've never had consensus to not have that, and we've long had consensus to have that -- we could revisit it
[20:54:38] --- raeburn☺ has left: Computer went to sleep
[20:55:01] --- tlyu has left
[20:55:06] --- kasumigaura has left
[20:55:24] --- nico has left
[20:59:14] --- mrex has left
[20:59:29] --- lha has left
[21:06:36] --- Simon Josefsson has left
[21:09:26] --- semery@jis.mit.edu has left: Disconnected
[21:10:40] --- rlbob has left
[21:10:46] --- ietf-meeting has left
[21:17:27] --- jhutz has left
[21:17:39] --- stefans has left
[21:22:55] --- ShoichiSakane has left
[21:45:16] --- lzhu has left