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

[Simon Josefsson <[e-mail]>]

Stephen Kent <[e-mail]> writes:

> At 1:01 PM -0400 11/2/11, Jeffrey Hutzelman wrote:
>>On Tue, 2011-11-01 at 11:43 -0400, Stephen Kent wrote:
>>
>>>  > 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.
>>
>>
>>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?
>
> 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 :-).

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