I'll confess that it took me some time to really understand the challenge protocol that you have introduced and the utility of the nonce and the session IDs that you are carrying. I attribute that to the language used in the draft which i think can be considerably improved. I, as someone else also noted in the list, could not find the Key ID and the cryptographic sequence number associated with each packet in the current draft. This was perhaps overwritten by the nonce and the session details that you have defined. You will have to move this information out somewhere else and bring back these two parameters so that this scheme works. Assuming that this can be done, i must say that this is i believe the first serious attempt at really solving the inter session replay attacks in any protocol that uses manual keying.
Kudos to the authors for that. I hope to see this being presented in Prague. Glen On Fri, Jan 14, 2011 at 6:04 PM, Sam Hartman <[email protected]> wrote: >>>>>> "Michael" == Michael Barnes <[email protected]> writes: > > Michael> Hi Manav, I wanted to address this point separately. > > Michael> On 01/14/2011 12:55 AM, Bhatia, Manav (Manav) wrote: > >>> > Regarding the new format for hello packets, is this format to > >>> be used > only during challenge and response, or for all hello > >>> packets > when this > new form of authentication is enabled? > > >> This has to be used*all* the time. > > Michael> I'm not very excited about a 3x increase in the number of > Michael> bytes per neighbor. (For those who haven't read the draft, > Michael> it changes the Hello packet so that it contains 12 bytes > Michael> for each neighbor over the current 4 bytes per neighbor.) I > Michael> have to wonder if this is really necessary for each and > Michael> every hello packet. I'm certainly not a security expert, > Michael> but it seems to me that once we have verified the > Michael> neighbor's session ID we shouldn't continue to need to > Michael> receive our own session ID and nonce back in every hello > Michael> packet. Did you consider if this can't be optimized? > > We can certainly look at optimizing. However, note that currently we > don't really have a well defined state of challenging. You need to look > at a neighbor's idea of your session ID and nonce whenever the state is > not at least two-way. > So, one of the tricky questions is how does a neighbor know when to > include this information? > > We could have separate authentication challenge packets. However, the > advantage of the current approach is that I think we can get to a point > where we have one or two extra packets total for a cold-start situation, > rather than an extra packet or two per neighbor. I don't know that the > current rules for receiving and sending packets actually achieve this, > but I believe we can get there with some minor changes. > > However, we can definitely think about optimizations. > > I believe the current text does actually say that hellos are sent > immediately if we need to challenge someone, at least if we have not > sent a challenge hello too recently. Take a look at the detailed > description of the section on nonce triggers. > > --Sam > _______________________________________________ > karp mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/karp > _______________________________________________ OSPF mailing list [email protected] https://www.ietf.org/mailman/listinfo/ospf
