Subject: RE: [AAA-WG]: Concern about Diameter disconnect and dynamic authorization

From: <[email-masked]>
Date: Fri, 11 Apr 2003 15:39:05 +0300

Bernard,

My assumption was that this kind of functionality would be
driven by the applications, so that may be part of the reason
this was 'forgotten' in the base.

John

> -----Original Message-----
> From: ext Bernard Aboba [mailto:[email-masked]]
> Sent: 06 April, 2003 08:13
> To: [email-masked]
> Subject: [AAA-WG]: Concern about Diameter disconnect and dynamic
> authorization
> 
> 
> We've just been through a bit of a security firedrill with 
> respect to the following draft:
> 
> http://www.drizzle.com/~aboba/IEEE/draft-chiba-radius-dynamic-
authorization-11.txt

While a bunch of the issues found here do *not* afflict Diameter
disconnect and dynamic authorization operations (since Diameter  uses
ordinary Request/Response mechanisms for authorization changes), it seems
to me that other issues *are* relevant.

For example, there is the question of how a NAS or proxy decides whether a
disconnect or dynamic authorization request is appropriate. Authentication
is not enough for this -- we would not want one ISP to be able to
disconnect users from another ISP on a shared use NAS, for example.

It seems to me that to some extent the mechanisms used to identify a
session for these operations are application specific -- and therefore
that the issues need to be addressed in the Diameter Application specs,
rather than Base.

However, in looking at the RAR and STR messages in Diameter, it would
appear that they lack the basic facilities necessary to do a reverse path
check (RPF) as described in the above draft. In addition, they
lack the NAS and session identification AVPs that would appear to
be necessary for proper identification. Therefore the RAR and STR
messages defined in Diameter Base probably can't be used in applications
without defining additional AVPs.

I am assuming that the intent in Diameter Base is just to define the basic
commands and allow individual applications to specify how they are used in
more detail. However Diameter NASREQ nor Diameter MIPv4 contain the
required details -- which leads me to believe that this is a more basic
problem that reflects some gaps in thinking about how these commands
really work?

Comments?

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 11 Apr 2003 06:15:33 -0700 (PDT)

That seems reasonable. However, it seems to have been 'forgotten' in the
applications, too.