Re: FW: Review of draft-ietf-radext-status-server

[Alan DeKok <aland@deployingradius.com>]

> From: Ignacio Goyret [mailto:igoyret@alcatel-lucent.com] 
...
> Anyway, I did a cursory review and have one technical comment
> and a few trivial editorial fixes:
> 
> 1) (tech comment) To be frank, both myself and our RADIUS engineers
> were quite surprised that the response to a Server-Status is not
> a code+1, or some other code like a fictitiuous "Server-Response".

  Yes.  I think it's because there was no "response" packet pre-defined.
 I suspect that the implementors didn't want to self-allocate.

> The overloading of Access-Accept and Accounting-Response for
> this purpose (response to a Server-Status command) is a bit
> disconcerting and quite dangerous since it opens the door
> for potentially bogus authentication.

  I'm not sure why.  The response packets are signed with the Request
Authenticator of the request.  i.e. the client *knows* that the
Access-Accept is in response to a Status-Server. So it has no "user
session" to authenticate.

> I know that it is past WGLC so dramatic changes are out of
> the question, but if nothing else, you should add some text
> explaining the decision for this overloading.

  OK.  I'll put something together.

  The rest of your comments are editorial, and will go into the document
as-is.

  Alan DeKok.

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>