Simple Authentication and Security Layer (SASL)
Note: This ballot was opened for revision 15 and is now closed.
(Sam Hartman) (was Discuss, Yes) Yes
(Brian Carpenter) No Objection
(Margaret Cullen) No Objection
(Bill Fenner) No Objection
(Ted Hardie) No Objection
(Scott Hollenbeck) No Objection
(Russ Housley) No Objection
(David Kessens) No Objection
(Allison Mankin) No Objection
Please respond to Sam's satisfaction as Responsible AD (I don't need to have an answer myself): The IESG may reassign responsibility for a SASL mechanism. The most common case of this will be to enable changes to be made to mechanisms where the author of the registration has died, moved out of contact or is otherwise unable to make changes that are important to the community. Is this an arbitrary grant of reassignment rights to the IESG? Or just of the standards track SASL mechanisms? How well must the unreachability be demonstrated before reassignment? By what means? This is not very crisp, and when it comes time to actually take this action, it will need to be implementable. One thought would be to state that the IESG has discretion to announce that the registrant has been found to be unreachable and therefore the registration is changed.
(Jon Peterson) No Objection
(Mark Townsley) No Objection
(Bert Wijnen) No Objection
sect 2, 2nd bullet seems to be an incomplete sentence? In sect 1.1. I see: 1.1. Document Audiences This document is written to serve several different audiences: - protocol designers using this specification to support authentication in their protocol, - mechanism designers that define new SASL mechanisms, and - implementors of clients or servers for those protocols which support SASL. While the document organization is intended to allow readers to focus on details relevant to their engineering, readers are encouraged to read and understand all aspects of this document. But I must say that I find it difficult to read it as a protocol designer as per your first bullet. ----- My successor Dan Romascanu also looked at this doc, and I agree with his further comments/questions: 1. Clarification question: Section 3.7 Once the security layer is in effect in the protocol data stream, it remains in effect until either a subsequently negotiated security layer is installed, or the underlying transport connection is closed. How is a subsequently negotiated security layer installed? I suppose that one would aim to keep the operational continuity of a protocol in cases of re-keying, as mentioned in section 6.3. If this is supported, how does it happen? Is the SASL exchange repeated, needs the underlying transport connection be torn down? Should multiple successful SASL authentication exchanges be permitted for this purpose? 2. In section 6.1..5 - Should not 'must not' and the second 'should' be in capitals? 3. Section 7.1.1 While this registration procedures do not require expert review, authors of SASL mechanisms are encouraged to seek community review and comment whenever that is feasible. Authors may seek community review by posting a specification of their proposed mechanism as an Internet-Draft. SASL mechanisms intended for widespread use should be standardized through the normal IETF process, when appropriate. I am wondering whether this process is not too loosely formulated. It seems to leave the door open for somebody requiring the registration of a mechanism directly from IANA without going necessarily through a review that checks that requirements defined in Section 5 are met. Maybe a mandatory referring to advice from a group of SASL experts or review on <email@example.com> mailing list or by a Security AD would be useful.