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

[Simon Josefsson <[e-mail]>]

Stephen,

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

Stephen Kent <[e-mail]> writes:

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

Isn't all that specified by the OpenID protocol?

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

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