Subject: AAP security

From: Steve Hanna <[email-masked]>
Date: Fri, 15 Oct 1999 09:36:47 -0400

I have been working on the next version of the AAP spec and I'd like to
discuss the topic of how AAP messages should be authenticated.
Authentication for AAP messages is important. Otherwise, denial of
service can be easily accomplished by announcing a tiny address set (or
blocking everyone's claims, etc.).

The current AAP draft calls for each message to be signed with a digital
signature. This is problematic, since verifying a digital signature is
very expensive (about 160 ms for a DSA verify on my Sun SPARC Ultra 1).
Asking each MAAS and Prefix Coordinator (MASC router) to verify a
digital signature on each AAP packet received is clearly problematic.
And only checking signatures on some packets is also problematic. This
just helps detect a denial of service, not prevent one.

I suggest that we authenticate messages with a keyed hash (MAC) and
discard packets that fail the authentication test. Verifying an
MD5-based MAC takes only .21 ms on my Ultra 1. The primary disadvantage
of a MAC is that it uses a shared key. If all MAAS's and Prefix
Coordinators share the key (as I would suggest), it would not be
possible to securely determine which MAAS or Prefix Coordinator sent a
particular message. But that's consistent with the general peer-to-peer
nature of AAP.

Also, the current AAP draft uses a special-purpose packet format.
There's really no need for this. The IPsec format (AH or ESP) should
work perfectly fine for AAP. We're just doing normal authentication.
IPsec doesn't include support for automatic key agreement within
multicast groups yet, so people will need to enter the shared key
manually on the MAAS's and Prefix Coordinators. But this is a one-time
task.

The Secure Multicast Research Group (SMuG) is working on group key
management techniques that will remove the need for manual keying.
They're also working on fast multicast authentication techniques that
would allow us to efficiently and securely determine which MAAS or
Prefix Coordinator sent a message. Also, if we switch to using IPsec for
authentication, we may be able to take advantage of future hardware
assist for IPsec.

So I suggest that we switch over to using IPsec for our packet
authentication. For now, we will suggest that people use MACs with a
manually configured shared key. At some later date, they may be able to
switch over to some of the SMuG techniques.

The primary benefits as I see them are:

* Simpler AAP protocol (easier to agree on, implement, etc.)
* Less chance of security holes
* Leverage current and future IPsec work
* Better performance (~500x better)
* Invalid packets are discarded in kernel (or hardware) for even better
  performance

The primary disadvantage is:

* IPsec support required for secure deployment

Comments, please?

-Steve

---

From: Dave Thaler <[email-masked]>
Date: Mon, 18 Oct 1999 15:28:57 -0700 (PDT)

> switch over to some of the SMuG techniques.

My personal opinions...

I am okay with this.  However, you may want to think about the effect
of multiple scopes.  I would suggest saying "a manually configured 
shared key per scope".  This way, MAAS's in a small scope (which may
be configured by the same person) can use a key for that scope
which doesn't have to be known by admins in a slightly wider area.

I would also ask that the wording be general enough not to preclude
the use of public keys with IPsec if/when smug develops practical
solutions.

-Dave

---

From: Steve Hanna <[email-masked]>
Date: Mon, 18 Oct 1999 16:54:47 -0400

Dave Thaler wrote:
> > manually configured shared key. At some later date, they may be able
> > to switch over to some of the SMuG techniques.
> 
> My personal opinions...
> 

Yes. I will mention this explicitly.

> the use of public keys with IPsec if/when smug develops practical

Definitely.

Thanks for the comments,

Steve