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]>]

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