Re: [secdir] review of draft-ietf-kitten-sasl-openid-06

[Eliot Lear <[e-mail]>]

Steve,

Hannes, can you send me the specific authorization identity text you
agreed to?  That wasn't clear.


Thanks for the review.  For my part...


On 11/1/11 1:46 PM, Stephen Kent wrote:
> 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 design consideration is that identity providers (OPs) and browsers
should remain untouched, since these are likely the components that are
most difficult to change.  The mechanism itself requires few changes to
clients.  The heavy lifting is done by the SASL server or RP.

> 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." 
RFC 6091 is really what I have in mind (perhaps other authors had other
things in mind) but I take your point.  Will remove the phrase.
> 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!

The point is to make use of the web-based identity infrastructure for
other application protocols.  I've reworded this as follows:

Applicability for application protocols other than HTTP

>
> 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.

This is informational text that references standard OpenID 2.0.  Please
see Section 8 of the referenced specification.  If you prefer we can
simply shorten this text to indicate something along the lines of "...
establish an association for use as described in Section 8 of..."

>
> 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.

I don't see those tags in my copy of the draft...


>
> 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.

Thanks.  We'll combine.  The intent is that there must be a nonce, but
the format can be internal to the RP.
>
>
> Section 2.2 uses the acronym "IPC" which appears nowhere else, and is
> not defined. 
Expanded.

> 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.
Ok, this is cleaned up.  The key point: when you are 100% within a
browser, you can stick transaction ids in a browser cookie that gets
retrieved by the RP.  With an application in the middle you lose that
ability.

>
> 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.

That depends on the state of capabilities of computing devices, I
suppose.  Got guidance?

>
> 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.

Steve, the base specification we're working from is a non-IETF
document.  I don't want to simply copy their spec (that would be rude,
to say the least).

>
> 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?
I've tried to make the text less woolly:


  As specified in <xref target="RFC4422" />, the server is
  responsible for binding credentials to a specific authorization
  identity.  It is therefore necessary that either
  a registration process takes place in advance that binds specific
  OpenIDs to specific authorization identities, or that only specific
  trusted OpenID Providers be allowed, where a mapping is predefined.
  (for example where it is known that "https://example.com/user" maps to
  "user" for purposes of authorization.)

>
> 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.

How's this:

  To mitigate this attack, implementations should carefully analyze
  URLs received, eliminating any that would in some way be
  privileged.  One mitigation would be for RPs to have a list of authorized
  URI bases. OPs SHOULD only redirect to RPs with the same domain
  component of the base URI.  RPs MUST NOT automatically retry on failed
  attempts.  A log of those sites that fail SHOULD be kept, and
  limitations on queries from clients SHOULD be imposed, just as with
  any other authentication attempt.  Applications should not invoke
  browsers to communicate with OPs that    they are not themselves
  configured with.

>
> 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.

Ok, you're the Umpteenth person to say this, so we're going to pull the
text.  The idea here was that VAST number of applications DO make use of
web-based authentication, and there probably should be some study into
signaling between applications on a device.  How that happens is
ABSOLUTELY beyond the scope of this document, but I didn't want to lose
the thought entirely.

Again, thanks for taking the time to do the review.

Eliot