IETF 76 - SASL Working Group Minutes ==================================== Location: Hiroshima, Japan - Crowne Plaza ANA Time: 11/11/09 at 10:30-11:30 Local time Chairs: Tom Yu Kurt Zeilenga Acting Chairs: Alexey Melnikov Shawn Emery Scribes: Jim Schaad Peter Saint-Andre Security Area Director: Pasi Eronen Action Items: ============= Co-chairs: Consider a BoF on just normalization issues so that there is a uniform solution for I-Ds/working groups. Co-chairs: CRAM-MD5: Publish CRAM-MD5 I-D as not-recommended. Co-chairs: Ask the list for any interest in pursuing channel-binding. Nico Williams: Post issue with GSS-API to SASL bridge confidentiality protection bitmask issue of using values of 6 or 4. List implementations that use either. Conference Session: =================== Slides for this meeting can be found here: WG Update: http://www.ietf.org/proceedings/09nov/slides/sasl-0.pdf StringPrep/SASLPrep: http://www.ietf.org/proceedings/09nov/slides/sasl-1.pdf WG Update: Alexey: Document Status Page Alexey: 4422bis has expired. Kurt Zeilenga: 4422bis also kind on hold due to SASLprep. That is, not sure what we want the spec to recommend. Alexey: channel-binding-03 has expired. No concensus to pursue this document. Alexey: scram I-D is in the RFC editor's queue. Alexey: gs2 is in IETF LC. To tele-chat on 12/3. Alexey: crammd5-to-historic and digest-to-historic, LC and publish? Question to the list. Alexey: Tried to schedule a BoF for StringPrep/SASLPrep, but not available. Nico Williams: I should mention an interop problem that has come up recently w.r.t. RFC4752; I'll describe during Q&A if there's time, and if anyone cares Slide: Tech discussion New Presentation: StringPrep Overview: Review the solution of SASLprep. This discussion branched to two aspects: Whether we should support agility or use one version. Trade-offs: Using one version may have issues as bugs may occur Using an agile solution is more complex Other issue is where should normalization take place; client or server. Aspects: Server should know the supported types, clients could have orthogonal types If client normalizes then if server normalizes, should be immutable This problem is not indigenous to SASL Kurt: My basic requirement is that SASLprep (and basically for other profiles) is that for Profile(version, string), Profile(3.2, string) == Profile(any, string) for any string. Nico: my comments have been sent to the list Nico: http://en.wikibooks.org/wiki/Unicode/Versions Nico: a useful summary of changes in Unicode versions Jeffrey Huztzelman: what, cuneiform scholars shouldn't be allowed to use cuneiform passwords? :-) Nico: jhutz: passwords on dried clay tablets aren't... good passwords Nico: BTW, stringpreps are per-mechanism Nico: not for all of SASL Nico: what's NFKC stability? Pete Resnick: not discussing specifics of normalizatino form we need. Kurt: I tried to do a version independent SASLprep and stringprep but found that "exceptions" were needed. Which is basically what IDNA found, yes? Pete: question of version independence depends on what we think we need out of it adn whether we think normalization forms might change over time Peter Saint-Andre: if a new version changes the class, it may get normalized differently Nico: I thought NFs were supposed to be _stable_ Pete: if we want something more stable, then we should lock it down and not be version independent Nico: well, no Sam Hartman: one nice thing about IDNAbis is that they described what is special about DNS. For example, search requirements. Sam: perhaps we can do something similar Nico: stringprep is per-SASL _mechanism_ Nico: so we can always consider _new_ stringpreps JHutz: I thought NFs were supposed to be _stable_ So, you could mean one of two things by "stable": (1) NF(NF(x)) == NF(x) for all x (2) NF(x) == NF'(x) provided that x contains no unassigned code points Nico: IMO RFC3454 needs updates to allow for stringpreps that have normalization-insensitivity and NFD, for example Nico: jhutz: (2) Sam: we need to clear on what the actual requirements are John: I think Sam has made the key point Nico: changes to existing stringpreps must be backwards compatible Kurt: Version upgrade or version independence? Sam: interested in requirement for NFKC stability, might want to consider UC's definition, which is that we want stability except when there are more important considerations Kurt: I basically don't mind SASLprep(3.2, string) != SASLprep(newer, string) for some very small set of strings that "don't matter", but for all strings that matter SASLprep(3.2, string) == SASLprep(newer, string). Sam: maybe we break a well-known class of existing solutions but we make things simpler going forward Nico: agrees with Sam's comments about stability John Klensin: example forthcoming... John: sometimes scripts were botched so badly that they had to start over John: you end up with incompabilities despite the stability rules John: better to clean things up now rather than waiting until there are larger numbers of users Nico: granted, if there are passwords using cuneiform characters, and the UC changes normalization for those, hey! you lose! Kurt: of course, "matters or not" is not necessarily easy to determine Sam: I think we might be in violent agreement Pete: can we state what the violent agreement is Sam: that stability is a tradeoff Pete: not violent agreement on the solution, only the problem Alexey: Nico, do you have other requirements? Nico: in my experience, normalizing as late as possible is good Nico: on the client, that happens to be early for hashing passwords Nico: many have optimized for NFC, but in long term we should prefer NFD Nico: not sure what I think of K mappings, not clear what we gain from them Nico: maybe helpful in file names, but not in usernames and passwords John: only argument against normalize as late as possible, someone somewhere in the path might change it before you get to it John: with regard to K conversions, many of the compatibility characters are there so that people can write their names as they expect Nico: that's why I think we don't need them in security technologies Nico: do you have an example of someone getting to it before you do? John: one can pretend that glitches in Unicode don't exist and figure that those will get fixed eventually Sam: what we found in MIT Kerb was that had to normalize late (because of ASN.1 problems) and in fact that turned out to be useful Sam: the server was in a position to know what was expected Sam: there were surprises that some things compared equal, but that was OK Sam: and better position to cope with the bugs Nico: that explains what I was looking for John: vigorously nods his head John: in these contexts, what matters is comparison rather than mapping early to forestall potential problems Nico: we're in violent agreement, RFC 3454 is IDNA-specific in this sense Nico: it would be nice if we could define stringprep profiles that are not IDNA-driven Sam: Although for scram and digest-md5, we do have this backward compat issue Kurt: we need to update stringprep! A key question is version upgrade only or version independent John: thinking in terms of stringprep gets us on the wrong track -- what matters is comparison, not mapping Alexey: maybe we need a BoF in Anaheim to get consensus on whether we want to do this (either update stringprep or take a different path) Sam: we need consensus of people who are using SASL, not just working on SASL Sam: A BoF would be good Kurt: even if we just update SASLprep, version update only or version independent is still a key question. The latter is bear in either case. Kurt: which is a fine question for discussion at a BoF. Peter: nods to Kurt Milestones: Pass for now. Channel-binding: Nico: Not to pursue. CRAMMD5/Digest to historic: Kurt: Last time we tried to move CRAMMD5 to historic we got contention... is that contention resolved. Kurt: We had the document passed WG LC and then found contention and dropped it. John: moving something to historic if it is so widely used is problematic John: perhaps create a short applicability statement for CRAM-MD5 Sam: historic doesn't mean don't use it Pasi: We should spend as little time on this as possible. JHutz: I feel like moving to historic ought to mean it is already not used Jim Schaad: I think that moving to historic should also mean -- you really shouldn't be using this. Kurt: one alternative is to move it to historic without an I-D Alexey: if it's too difficult we might as well drop it Nico: agrees with Sam Open mic: Nico: Interop issue with original GSS-API bridge for SASL (RFC 4752): 2 classes of implementations: 6: confidentiality 4: confidentiality Solution: Servers should accept 6 and 4. Will send e-mail to the list and list implementations. ================ Session Over