Re: [radext] Secure COA

[Alan DeKok <[e-mail]>]

  To back up a bit, most of the forgery problem can be avoided by noting that the Operator-NAS-Identifier is itself a unique key.  If the visited realm creates many values for the attribute, then guessing correct values is hard, and forgery is trivially detectable.

  i.e. if each user session has a different Operator-NAS-Identifier, then a home server can forge a CoA packet, but it will get detected by the visited realm as a forgery.  The proxies need to do nothing.

  The visited realm could simply track user sessions in a database (as they mostly do now), and create unique Operator-NAS-Identifiers for each user.  When receiving a CoA request, look up the identifier in a DB, and get the IP of the NAS from there.  Or, the visited realm could be stateless, and encrypt the real NAS IP address with a combination of a secret local key, and the destination realm.  This makes a unique (and secret) identifier for each realm, and for each NAS in the visited realm.

  Remember, all of these packets are sent within a trusted network.  The systems aren’t open to the wider internet, and there isn’t a requirement to protect against DoS attacks from every single IP on the planet.

  I view the forgery problem as something which is best dealt with by non-technical means.  *Detecting* forgery is a technical requirement.  But *preventing* forgery isn’t necessarily a requirement.

  i.e. it’s OK for the visited realm to detect a forged request, ignore it, and escalate the problem to an administrator.  The intermediate proxies don’t need to detect or prevent the forgery.  That’s a hard problem to solve.

On Mar 24, 2015, at 4:59 AM, Sam Hartman <[e-mail]> wrote:
re: crypto keys

> It's much less obvious to me that this is untenible.
> We definitely have key distribution mechanisms that seem up to the task.
> This is especially true in deployments where the original access request
> travels through  the same operators as  the COA packet travels in
> reverse.
> In that case, operators can add/transform their own state, and need only
> manage keys within  their own domain.

  If we do want the proxies to get involved, we could use per-proxy encryption keys.

  Each proxy has it’s own secret key, K_p.  The proxy uses the key to encrypt the Operator-NAS-Identifier when proxying auth / acct packets to a home server.  It uses the same key to decrypt the Operator-NAS-Identifier when proxying CoA / Disconnect packets to the visited realm.  Forged packets from home servers get decrypted to nonsense, and the visited realm will reject the CoA packet.

  The reason this works is that no one but the visited realm can interpret Operator-NAS-Identifier.  Therefore, it’s safe to transform the value in a “conservative” or reversible way.

re: User-Name verification.
> This seems fairly weak to me.

  It’s not perfect, but it’s not wrong.  It’s a good idea to do, in any case.

> I'd be much more comfortable with a solution that took routing and
> session state into account.

  I agree.

  In the end, I think the solutions to this are pretty simple.  CoA proxies can protect themselves by doing reverse realm lookups on User-Name.  Visited realms can prevent forgery by using unique Operator-NAS-Identifiers within a large space.

  Alan DeKok.