[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: FW: Review of draft-ietf-radext-status-server
> From: Ignacio Goyret [mailto:email@example.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
to unsubscribe send a message to firstname.lastname@example.org with
the word 'unsubscribe' in a single line as the message text body.