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

[Stephen Kent <[e-mail]>]

At 3:19 PM +0100 11/1/11, Simon Josefsson wrote:
>Stephen,
>...
>  >
>>  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?

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.

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

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

>If you review the base SASL specification about authorization identity,
>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 :-).

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

Thanks,

Steve