Re: [OSPF] [karp] Last Call: <draft-ietf-ospf-auth-trailer-ospfv3-05.txt> (Supporting Authentication Trailer for OSPFv3) to Proposed Standard

[Acee Lindem <[e-mail]>]

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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ospf