RRC and sign_only

[Jeffrey Hutzelman]

--On Wednesday, December 17, 2008 08:39:44 AM -0800 Love Hörnquist 
Åstrand <lha at kth.se> wrote:

>
> 17 dec 2008 kl. 07:47 skrev Greg Hudson:
>
>> 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 beg to differ.


>> Put another way, it makes sense to have different semantics
>> depending on
>> which API an application uses *if* the different API usages are for
>> different network protocols.



I have to agree with Love here.   Essentially what you're saying is that if 
you use this API, it might not interoperate, because it cannot successfully 
decode anything that an RFC4121 implementation might send.  Further, you 
can't predict whether it will fail without violating the abstraction and 
peering into the token to see what the RRC is.  I suppose you could 
guarantee it won't break by only using the API with new applications that 
are specified such that only certain RRC values are permitted, but that 
would require that _every_ implementation of such an application use some 
non-standard interface to inform its GSS-API implementation of the 
restriction.  There is no standard way to do this because the RRC is that 
the discretion of the sending RFC4121 implementation, not of the 
application, which is supposed to be using a mechanism-agnostic interface.


Sam says...

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

There is no guarantee of this.  Perhaps it will never be produced by your 
implementation of RFC4121, or Microsoft's, but that's not the same thing. 
RFC4121 does not specify how a sender determines what RRC to use; it only 
gives some hints about a use case involving more efficient implementation 
of a particular use of a particular nonstandard API.

And, Luke says...

> BTW, I've tested the GSS IOV code in mskrb-integ against W2K8 with
> LDAP and RPC (both rc4-hmac and AES).

This smells of cargo-cult programming ("well, I tried foo, and it worked 
for me, so it must be right"), and I know you're better than that.  Having 
a few tests work is not a substitute for correctly implementing the 
protocol.


The interface in question is not part of the GSS-API, so failing to support 
arbitrary RRC values does not mean it will be noncompliant.  It will 
probably even interoperate with the current major implementations.  But it 
won't be guaranteed to interoperate with everything, and if/when this gets 
standardized, I don't expect to see a special case like "if the mechanism 
happens to be RFC4121, and this interface is used, then the sender MUST 
have used an RRC value we think is convenient".

-- Jeff