Hi, [clipped] > > Based on this review I have a few recommendations for the > OSPF v3 authentication trailers document. > > 1) The v3 authentication trailer takes a step back in the > ability to rekey security associations both from OSPF v2, > from IPsec for OSPF v3 and from [ ..] > > I believe that draft-ietf-ospf-auth-trailer-ospfv3-05 needs > to be revised to require implementation behavior at least as > flexible as draft-ietf-karp-crypto-tables. That is, > associated with each security association is a time for when > sending packets can start with a given SA and for when it > must stop. Infinity and 0 should of course be supported for > the appropriate times. > > 2) I notice terminology inconsistency between key identifier > and security association identifier. This should probably be > cleaned up, although it's not that big of a deal. http://tools.ietf.org/id/draft-ietf-ospf-auth-trailer-ospfv3-06.txt addresses the first two comments. > > > 3) draft-ietf-ospf-analysis says that we are going to solve > related protocol attacks. That is, we recognize that it's > quite likely that some people will use the same preshared key > both for OSPF authentication and for something else. We need > to mix something into the key or hash or something that is > unlikely to appear in any other use in order to make it > cryptographically unlikely for the resulting OSPF > authentication hash to be a hash useful in some other > protocol or for the hash from some other protocol to be > useful in OSPF. This draft does not do that. One possible > way to solve this would be to prepend a constant in front of > the key in the key preparation step or a constant in front of > every packet that gets hashed. The constant should be the > same for OSPFv3 and not used for any other purpose. We had an offline discussion with Sam and others and we seem to have converged at this text: We change the hex that's repeated in the Apad from 0x878FE1F3 to 0x878FE1F4. This value will be unique for OSPFv3. Other protocols that use this mechanism must use a different value of Apad - you could think of this as "salting" the Apad. OLD TEXT in Sec 4.4: Apad is a value which is the same length as the hash output or message digest. The first 16 octets contain the IPv6 source address followed by the hexadecimal value 0x878FE1F3 repeated (L-16)/4 times. This implies that hash output is always a length of at least 16 octets. NEW TEXT: Apad is a value which is the same length as the hash output or message digest. The first 16 octets contain the IPv6 source address followed by the hexadecimal value 0x878FE1F4 repeated (L-16)/4 times. This implies that hash output is always a length of at least 16 octets. Cheers, Manav _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf