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

["Bhatia, Manav (Manav)" <[e-mail]>]

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