I reviewed this document (draft-ietf-kitten-sasl-openid-06) as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Overall comment: the document contains a number of typos, and odd English constructions. These problems detract from its readability, and need to be addressed. This document describes how to map OpenID to GSS-API and SASL. OpenID is a protocol used to enable single sign-on (SSO) in a three party (client, server, id provider) scheme. SASL is an IETF standard used to "modularize" authentication (and other security mechanisms) so that new mechanisms can easily be added, as needed. GSS-API is an IETF framework intended to enable use of various authentication mechanisms via a uniform interface. Thus there is overlap between SASL and GSS-API. This document defines a "pure" SASL mechanism but it also offers a GSS-API G2 interface as well. The document says that it attempts to reuse as much of the OpenID mechanism as possible, and notes that it targets browser environments. The proposal preserves the OpenID provider interface, but requires "enhancements" (a euphemism for changes) to both the client and relying party (e.g., server). The document says that use of TLS is a MUST, for protection of OpenID transactions. Consistent with this requirement, the document says that "the client MUST successfully validate the server certificate" but then includes an ambiguous phrase "or similar integrity protected and authenticated channels." The two cites provided here are to the current PKIX base standard (RFC 5280) and to the recent standard on how to use ID info extracted from a certificate in the TLS context (RFC 6125). Thus the cites provide no hints about what the latter phrase really means. Although the introduction says "This specification is appropriate for use when a browser is available." Section 2 is titled "Applicability for non-HTTP Use Cases" a surprising start to the non-intro portion of the document! In examining the processing steps described in Section 2, I was confused by step 4, on page 6. The text says: 4. The Relying Party and the OP optionally establish an association -- a shared secret established using Diffie-Hellman Key Exchange. The OP uses an association to sign subsequent messages and the Relying Party to verify those messages; this removes the need for subsequent direct requests to verify the signature after each authentication request/response. A Diffie-Hellman exchange yields a shared secret value that typically is used to encrypt traffic, using a symmetric algorithm. But, the text says that the association created using Diffie-Hellman is used to "sign subsequent messages." I don't see how this occurs. Perhaps the authors meant to say that traffic sent via this connection will be integrity protected (not signed), but there is no mention here of the integrity mechanism that would be employed with the shared secret from the Diffie-Hellman exchange. Also, this step is cited as optional. If the option is not elected, what are the security implications for the remaining steps (5-11) of the protocol? This text needs to be modified to address these problems and questions. The diagram that describes these protocol steps (and which has no label) is a good way to augment the text description of the 11 steps. However, the diagram includes tags "gt" and "lt" that do not appear in legends anywhere in this document. Section 2.1 is very brief, and a bit confusing. It discusses the potential need for a relying party to place a nonce or ID into URIs. The text gives only generic examples of how to do this, suggesting that there is no need to define a standard representation. If this is true, the text should be expanded a bit to make clear why this is true. At the end of Section 2.2, (page 9) the document says "A transaction id, MUST be included by the RP by appending it to the return_to URL." This text in 2.2 and the text in 2.1 seem to contradict one another. Section 2.2 uses the acronym "IPC" which appears nowhere else, and is not defined. The phrasing in the second paragraph is very odd in several places. I suggest enlisting the help of a native English speaker to improve the text here. At the end of 2.2 (page 9) the wording is confusing, i.e., "OpenID is also meant to be used in serial within the web." Also, there is no specification for the transaction id that is a MUST at the end of 2.2. An explanation is needed here, i.e., why is a transaction id required, but there is no need for a spec for this id. In 3.1, the document says "The GS2 header carries the optional authorization identity." It is not clear if this implies that the header MUST carry the auth identity, even though it is optional in the more general case, or if carriage of this identity is a MAY. Subsequent text does not clarify this ambiguity, e.g., "The "gs2-authzid" carries the optional authorization identity." In 3.2, the document clarifies that the format of the transaction ID is not mandated. However, the admonition "but SHOULD be large enough to be resistant to being guessed or attacked." is not very helpful. Guidance ought to be included here. The opening paragraph for section 4 is too long and needs to be reworded. In Section 5, the term "OpenID Consumer" is used for the first time. It is not defined anywhere in the document. Is "OpenID Consumer" the relying party? Since the example here does not entail an association between the OP and the OpenID Consumer is it a suitably representative example? The Secruity Considerations Section (#6) addresses security topics only in the context of OpenID when used with SASL and GSS-API. I think this is appropriate, and a reference to an OpenID-specific security considerations is OK. But, the cite provided is not to an IETF document, and thus I do not consider it adequate. Section 6.1 is very fluffy in its discussion of what is needed to ensure that the mapping between an OpenID and an authorization ID is appropriate/secure. Also, the term "server" is as used here, which may be ambiguous. I assume the relying party is the server in question, right? The security issue highlighted in 6.2 is worthy of the discussion, but, again, the advice is a bit fluffy. Saying that an implementation should "carefully analyze URLs received" is not especially helpful. The RECOMMENDATION to restrict the URL to http or https is the only concrete guidance. I find the discussion in Section 7 to not be very useful. It provides a vague suggestion about the utility of a SASL client signaling the beginning of a sensitive transaction, to trigger "increased scrutiny." Since this document describes how to use SASL (and GSS-API) with OpenID in a fashion that preserves the current OpenID interface, a vague suggestion about how that interface might be improved seems out of place.