Wasn't the purpose to allow an admin connecting to a terminal server to administer it over a serial connection?Yes, among other options. I've always implemented NAS-Prompt and Administrative for access to the CLI, regardless of whether the connection was to the local console (e.g. serial RS-232) or via a remote terminal protocol (e.g. via telnet over TCP/IP. Most NASes that I'm familiar with have a host-IP address and (at least) a telnet listener.
My experience with Service-Type=NAS-Prompt (if memory serves) was for administering a NAS over a serial port, with authentication protectedby a token system. As I recall, it was possible to utilize Service-Type=NAS-Prompt
alongside token authentication.In those scenarios, I would guess that the NAS would send Service-Type=NAS-Prompt in the Access-Request, along with no Transport-Protocol attribute. If the user came in via Telnet or SSH, the Transport-Protocol would change depending on what was used. Is this more or less the usage model that is envisaged, where the NAS tells the RADIUS server what type of access is being requested, and the server decides whether to
authorize it? -- 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/>