The PLAIN Simple Authentication and Security Layer (SASL) Mechanism
Note: This ballot was opened for revision 09 and is now closed.
(Sam Hartman) Yes
(Jari Arkko) No Objection
(Ross Callon) No Objection
(Brian Carpenter) No Objection
Comment (2006-03-29 for -** No value found for 'p.get_dochistory.rev' **)
From Gen-ART review by Eric Gray. A few sentences seem to need clarification. ---- In the second paragraph on page 4, I am having some trouble parsing the text "The SASLprep preparation algorithm is not mandatory to allow, when appropriate, the server to employ other preparation algorithms (including none)." What I think this means is "To allow the server to employ other preparation algorithms (when appropriate, including none), the SASLprep preparation algorithm is not mandatory." Alternatively, a construction identical in meaning would be "The SASLprep preparation algorithm is not mandatory. This allows, when appropriate, the server to employ other preparation algorithms (including none)." Is this interpretation correct? Another potential (mis?) interpretation of this statement is "It is not mandatory, in the SASLprep preparation algorithm, to allow the server to employ other preparation algorithms (when appropriate, including none)." The latter interpretation is a stretch as well as not being self-consistent, but it is a possible interpretation... ============================================================ I am not certain what the first two paragraphs on page 6 are trying to say. "It is noted that the DerivateAuthzid and Authorize functions (whether implemented as one function or two, whether designed in a manner in which these functions or the mechanism implementation can be reused elsewhere) require knowledge and understanding of mechanism and the application-level protocol specification and/or implementation details to implement "It is also noted that the Authorize function outcome is clearly dependent on details of the local authorization model and policy. Both functions may be dependent on other factors as well." After struggling with it for a while, I think it means - 'Implementation of portions of the functionality shown in the above pseudo-code (e.g. - DerivateAuthzid and Authorize) will require understanding of specific mechanisms, application level protocols and implementation details. Also, the functionality associated, in the pseudo code example, with the "Authorize" function depends on local authorization and policy details. Represented functionality may also depend on other factors.' Is this correct? I had trouble with the wording because: 1) I have no idea what value to associate with "noting" these things as opposed to simply saying them. Is there any? 2) I had to look a couple of times to realize that the intent of the parenthesized text in the first paragraph seems to be to avoid giving any sort of "definitive weight" to the example represented by the pseudo code (in other words, I had to read it twice to realize that I never had to read it at all). 3) I had some touble parsing the last two lines of the first paragraph. ============================================================ The following text in section 5 - "The second example shows how the PLAIN mechanism might be used to assume the identity of another user. In this example, the server rejects the request." The first sentence implies success, the second failure. I assume the second is correct. In that case, shouldn't the first sentence refer to an "attempt to assume ..."? There is some shock value in the current wording, because I thought it was getting ready to tell me how to do something I should not be able to do. =========================================================== NITs: ==== Section 1 - 6th paragaph "a strong data security service" as opposed to "an strong ..." Page 4, third paragraph - "unassigned code points are allowed to appear in" as opposed to "... allowed appear in".
(Lisa Dusseault) No Objection
Comment (2006-03-27 for -** No value found for 'p.get_dochistory.rev' **)
The changes from RFC2595 section explicitly notes that CR and LF are now legal as authzid characters. As I understand it, since this document updates RFC2595, an application protocol specification would have to write a new profile to use this, and could then exclude CR and LF characters if those cause any problems in the application layer. Sam and I discussed the possibility of adding this kind of explanation to this document, which I feel would be useful.
(Lars Eggert) No Objection
(Bill Fenner) No Objection
(Ted Hardie) No Objection
(Russ Housley) (was Discuss) No Objection
The Security Considerations say: > > "stringprep" and Unicode [StringPrep] security considerations > also apply, as do [UTF-8] security considerations. > I think it would be better if this were a separate paragraph. Also, it will be easier to read if it was reworded slightly: > > Unicode and "stringprep" [StringPrep] security considerations > also apply, as do [UTF-8] security considerations.