RRC and sign_only
lukeh at padl.com
Thu Dec 18 02:42:34 EST 2008
> 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
> decode anything that an RFC4121 implementation might send. Further,
> can't predict whether it will fail without violating the abstraction
> 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
> are specified such that only certain RRC values are permitted, but
> would require that _every_ implementation of such an application use
> non-standard interface to inform its GSS-API implementation of the
> restriction. There is no standard way to do this because the RRC is
> the discretion of the sending RFC4121 implementation, not of the
> application, which is supposed to be using a mechanism-agnostic
I would argue if RFC4121 is the goal, one should be using STREAM or
>> 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
> for me, so it must be right"), and I know you're better than that.
> a few tests work is not a substitute for correctly implementing the
Heh. Well, as usual it's often quicker to fix than it is to try to win
an argument :-) I agree it's always good to implement things with a
view towards standardization, etc, but don't forget that the whole
DCE_STYLE thing is very Windows-specific and my primary goal was
interoperability with that.
My reservation (apart from the usual amount of laziness) regarding
supporting arbitrary RRC in the multiple buffer case is: if an
application is managing explicit buffers, why would the sending GSS
implementation change the meaning of the buffers by rotating contents
of one into another? To me it only makes sense to use RRC to support
the trailer-less buffer configuration.
If one is using gss_wrap(), then yes, I agree we should accept
arbitrary RRC because that's what the RFC says.
More information about the krbdev