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

[Thomas Narten <narten@us.ibm.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.

I had a similar thought, though the second half of the note would need
a bit more wordsmithing and removal of "I would.." type comments.

But it would be nice to capture some of this somewhere in the RFC
itself.

Thomas

>   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 -----<