| Sigh. C'mon, folks, there is no problem. View the algorithm as simply part of the shared secret. All authentication is done between consenting adults and there has to be out-of-band and a priori agreement on the parameters or the authentication fails. Nobody is going to be guessing the algorithm in use on a particular session any more than they would be guessing the secret. And if you want to switch algorithms (which is essentially just switching secrets) the key ID mechanism is present. At the end of the day it doesn't matter if the value of 2 or 3 or 42 is used; if there's a mismatch on the the algorithm ID, the algorithm, or the key, the authentication will fail, and if it all matches, it will work. For that matter, I don't think that even the existing algorithm ID is necessary, since the entire thing has to be agreed upon a priori anyhow. For what it's worth, type 2 fits the bill just fine, defined the way that it is. If one box does only MD5 and the other box only does SHA, they cannot talk. If they share an algorithm, it is up to the user to configure the two boxes compatibly, like a thousand other parameters. While having a separate code point for SHA would have marginal debugging utility ("wrong algorithm, dummy!") it's no harder to make sure that this matches on both sides than it is to make sure the shared secret matches. --Dave On Aug 23, 2006, at 3:06 AM, sujay wrote:
|
_______________________________________________ OSPF mailing list [email protected] https://www1.ietf.org/mailman/listinfo/ospf
