chatroom log from IETF#59 session

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

For your info, here is the chatroom log from our IETF#59 session.
Thanks to Alexey for being our scribe!

[3:42 PM]<alexeymelnikov> Kurt: is talking about WG status
[3:42 PM]<alexeymelnikov> WG had two documents last time
[3:43 PM]<alexeymelnikov> Protocol is pretty much done, authmech still remains
[3:43 PM]<alexeymelnikov> Kurt is hoping to finish this quickly (optimist ;-))
[3:43 PM]<alexeymelnikov> Next step is to Last Call "protocol" document
[3:44 PM]<alexeymelnikov> Kurt is expecting approx. 2 revs on authmethods before it is done
[3:44 PM]<alexeymelnikov> Next time Kurt is hope to talk about new work (if any)
[3:45 PM]<alexeymelnikov> Jim is doing update on "protocol"
[3:46 PM]<alexeymelnikov> Issues:
[3:47 PM]<alexeymelnikov> 1) attributesd with no equality rules (Jim hopes that "model" can be updated)
[3:47 PM]<alexeymelnikov> 2) Server-enforced control criticality (more list discussion might be required)
[3:49 PM]<alexeymelnikov> should the server return error if criticality flag doesn't much criticality as described for a control extension
[3:50 PM]<alexeymelnikov> Kurt: are there any server implementors that implement as Howard interpreted the spec. Nobody come up with any example
[3:51 PM]<ludomp> It's Hallvard (Furuseth) not Howard
[3:51 PM]<alexeymelnikov> [disclaimer: non english speaker can't spell names ;-)]
[3:52 PM]<ludomp> [disclaimer: non english corrector neither, but it was for correctness of minutes/scribings]
[3:53 PM]<alexeymelnikov> Ted is asking what kind of problems would arise if a server enforces check for criticality matching a control spec
[3:54 PM]<alexeymelnikov> Kurt is saying that criticality may change over time, the server should not care
[3:55 PM]<alexeymelnikov> Hallvard wants the following: if the client doesn't set criticality flag properly, the server should return an error. This will cause the client author to fix it.
[3:55 PM]<alexeymelnikov> Kurt: this might be useful for debuging
[3:56 PM]<alexeymelnikov> Ted suggests to ask Hallvard to come up with a useful usecase (not for debugging)
[3:57 PM]<alexeymelnikov> Action: ask Halvard about a non diagnostic use case
[3:58 PM]<alexeymelnikov> Kurt: the document was listing 3 options: control criticality must be TRUE, must be FALSE, up to the client. But the reality is that this might depend on other conditions
[4:00 PM]<alexeymelnikov> Jim: most servers check if control is enabled and if it is not, but required, the server should return an error. Those server has to be updated
[4:00 PM]<alexeymelnikov> [I might be misinterpreted the last statement]
[4:01 PM]<alexeymelnikov> 3) AuthMech reconciliation. Some text was duplicated in both authmech and protocol, should be removed from authmech
[4:01 PM]<alexeymelnikov> Jim: we are ready for WG last call
[4:02 PM]<ludomp> most servers check if they know the control, if they don't they check criticality to decide to abort the operation or ignore the control. If Hallvard recommendations are added, some servers implementation will have to be updated.
[4:03 PM]<alexeymelnikov> [yes, that is better]
[4:04 PM]<alexeymelnikov> Kurt: Last Call mid March?
[4:04 PM]<alexeymelnikov> Jim is presenting on AuthMech
[4:04 PM]<alexeymelnikov> revision 10
[4:05 PM]<alexeymelnikov> 1) Password Considerations (clarify that password considerations only apply to cleartext passwords in bind)
[4:06 PM]<alexeymelnikov> 2) Move mandatory-to-implement features into its own section
[4:06 PM]<alexeymelnikov> 3) Start TLS sequencing warning
[4:07 PM]<alexeymelnikov> (all oustanding operations must be completed)
[4:07 PM]<alexeymelnikov> some clients are used to send StartTLS before receiving responses to outstanding operations
[4:08 PM]<alexeymelnikov> ... because most servers will finish all operations or cancel them
[4:08 PM]<alexeymelnikov> Kurt: client is supposed to wait, but some don't
[4:09 PM]<alexeymelnikov> Kurt: some servers process one operation at a time, so badly behaved clients can get away with there behaviour
[4:10 PM]<alexeymelnikov> Personal Comment: I think some Microsoft client has the broken behaviour
[4:10 PM]<alexeymelnikov> 4) Anonymous authentication (need to remove the statement whcih says it's typical to bind anonymously when no updating)
[4:11 PM]<alexeymelnikov> 5) Rules for SASL layers
[4:12 PM]<alexeymelnikov> The current wording is limited (suggestion: allow both clients and server to enforce which mechanisms to use)
[4:13 PM]<alexeymelnikov> Kurt: think in terms of security levels, not SASL mechs
[4:13 PM]<alexeymelnikov> because a stronger mech can be used in weaker mode (i.e. GSSAPI with no security layer)
[4:13 PM]<alexeymelnikov> 6) Sample Deployment Secnarios
[4:14 PM]<alexeymelnikov> People not sure what is this all about
[4:14 PM]<alexeymelnikov> Roger is working on the document this week
[4:16 PM]<alexeymelnikov> Kurt: the authmech needs review rant
[4:17 PM]<alexeymelnikov> Kurt: other outstanding issues
[4:18 PM]<alexeymelnikov> Kurt: quality matching rules (current proposal doesn't agree with X501)
[4:19 PM]<alexeymelnikov> Kurt will cut and paste from X501
[4:19 PM]<alexeymelnikov> Kurt: some minor changes will be done if X500 don't agree with LDAP
[4:20 PM]<ludomp> [This is about the absence of equality matching rule and how to treat such attributes]
[4:21 PM]<alexeymelnikov> Kurt: the document has passed the Last Call, so the changes should be reviewed on the mailing list
[4:22 PM]<alexeymelnikov> Ted: break protocols in chinks for IESG review, so that a Discuss comment on one document doesn't hold 8 other
[4:23 PM]<alexeymelnikov> Kurt: document have interdependencies, so it actually might be reasonable for 1 doc to delay all
[4:24 PM]<alexeymelnikov> Kurt: minor clarifications in URL, filter, etc
[4:25 PM]<alexeymelnikov> Syntaxes is done, the question is whether all standard track matching rules should be absorbed by the document
[4:27 PM]<ludomp> the additional matching rules published to standard tracks just been published in rfc 3698
[4:27 PM]<alexeymelnikov> Kurt is asking if there is any opposition to the plan
[4:28 PM]<alexeymelnikov> Jim: must identify which matching rules are elective
[4:28 PM]<alexeymelnikov> Kurt: les
[4:29 PM]<alexeymelnikov> s/les/let's talk about milestones/
[4:30 PM]<alexeymelnikov> Kurt: "protocol" - march, "authmech" - april, may for the rest
[4:31 PM]<alexeymelnikov> Interop report is 6 month after approval as RFC
[4:32 PM]<alexeymelnikov> the meeting is closed
[4:33 PM]<ludomp> Thanks Alexey... Great scribing !
[4:33 PM]<rlbob> yes, thanks Alexey
p