Last Call Review of draft-ietf-kitten-sasl-openid-

Request Review of draft-ietf-kitten-sasl-openid
Requested rev. no specific revision (document currently at 08)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2011-11-22
Requested 2011-10-14
Authors Eliot Lear, Hannes Tschofenig, Henry Mauldin, Simon Josefsson
Draft last updated 2011-11-08
Completed reviews Genart Telechat review of -?? by Brian Carpenter
Genart Telechat review of -?? by Brian Carpenter
Secdir Last Call review of -?? by Stephen Kent
Assignment Reviewer Stephen Kent 
State Completed
Review review-ietf-kitten-sasl-openid-secdir-lc-kent-2011-11-08
Review completed: 2011-11-08


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.