On Thu, 20 Feb 2014, Simon Wilkinson wrote:
On 19 Feb 2014, at 21:23, Benjamin Kaduk <[email protected]> wrote:
Does anyone have an opinion that might sway us to one side or the other?
I've just realised that this opens a whole can of worms, relating to two
different definitions of the PRF+ function. There is a PRF+ defined in
RFC4402, which uses a network byte order 4-octet value as the counter.
Then there is the PRF+ defined in RFC6113 which uses a single octet
value as the counter.
Well, sure, there are a handful of PRF+ functions floating around. As
long as we specify which ones to use where (and implement it correctly :)
), things should interoperate fine. Having to code up or call into a
library for different ones is perhaps a bit annoying, but seems doable.
As specified, rxgk uses both of these PRF+s - the 4402 one for key
derivation, and the 6113 one for key combination. However, in the YFS
implementation, we are actually using a 6113 PRF+ for both derivation
and combination.
It seems like this should not be catastrophic, given that YFS is using
custom rx service numbers and such. The choice of which PRF+ to use can
be tied to the (service, RPC number) pair; since both sides need to know
about the service and RPC number in order for the call to succeed, a new
behavior can be implemented seamlessly, and new YFS deployments that know
about the afs3-stds protocol and the old/current YFS protocol will
interoperate with both. All for the cost of some more code and
conditionals, which is effort, yes, but seems doable.
I'll also note that MIT krb5 provides a krb5_c_fx_cf2_simple() API and
Heimdal a krb5_crypto_fx_cf2() API that perform the KRB-FX-CF2 operation
directly, abstracting away the RFC 6113 PRF+ from us.
-Ben
_______________________________________________
AFS3-standardization mailing list
[email protected]
http://lists.openafs.org/mailman/listinfo/afs3-standardization
