RE: [Isms] RE: Follow up on Authorize Only issue

["Nelson, David" <dnelson@enterasys.com>]

Jeffrey Hutzelman writes...

> Overloading Service-Type in this way was almost certainly a 
> mistake; ...

Perhaps.

> ...as you note, it prevents the attribute for being used for 
> its intended purpose, ...

In this case, providing a service hint.

> I think this is up to radext to fix; possibilities I can think of are
> defining an "authorize-only" authentication mechanism, or defininig a
new
> attribute which carries the value that Service-Type would have had.

One suggestion that comes to mind is to create a new attribute called
Asserted-Identity, which could be empty.  In RADIUS, the authentication
method is implicitly selected by the inclusion of the corresponding
credential-bearing attribute(s), such as User-Password, CHAP-Password,
EAP-Message, etc.  Asserted-Identity could be the attribute which
selects the Authorize Only authentication method. 

> I must note, BTW, that if you are trying to restrict what information
the
> RADIUS server gives out because you don't trust the NAS, then giving
out
> informaton based on what service the NAS claims it is providing, or
what
> port type the NAS claims the user came in on, is kind of silly.

Right.  But providing hints in the Access-Request message is still
necessary for the RADIUS server to make an informed policy decision as
to which service to provision, from among those allowed for the user,
and to put the corresponding attributes in the Access-Accept message.


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