RRC and sign_only

[Tom Yu]

Love Hörnquist Åstrand <lha at kth.se> writes:

>>
>>>> On Wed, 2008-12-17 at 08:13 +0100, Stefan (metze) Metzmacher
>>>> wrote:
>>>>> I think it don't make sense to have different semantics
>>>>> depending on which api an application uses. And we should
>>>>> allow every per RFC valid request with any api.
>>>> If you are using the IOV API in non-stream mode, you are not
>>>> really using the RFC wire format; you're using an extension.
>>>> It's reasonable for this extension to have restrictions not
>>>> imposed by the RFC.
>>
>> I have to agree with Greg.
>> If you would e explain why you disagree, it would be easier to see  
>> where we're coming from.
>>
>> Consider for example a buffer layout with 10 bytes of data, a trailer,
>> the header and then the remainder of data.  Even without sign_only,
>> that layout will never be produced by RFC 4121.
>
> Greg say that the api use must be limited to STREAM use, everything  
> else is of bounds, I don't agree with that.an

Are you saying that you would like an application to be able to use
gss_unwrap_iov in non-stream mode to decode messages known to
originate from a RFC 4121 implementation that produces unusual RRC
values, i.e. ones that do not match the submitted buffer layout?

What is the use case for this?  Does SSPI produce such encodings?

Also, it seems to me that it is easiest to implement the "mismatched
RRC" case in a less-efficient way, i.e. with additional copies that
would otherwise not be needed if the RRC did match.

I see several possibilities:

1. Reject RRC mismatches in non-stream mode.  Make no plans to change
   this behavior.

2. Reject RRC mismatches in non-stream mode.  Consider it a
   low-priority bug until a need is demonstrated.

3. Accept RRC mismatches in non-stream mode, possibly with performance
   penalties due to copying.

Unless there are strong objections, I say that we do (2) unless Luke
says that implementing (3) is fairly cheap and does not present
substantial testing challenges.

As gss_unwrap_iov is not (yet) standardized, we could argue that its
interface requires the same buffer layout on sender and receiver when
not running in stream mode.  It would not necessarily accept all valid
RFC 4121 encodings and is not fully compatible with RFC 4121 wrap
tokens unless operating in stream mode.

On the other hand, maybe there are valid use cases for a caller to
want to unwrap arbitrary RFC 4121 wrap tokens using the non-stream
mode of gss_unwrap_iov.  Please describe such use cases if you know
about them.