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

[Stephen Kent <[e-mail]>]

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

That's not the impression one gets from reading the text cited above. 
The text could be changed to emphasize that the client changes are 
very minor, but the clients are still the biggest population (among 
client, RPs, and OPs) right, and so change to them are potentially 
the hardest.

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

But doesn't thus section talk about how to use SASL and OpenID in 
support of the common, browser use case?

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

As noted in my reply to Simon, I did look at the OpenID spec, and 
discovered that it uses the wrong terminology in this context. (I am 
bothered by the fact that we don't have an RFC version of the OpenID 
spec, and that the spec we're citing  contains errors of this sort. 
But, those are issues outside the scope of this review.) I think it 
appropriate to cite the relevant section of the OpenID spec, but also 
to note that what they refer to as a signature, is actually a MAC.

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

That's what I saw when I downloaded the I-D as a text file. But, 
looking at the PDF and the version displayed in my browser, I don't 
see the offending characters either. So, never mind ...

>  > 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 security community likes bit-length measures of entropy. In this case,
the entropy is needed to achieve a high likelihood of uniqueness. it 
is not clear to me, from reading this doc (vs. the full OpenID spec) 
what is the required scope for the uniqueness. If an adversary has an 
unlimited number of attempts in a brief time window (e.g, Kamisky DNS 
attack), then the IETF community no longer believes that 2**16 is a 
big enough space. So, if you can characterize the attack surface, we 
can probably pick a suitable entropy target.

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

In the past we have created RFCs from docs that are products from 
other SDOs or companies, with their permission. I'm not saying that 
this is a requirement, but  I am concerned, especially given the 
error I discovered, and some of the comments in this I-D, e.g., 
"Portions of the authentication stream are only defined in the 
crudest sense."

>  > 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 content is good, but a single sentence that runs on for > 5 lines ...

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

This is better. I'd say that what we can expect is a simple set of 
simple syntactic checks by an implementation, not really "careful 
analysis." Would you be comfortable making the list of "authorized 
URI bases" be a RECOMMENDATION, or is it just an example?

Steve