Subject: [Isms] radius usage

From: "Tschofenig, Hannes" <[email-masked]>
Date: Fri, 19 Aug 2005 11:14:15 +0200

hi all 

i was wondering about the purpose of the radius interaction. 
what is the purpose of the radius interaction?  
a) key transport
b) authorization

in case of (b): what is the authorization decision that is made by the
radius server?  
what input by the radius client is needed in order for the radius server
to make a decision?
if a decision is made is it binary (accept/reject)?  

ciao
hannes

_______________________________________________
Isms mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/isms

---

From: "Nelson, David" <[email-masked]>
Date: Fri, 19 Aug 2005 10:37:59 -0400

Hannes Tschofenig writes...

> what is the purpose of the radius interaction?

(1) authentication
(2) authorization

Using the SSH transport, SSH provides the key agreement mechanism, so
that transport via RADIUS is not required.

> in case of (b): what is the authorization decision that is made by the

RADIUS servers provide authorization in two ways.  If the Access-Request
message contains suitable "hint" attributes, e.g. that the requested
access is for ISMS, the RADIUS server may compare those attributes
against a profile of allowed services (or a group of profiles) for a
given user account to determine whether an Access-Accept or
Access-Reject will be returned.

Additionally, based on group membership properties of the user account
(and possibly the access profiles) the RADIUS server may return a
customized set of service provisioning attributes.  For example, it
could specify that the service to be provisioned is SNMPv3 access via
ISMS. It could additionally return attributes to map into securityName
or groupName.

See the I-D,
http://www.ietf.org/internet-drafts/draft-nelson-radius-management-autho
rization-02.txt for examples of these types of attributes.

> what input by the radius client is needed in order for the radius
server

The minimum required is the User-Name attribute and suitable
credentials, such as User-Password.  Adding "hint" attributes in the
Access-Request that describe the requested service would be of benefit.

> if a decision is made is it binary (accept/reject)?

The decision is binary, but the accept decision may contain specific
service provisioning attributes. Generally speaking, if a RADIUS client
cannot provide the specific service provisioned in the Access-Accept, it
is expected to treat it as an Access-Reject.