[ xmpp.txt - Tue Mar 18 15:53:03 2003 - 56th IETF - /mtr ] WG: XMPP Chairs: Lisa Dusseault Pete Resnick Monday, March 17th, 2003 19:30-21:00 US/Pacific Minutes by: Marshall T. Rose Lisa: Agenda 1930 - Agenda-bashing, find note-taker 1940 - draft-ietf-xmpp-core: P. Saint-Andre Overview - changes since last meeting SASL / TLS Internationalization Error handling How 'core' meets IMPP requirements 2010 - draft-ietf-xmpp-im: P. Saint-Andre Overview - changes since last meeting Rosters & subscriptions Communications blocking How 'im' meets IMPP requirements 2040 - draft-ietf-xmpp-*prep: J. Hildebrand 2050 - draft-ietf-xmpp-e2e: J. Hildebrand 2110 - draft-hildebrand-xmpp-sdpng: J. Hildebrand 2130 - Break for drinks! Peter: XMPP Delta (Core and IM 05) XMPP Core: Security - Channel encryption via TLS during stream negotation client-to-server, server-to-server, usual TLS rules minimum to implement: TLS_RSA_WITH_3DES_EDE_CBC_SHA - Authentication via SASL client-to-server, server-to-server, usual SASL rules minimum to implement is DIGEST-MD5 Eric: If you're going to use TLS for peer-to-peer, you need to explain what parts of the certificate you examine. Eric: If TLS negotiation has failed, things are typically hosed because TLS implementations will probably read more than you want.(beyond just the TLS error.) Peter: Right, we'll fix those. Joe: Let's talk about dialback. Looks like we should yank it from the spec and define it in an informational document describing historic usage. [ scribe's summary ... at this point, many people spoke many times about s2s security, TLS, SASL, and dialback. the two perspectives are probably best summarized as: 1. dialback doesn't address any actual threat model, but TLS/SASL provides real value when properly provisioned (e.g., a mutually-trusted CA, bilateral passwords, etc.) 2. some operators may not want to do this provisioning in order to make s2s work. in that case, dialback provides protection against a trivial attack with no cost of provisioning of course, these positions aren't necessarily contradictory, e.g., xmpp could require that products implement TLS/SASL, but allow operators don't have to fully provision their use. ] ACTION: Discuss and resolve on the mailing list. XMPP Core: Internationalization - clarified unicode usage and character encodings - added stringprep profiles as new I-Ds - optional xml:lang attribute on child elements that may contain natural language CDATA Martin: The lack of negotiation may be a problem, other protocols allow negotiation. Lisa: This isn't a stated requirement. Pete: No concensus to add it. XMPP Core: Error Handling - New extensible syntax superseding DATA error messages for streams - Classes for address, format, redirect, and server - Better than the old HTTP-style error codes for stanzas - Classes for access, address, app, format, recipient, and server [ scribe's summary ... at this point, there was a long discussion about the need for working groups being able to assign URNs in their documents. ] ACTION: The ADs will consult with Michael Mealling. XMPP IM: Delta - Specified roster/subscription interaction - Updated error handling to track XMPP core - Modified privacy list protocol to address 2779 requirements regarding communications blocking. No discussion. XMPP IM: Open Issues - There are a couple of things in 2779's requirements that need some clarification (5.1.3 & 5.1.4) Dale: Are temporary subscriptions supported? Lisa: There isn't a requirement for timing out a subscription. Joe: But I can show you how to do it with the existing specs. Derek: 5.1.3 says that the protocol must support un-authenticated subscription requests (emphasis on un-authenticated request). Derek: i *believe* that 5.1.4 can be satisifed by MIC rather than ACK, but further investigation is required. Joe: Stringprep, e2e-encryption, and TINS Stringprep Profiles - the only place where strings are compared are JIDs - user: nodeprep (case insensitive, no "@", etc.) - host: IDNA (case insensitive, DNS restrictions) - resource: resourceprep (case sensitive) Sam: Besides JIDs, SASL adds additional string operations, both internally and when mapping to JIDs Patrik: What's the relationship to the localpart of email addresses Pete: email localparts aren't case-insensitive. E2E-encryption - Adding support for replay-protection - Lots of open issues to deal with - This is all preliminary [ scribe's summary ... at this point, there was considerable discussion about inadequacies in the preliminary approach, not all of which were consistent, e.g., should XMLDSIG be used, or the CPIM format... ] ACTION: Discuss and refine on the mailing list. TINS: Not a WG item - TINS = SDPng over XMPP - TINS = Transport for Initiating and Negotiating Sessions - SDPng = SDP written using XML - Perhaps good for including in an SDPng appendix? No discussion. Lisa/Pete: Adjourn. #######