RRC and sign_only
jhutz at cmu.edu
Wed Dec 17 19:09:08 EST 2008
--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
>>> 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.
> 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
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".
More information about the krbdev