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

From: Stephen Kent <[email-masked]>
Date: Tue, 1 Nov 2011 08:46:08 -0400

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.

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 01 Nov 2011 15:19:45 +0100

Stephen,

Thanks for your review.  I'm addressing some issues, leaving the rest
for Eliot and others.

Stephen Kent <[email-masked]> writes:

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

Isn't all that specified by the OpenID protocol?

> 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

The situation is a bit more complicated than a simple MUST/MAY, but I
believe everything is clear from the base SASL specification:

https://tools.ietf.org/html/rfc4422#section-3.4.1

Authorization identities are always optional, but mechanisms are
required to be able to transfer them if they are used by the
application.

If you review the base SASL specification about authorization identity,
do you still believe this document needs to say more than it does here?

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

Yes.  "Consumer" is OpenID 1.x terminology, this should be fixed.

/Simon

---

From: Stephen Kent <[email-masked]>
Date: Tue, 1 Nov 2011 11:43:41 -0400

At 3:19 PM +0100 11/1/11, Simon Josefsson wrote:
>...

I don't see any IETF document that describes OpenID, and that 
concerns me. But, using Google, and searching for "openID protocol 
signature" I did find an
intro doc at wiki.openid.net. That doc refers to "openid.sig = *base 
64 encoded HMAC signature*"  This is NOT a signature. It is a MAC (a 
message authentication code).  So, please change the text to note the 
actual secruity mechanism being employed here.

>required to be able to transfer them if they are used by the

That statement, if placed in the I-D, will resolve my question.

>do you still believe this document needs to say more than it does here?

yes, I believe it should include the concise, clear statement that 
you made :-).

>Yes.  "Consumer" is OpenID 1.x terminology, this should be fixed.

Thanks,

Steve

---

From: Eliot Lear <[email-masked]>
Date: Tue, 01 Nov 2011 17:03:57 +0100

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

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

> 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

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

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

> return_to URL." This text in 2.2 and the text in 2.1 seem to

Thanks.  We'll combine.  The intent is that there must be a nonce, but
the format can be internal to the RP.
> 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.
>
> 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.

> more general case, or if carriage of this identity is a MAY.

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

> between the OP and the OpenID Consumer is it a suitably representative
> example?
>

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

> 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 RECOMMENDATION to restrict the URL to http or https is the only

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.

> 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

---

From: Stephen Kent <[email-masked]>
Date: Wed, 2 Nov 2011 09:49:23 -0400

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

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

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

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

>That depends on the state of capabilities of computing devices, I

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.

>document.  I don't want to simply copy their spec (that would be rude,

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

>   "user" for purposes of authorization.)

The content is good, but a single sentence that runs on for > 5 lines ...

>   browsers to communicate with OPs that    they are not themselves

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

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 02 Nov 2011 13:01:32 -0400

> That statement, if placed in the I-D, will resolve my question.

That statement is not within the scope of this I-D.  It's descriptive of
SASL itself, and is covered in the SASL base specification.  In
particular, the requirement is one placed on SASL mechanisms (such as
the present I-D) by SASL itself.

Implementation of this mechanism requires an understanding of the SASL
base specification (unless one is implementing only the underlying
GSS-API mechanism, in which case the section in question is not relevant
at all).  I don't think it's necessary for every SASL mechanism to
restate all of SASL's requirements, and it may even be harmful, because
then it looks like you're trying to say something _different_ than what
the SASL spec says.

Do you really think any SASL implementor is going to be confused by
this?

---

From: Stephen Kent <[email-masked]>
Date: Thu, 3 Nov 2011 04:16:57 -0400

>Do you really think any SASL implementor is going to be confused by

Since I am not a SASL implementer, I can't say. I can say that as a 
reasonably intelligent reader, I found the wording ambiguous. I am 
opposed to ambiguous statement in RFCs :-).

Steve

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 03 Nov 2011 12:20:25 +0100

> opposed to ambiguous statement in RFCs :-).

Perhaps the solution is to remove text rather than add more?

I share Jeff's concern that adding text here may give the impression
that it implies something different than what a SASL implementer would
expect to follow automatically from the normative references.

How about removing this sentence:

       The GS2 header carries the optional authorization identity.

from section 3.1 and modify the other paragraph in section 3.1 into

   The syntax and semantics of the "gs2-header" is specified in
   [RFC5801], and we use it here with the following limitations.  The
   "gs2-nonstd-flag" MUST NOT be present.  The "gs2-cb- flag" MUST be
   "n" because channel binding is not supported by this mechanism.

The document is already clear elsewhere that the mechanism supports the
concept of authorization identities (see beginning of section 3).

The syntax and semantics of the authorization identity field is covered
normatively by the base SASL specification and the GS2 document.

/Simon

---

From: Eliot Lear <[email-masked]>
Date: Thu, 03 Nov 2011 14:54:52 +0100

Steve,

On 11/2/11 2:49 PM, Stephen Kent wrote:
> client, RPs, and OPs) right, and so change to them are potentially the
> hardest.

I appreciate this point, but (a) any mechanism addition to SASL requires
a client change and (b) with little exception the client in this case is
just passing a funny URL to a browser component (one way or another) and
then awaits an answer from the server.  Therefore, I would accept your
advise to improve the clarity of the above, as follows:

>         Minimal changes    are required to    non-web    applications,
> as most
>         of the transaction occurs through a normal web browser.     Hence,
>         this specification is only appropriate for use when such a
> browser is
>         available.

> support of the common, browser use case?

Think about the example: a mail client (like Thunderbird) gets a new
SASL mechanism that takes as a single configuration parameter a URL. 
That is passed to the browser (modulo some checks we discussed) and
we're off to the races.  And so the web infrastructure is leveraged by
non-web components.

> to note that what they refer to as a signature, is actually a MAC.

Ok.  How about this:

          <t>The Relying Party and the OP optionally establish an
            association -- a shared secret established using
            Diffie-Hellman Key Exchange.  This shared secret is    used
            to generate    and check what the OpenID specification    calls
            a signature    but what others might call a message
            authentication code    (MAC). This process is
            described in Section 8 of <xref target="OpenID" />.</t>

> can probably pick a suitable entropy target.

In this case, since we're requiring TLS, the only function here is to
disambiguate transactions.  The attack surface, therefore is fairly
small.  I would suggest 2^16 is probably a bit small, even so (UNIX pids
are bigger than that), but that 2^32 would be more than sufficient. 
Again, this is really an internal matter for the RP.

[...]
> analysis." Would you be comfortable making the list of "authorized URI
> bases" be a RECOMMENDATION, or is it just an example?

As a recommendation, yes.

---

From: Stephen Kent <[email-masked]>
Date: Thu, 3 Nov 2011 11:44:35 -0400

>        The GS2 header carries the optional authorization identity.

OK with me.

>normatively by the base SASL specification and the GS2 document.

OK.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Thu, 3 Nov 2011 11:55:56 -0400

At 2:54 PM +0100 11/3/11, Eliot Lear wrote:
>....

Your text makes it sound as though both terms have equal pedigree.
They don't. See the Interent Security Glossary (RFC 4949).

>  > The security community likes bit-length measures of entropy. In this
>...
>

Since, as you noted, this is within a TLS session, I'd agree with 2**16.

OK.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 03 Nov 2011 12:05:57 -0400

>normatively by the base SASL specification and the GS2 document.

So, the reason not to do that is that we've decided (I think) that people doing pure-SASL implementations of dual-stack mechanisms such as this one should normally not have to read the GS2 spec, since it specifies a layer of abstraction that they don't care about.

OTOH, I think we can be clearer.  The new text you just proposed is a good start; we can refer to GS2 for clarification without annoying pure-SASL implementers too much.  But instead of removing references to "optional authorization identity", what if we change them to "SASL authorization identity, when used" ?  This makes it clear that an autzid might _not_ be used, provides a hint where to look to learn more about autzids (SASL), and avoids the impression that we are applying the word OPTIONAL to anything.