I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written primarily for the benefit of the security area
directors.
 Document editors and WG chairs should treat these comments just like any
other
last call comments.

The summary of the review is that this document is ready with some
editorial fixes.

Thanks for your work on this draft!  If this is the last draft, which I
think it may be, I am really glad I got to review it to see the last one
for the WG.  Congratulations!!!

Here's my review:

Abstract:
In the abstract, it reads as though RFC7542 is updated by this draft with
the text that says,
"This specification corrects that omission for
   scenarios where networks use Realm-based proxying as defined in
   [RFC7542]."

The text in the introduction on these two draft is a bit more clear in that
RFC7542 defines a use case that requires this update to RFC5176.  I think
it would be helpful to expand the abstract text to make these points more
clear to the reader.

Nit Section 3.1:
s/activee/active/

Section 3.3:

A sentence like the following seems to invite it to be proved wrong at some
point ;-).

      A twenty octet string is
      more than sufficient to individually address all of the NASes on

DeKok, Alan                   Informational                    [Page 10]
INTERNET-DRAFT  Dynamic Authorization Proxying in RADIUS    30 July 2018

      the planet.

Perhaps a statement that says it is believed this will be sufficient given
current deployment trends may read better and not tempt fate. :-)


Section 4.3.1

For the following paragraph:
   Proxies that record user session information SHOULD verify the
   contents of a received CoA packet against the recorded data for that
   user session.  If the proxy determines that the information in the
   packet does not match the recorded user session, it SHOULD return a
   CoA-NAK or Disconnect-NAK packet, that contains an Error-Cause
   attribute having value 503 ("Session Context Not Found").
Are there privacy recommendations that have already been made to leave out
certain user information, obscure it, or protect it in some way?  If so, a
pointer to that documentation would be a nice addition.  If not, a pointer
to RFC6793 would be helpful.

Section 6.

The ability to attack, intercept or inject data into RADIUS sessions should
be mentioned as a security consideration.  Is there an RFC that explains
how sessions can be encrypted that can be referenced (TLS for server to
server connections and DTLS for client)?  If not, I think it's worth adding
a sentence so that people are aware of these options even if they don't
care to implement them.


-- 

Best regards,
Kathleen