Subject: [AVT] Comments on Section 9.1 of draft-ietf-avt-ports-for-ucast-mcast-rtp-09

From: "Glen Zorn" <[email-masked]>
Date: Sat, 18 Dec 2010 11:56:17 +0700

The second paragraph says:

   Multicast is deployed on managed networks - not the Internet.  These
   managed networks will choose to enable network ingress filtering
   [RFC2827] or not.  If ingress filtering is enabled on a network, an
   attacker attacker cannot spoof a victim's IP address to use a Token
   to initiate an attack against a victim.  However, if ingress
   filtering is not enabled on a network, an attacker could obtain a
   Token and spoof the victim's address, causing traffic to flood the
   victim.  On such a network, the server can reduce the time period for
   such an attack by expiring a Token in a short period of time.  In the
   extreme case, the server can expire the Token in such a short period
   of time, such that the client will have to acquire a new Token
   immediately before using it in a Token Verification Request message.

It seems like you're suggesting that the remedy for a DoS attack against the
client(s) is a DoS attack against the server (perpetrated by the clients);
that is, unless the requirement for server provisioning in networks that
aren't ingress filtering enabled is to be able to handle all these requests.
That's OK, but in this case at least you seem to have lost any
efficiency-related argument vis-à-vis the cookie approach.

The third paragraph says:

   HMAC-SHA1 provides a level of security that is widely regarded as
   being more than sufficient for providing message authentication.  It
   is believed that the economic cost of breaking that algorithm is
   significantly higher than the cost of more direct approaches to
   violating system security, e.g., theft, bribery, wiretapping, and
   other forms of malfeasance.  HMAC-SHA1 is secure against all known
   cryptanalytic attacks that use computational resources that are
   currently economically feasible.

This is all motherhood & apple pie ;-), but the use of HMAC-SHA1 isn't even
RECOMMENDED, just given as an example of what might be done.  I would
suggest that the crypto requirements be tightened up, possibly with
HMAC-SHA1 being explicitly specified as the minimum strength algorithm to be
used (unless it's really OK to use, e.g., MD2 ;-).

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Sat, 18 Dec 2010 11:07:30 -0800

> -----Original Message-----
> From: Glen Zorn [mailto:[email-masked]]
> Sent: Friday, December 17, 2010 11:56 PM
> To: Ali C. Begen (abegen)
> Cc: [email-masked]
> Subject: Comments on Section 9.1 of draft-ietf-avt-ports-for-ucast-mcast-rtp-09
> 

True but we are not expecting a deployment model without ingress filtering.
 
> used (unless it's really OK to use, e.g., MD2 ;-).

Should we? I am not sure as there could be some deployments where easier algorithms could be used without any issues. Note that the attacker does not know what the server does. The algorithm is only known by the server. So, it could be even reversing the bits for all we care.

Does anybody have a strong opinion on this?

-acbegen

---

From: "Glen Zorn" <[email-masked]>
Date: Sun, 19 Dec 2010 09:18:39 +0700

> True but we are not expecting a deployment model without ingress

OK, but shouldn't this limitation be at least mentioned in the Security
Considerations section (along with a recommendation that this protocol not
be deployed in networks in which ingress filtering has not been enabled)?

> Should we? I am not sure as there could be some deployments where easier
> algorithms could be used without any issues. Note that the attacker does
> not know what the server does. The algorithm is only known by the
> server. So, it could be even reversing the bits for all we care.
> 

I don't care, but at that point your security story is pretty much reduced
to "security through obscurity", which means that "motherhood & apple pie"
should be deleted & probably replaced with something to the effect that "the
security of this protocol is based on the assumption that no attacker knows
the configuration of the server".

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Sun, 19 Dec 2010 09:18:37 -0800

> Sent: Saturday, December 18, 2010 9:19 PM
> Subject: RE: Comments on Section 9.1 of draft-ietf-avt-ports-for-ucast-mcast-rtp-09
> 

If ingress filtering is off, there are really more serious problems you could experience than the ones that tokens will result in. So, such a scenario is not our worry IMO. And the text says that if filtering is off, there are risks and you might end up using very short-term tokens (which has its own drawbacks).
 
> the configuration of the server".

I think the text about hmac-sha1 should remain. At the end, while we are not mandating or recommending in 2119 language, we could expect many implementations will do that. I don’t think this text hurts. In addition, I would expect secdir will like to see it as well.

-acbegen

---

From: "Glen Zorn" <[email-masked]>
Date: Mon, 20 Dec 2010 09:35:32 +0700

Ali C. Begen (abegen) [mailto://[email-masked]] writes:

> If ingress filtering is off, there are really more serious problems you
> could experience than the ones that tokens will result in. So, such a
> scenario is not our worry IMO. And the text says that if filtering is
> off, there are risks and you might end up using very short-term tokens
> (which has its own drawbacks).

Those drawbacks need to be discussed in detail.

> > > >    being more than sufficient for providing message
> authentication.
> > > It
> > > > This is all motherhood & apple pie ;-), but the use of HMAC-SHA1
> isn't
> > > even
> > > > HMAC-SHA1 being explicitly specified as the minimum strength
> algorithm
> > > to be
> I think the text about hmac-sha1 should remain. At the end, while we are
> not mandating or recommending in 2119 language, we could expect many
> implementations will do that. 

Why?

> I don't think this text hurts. In
> addition, I would expect secdir will like to see it as well.

Speaking as an (occasional) secdir reviewer, I don't want or need to see a
bunch of "feel good fluff" in a Security Considerations section; I want to
see a forthright analysis of the threats against the protocol, along with
mitigating tactics (if any).  

...