Last Call Review of draft-ietf-kitten-sasl-openid-
review-ietf-kitten-sasl-openid-secdir-lc-kent-2011-11-08-00

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.