Hi Manav, On Aug 24, 2011, at 10:39 AM, Bhatia, Manav (Manav) wrote:
> 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. Could we simply use the OSPFv3 protocol number, 89, in the Apad, e.g., 0x898FE1F4, (or at least the first instance of Apad). Otherwise, we probably need a registry for IANA Apads. Thanks, Acee > > 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 > _______________________________________________ > OSPF mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ospf
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OSPF mailing list [email protected] https://www.ietf.org/mailman/listinfo/ospf
