Re: draft-chiba-radius-dynamic-authorization-15.txt

[Erik Nordmark <Erik.Nordmark@sun.com>]

Would it make sense to take Bernard's text in the email as a basis for 
an applicability statement added to the document?
It seems like useful information for someone reading the RFC
to decide whether or not to use this technology.

  Erik

>----- Begin Included Message -----<

Date: Thu, 17 Apr 2003 10:55:59 -0700 (PDT)
From: "Bernard Aboba" <aboba@internaut.com>
Subject: Re: draft-chiba-radius-dynamic-authorization-15.txt
To: "Randy Bush" <randy@psg.com>
Cc: "iesg" <iesg@ietf.org>

I will address Steve and Russ's comments in -16, available here (will go
over it again during the weekend before submitting):

http://www.drizzle.com/~aboba/IEEE/draft-chiba-radius-dynamic-authorization-16.txt

I believe this draft should be Informational because the protocol
has an inherent semantic ambiguity and because deployed versions of
the protocol have substantial security problems. For example, while we
added Event-Timestamp and IPsec replay protection, deployed
implementations have no liveness, and therefore can be replayed.

Also, existing deployments do not support authorization; that is, any ISP
sharing a NAS can disconnect or change authorizations from other ISPs.
We added an RPF check to fix this.

Finally, the command structure of the protocol is problematic. Instead of
having a CoA-Request set off a normal RADIUS Access-Request/Accept
sequence, a CoA-ACK is sent. The problem with this is that it creates a
semantic ambiguity where within the CoA-Request, attributes can have
one of two meanings: the standard RADIUS meanings, as well as potential
use as a session identification attribute, where instead of "change the
authorization to this" the meaning is "apply the authorizations to sessions
matching this attribute".

This problem was avoided within Diameter, by defining a command where
AVPs are used solely for identification, followed by a standard
Diameter Request/Response sequence where AVPs have their standard
meanings. That way, in no Diameter command are attributes used for
multiple purposes so that there is no ambiguity. If this protocol
were to be designed by a WG (as opposed to merely being documented)
I would advocate that the current command structure be changed,
since among other things it creates problems in gatewaying between
Diameter and RADIUS, since certain operations permissible in Diameter
(such as changing any attribute that draft-chiba uses for
identification) is impossible to carry out.

In summary, this protocol has a sub-standard design, which is the reason
it was not standardized originally. If the desire is to create a standards
track protocol doing the same thing, substantial changes would be
necessary, and a WG should probably be chartered to do this, rather than
going the individual submission route.

On Thu, 17 Apr 2003, Randy Bush wrote:

> -15 does not address steve's and russ's comments
>
> and please record in a message to iesg why info as opposed to ps
>
> randy
>


>----- End Included Message -----<