On Aug 24, 2011, at 10:44 AM, Acee Lindem wrote: > > > 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. I meant 0x898FE1F3 as to not change the last 3 octets of the existing HMAC-SHAx Apad. Thanks, Acee > > 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 >> OSPF@xxxxxxxx >> https://www.ietf.org/mailman/listinfo/ospf >
<<attachment: smime.p7s>>
_______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf