Draft: draft-raeburn-krb-rijndael-krb-06.txt Reviewer: Kent Crispin Date: 8 July 2004 I did not find any "showstoppers" in this draft. The security considerations section, however, is curious, and leaves me with the feeling that there is more work that could be done in the area -- but the work is of a more general nature. The underlying point of the discussion is that the mechanisms used to resist dictionary attacks (iteration and a salt, as described in PKCS5) also, in this context, increase the computational load of legitimate authentication. Since the computing power available to the legitimate user (a smartcard, for example) can be very much less than the computing power available to a cracker (who could have a network of dedicated servers working on the problem), the draft recommends that the associated parameters (salt length and iteration count) be site selectable, to allow sites to make tradeoffs in light of their particular security policy and situation. The draft provides some ballpark studies of the computational loads involved, and recommends tweaking the parameters every year to increase the load sufficient to compensate for Moore's law. Overall, this seems unfortunately weak to me. I don't think it realistically addresses how site administrators should or will deal with tweaking the parameters.