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

From: Sam Hartman <[email-masked]>
Date: Mon, 15 Aug 2011 13:25:58 -0400

Hi. I've reviewed the draft-ietf-ospf-auth-trailer-ospfv3-05 for
consistency with draft-ietf-karp-ospf-analysis.  KARP is chartered to
figure out what improvements we need in routing protocol
authenticationq. While draft-ietf-karp-ospf-analysis has not been
approved by the WG, I think it's fairly close to our current thinking on
what needs to be done to OSPF authentication.  I believe we should
either be consistent with that thinking or  if during the discussion we
discover that what we're doing in KARP is incorrect decide to update the
KARP document.

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 draft-ietf-karp-crypto-tables. At the top of page 231 of RFC
2328, OSPF v2 security associations are defined with four lifetimes:
KeyStartGenerate, KeyStartAccept, KeyStopGenerate and
KeyStopAccept. Similarly, RFC 4301 defines a lifetime value for the SAs
used by OSPFv3; in that case, whether an SA is an outbound or inbound SA
controls whether it can be used for reception, generation or both at the
current time. In the KARP crypto tables, lifetimes related to when
packets can be sent are included: SAs are deleted from the crypto table
to prevent reception. However the V3 auth trailer draft leaves this all
up to implementation defined behavior.
draft-ietf-karp-ospf-analysis indicates that we're going to remind
people of the existing OSPF requirements for keylifetimes because they
are necessary for key rollover.

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.

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.

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Wed, 24 Aug 2011 20:09:40 +0530

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

---

From: Acee Lindem <[email-masked]>
Date: Wed, 24 Aug 2011 10:44:00 -0400

Hi Manav, 

> 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 c…

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 

> _______________________________________________
> OSPF mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ospf

---

From: Acee Lindem <[email-masked]>
Date: Wed, 24 Aug 2011 10:46:31 -0400

> 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

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Wed, 24 Aug 2011 20:21:08 +0530

Hi Acee,

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

We would still need an IANA registry of Apads unless youre thinking of using the IP protocol type as the first octet of the Apad. If it's the latter, then OSPFv3 and OSPFv2 would share the same Apad, which would defeat the purpose of the whole exercise.

This would also not work for multiple protocols that ride over UDP and TCP. BFD and RIP would end up using the same Apad as their IP protocol is the same. 

We thus need a unique Apad that each standard can define if we want to protect ourselves from the attack that Sam describes.

Cheers, Manav

---

From: Acee Lindem <[email-masked]>
Date: Wed, 24 Aug 2011 12:05:42 -0400

Hi Manav,

On Aug 24, 2011, at 10:51 AM, Bhatia, Manav (Manav) wrote:

> We would still need an IANA registry of Apads unless youre thinking of using the IP protocol type as the first octet of the Apad.

That's exactly what I'm proposing. 

> If it's the latter, then OSPFv3 and OSPFv2 would share the same Apad, which would defeat the purpose of the whole exercise.

Are you forgetting about the version as the first nibble of the header? 

> This would also not work for multiple protocols that ride over UDP and TCP. BFD and RIP would end up using the same Apad as their IP protocol is the same. 

UDP/TCP protocols would need a scheme that includes their well-know port - perhaps, the second octet of the first instance of Apad ;^). 

Thanks,
Acee

---

From: Acee Lindem <[email-masked]>
Date: Wed, 24 Aug 2011 12:10:22 -0400

> Are you forgetting about the version as the first nibble of the header? 

Meant the first byte of course - first nibble is for IPv4 vs IPv6 ;^) 

> <smime.p7s>_______________________________________________
> OSPF mailing list
> [email-masked]