>>We found there was a problem in the localization algorithm First of all, I don’t think the above is a correct statement.
There is no *problem* in the algorithm, but a usage constraint that was clearly stated in the RFC, and is unlikely to manifest in the real world. This constraint could have been addressed by the method you proposed, and the algorithm would have been better, albeit by very little. But unfortunately you weren’t around participating in this discussion in 2002, and now it’s really late (see below). >>but we are not sure whether this issue is worthwhile for us to address, I think it definitely is not worth (nor wise) addressing, by changing the proven and mature standard at this point. Bert Wijnen (my co-author) concurs, as stated in his email to the list: http://www.ietf.org/mail-archive/web/opsawg/current/msg03668.html > The new algorithm that you propose seems to offer very little >improvement. I agree with Tom. It could make sense if we were starting from scratch. But forcing all the vendors to change after 12+ years of deployment (the algorithm was first published in RFC 2264 published in Jan 1998), and for such a meager gain - just does not make sense. >You suggest that after replicating the password, you then add the >password length in the last four octets to bring the length up to 64 >octet. This seems to add very little entropy. Again, I concur with Tom. The number of cases where this modification would help is small to negligible. Thanks! P.S. It could make sense for *new* algorithms/protocols that use similar techniques to slow the attacker down. But for new algorithms that start with no past baggage to carry - probably PBKDF2 or such would be a better choice altogether. P.P.S. Does your proposed code run correctly on Big Endian (such as Motorola) and Little Endian (such as Intel) CPUs? -- Regards, Uri Blumenthal Voice: (781) 981-1638 Cyber Systems and Technology Fax: (781) 981-0186 MIT Lincoln Laboratory 244 Wood Street, Lexington, MA 02420-9185 _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
