Subject: RE: [Isms] #19: should RADIUS be exposed outside of SSH?

From: "Kaushik Narayan \(kaushik\)" <[email-masked]>
Date: Fri, 14 Oct 2005 10:48:06 -0700

Please find my reply inline. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Nelson, David
Sent: Friday, October 14, 2005 10:18 AM
To: [email-masked]
Subject: RE: [Isms] #19: should RADIUS be exposed outside of SSH?

> Subject: [Isms] #19: should RADIUS be exposed outside of SSH?

Yes and no.  The details of RADIUS authentication need not be exposed
outside of SSH, except for making the authenticated identity (e.g.
User-Name) available.  The details of RADIUS authorization, which may be
mapped onto, or otherwise impact, SNMP access control mechanisms need to
be exposed to SNMP.

<Kaushik>

This is not a RADIUS specific requirement, there needs to be a way to
map the user identity authenticated by SSH to the SNMPv3 securityName.

One point that hasn't had much [any] discussion is that AAA services
such as RADIUS and Diameter are designed to provision a specific
service, such as packet forwarding or telnet terminal services.  I
believe that AAA should provision SNMP management access as a specific
service, and therefore a RADIUS authorization for SNMP access should not
be capable of being used for packet forwarding services (or visa versa).
This is another level of authorization that would need to be exposed
beyond SSH.

<Kaushik>

This is an important discussion but it isn't this specific to AAA
handling of management (CLI, NetConf, SNMP) authorization.

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

---

From: "Nelson, David" <[email-masked]>
Date: Fri, 14 Oct 2005 15:10:38 -0400

Kaushik Narayan writes...
 
> map the user identity authenticated by SSH to the SNMPv3 securityName.

Good point.  I had assumed that the question was using RADIUS as a
specific instance of generalized AAA service "exposure" requirements.

> handling of management (CLI, NetConf, SNMP) authorization.

Yes, in a way.  However, there is no RFC that I'm aware of that
describes RADIUS provisioning of management other than CLI
(Service-Types of Administrative and NAS-Prompt).  While not an issue
for SSHSM itself, it is an issue for a RADIUS document that supports
SSHSM, and probably an issue for SSH implementations used to support
SSHSM.

---

From: "Kaushik Narayan \(kaushik\)" <[email-masked]>
Date: Fri, 14 Oct 2005 13:25:34 -0700

Would this part of a RADIUS document for SSHSM or a general document
that talks about RADIUS extensions for network management. I personally
prefer a more generic approach here although there might be some SNMP
specific attributes.

---

From: "Nelson, David" <[email-masked]>
Date: Fri, 14 Oct 2005 16:33:50 -0400

> prefer a more generic approach here although there might be some SNMP

Most likely in a RADIUS extensions for network management document,
which could contain some specific attributes for SNMP.  Coincidentally,
there is such an I-D, authored by Greg Weber and myself.  I have
mentioned this document before.  Once the ISMS requirements are clear,
we will likely make the appropriate revisions to this draft.

http://www.ietf.org/internet-drafts/draft-nelson-radius-management-autho
rization-02.txt

---

From: "Kaushik Narayan \(kaushik\)" <[email-masked]>
Date: Fri, 14 Oct 2005 13:54:16 -0700

I agree that it makes sense to treat SNMP management access as a
separate service.  I wonder whether there would be any value to
subdividing that service into, for example, notification, monitoring,
and control services.

<Kaushik>

The RADIUS service would typically serve as a namespace for
authorization information. We also need to careful about proliferation
of services since they would make administration of authorization more
difficult on a RADIUS server. I am really not sure about the need for
separate services for notification, monitoring etc.

---

From: "Salowey, Joe" <[email-masked]>
Date: Fri, 14 Oct 2005 14:26:46 -0700

Something to also consider when looking at management extensions for
RADIUS is that the exact type of management may not be know at
authentication time.  For example if the same SSH service is used for
SNMP, CLI and NETCONF you probably won't know what the SSH client wants
until it invokes the appropriate subsystem.  The same is true for more
fine grained services. 

> From: Narayan, Kaushik 
> Sent: Friday, October 14, 2005 1:54 PM
> To: Randy Presuhn; [email-masked]
> I agree that it makes sense to treat SNMP management access 
> as a separate service.  I wonder whether there would be any 
> value to subdividing that service into, for example, 
> notification, monitoring, and control services.
> 
> 
> <Kaushik>
> 
> authorization information. We also need to careful about 
> proliferation of services since they would make 
> administration of authorization more difficult on a RADIUS 
> server. I am really not sure about the need for separate 
> services for notification, monitoring etc.
>

---

From: "Nelson, David" <[email-masked]>
Date: Fri, 14 Oct 2005 17:40:00 -0400

Salowey, Joe writes...

> authentication time.

Yes.

>  For example if the same SSH service is used for

There are three ways that AAA systems that provision specific services
typically deal with this issue:

1. the user identity presented for authentication is unique to the
specific service,

2. the AAA client identity is unique to the specific service, or

3. the AAA client provides hints to the AAA server in the authentication
request as to what service is being requested.

The third approach is most common.  In the case of an SSH connection
where the application protocol is not known at authentication time, this
presents a problem.  Either the AAA system provides authentication
without authorization, or some other method needs to be found.

It seems like this in an AAA/SSH issue, and requires some further
investigation.

---

From: "Kaushik Narayan \(kaushik\)" <[email-masked]>
Date: Fri, 14 Oct 2005 14:58:44 -0700

There are two options

The AAA server sends down all the management authorization information
specific to that particular user. We can have the service names that are
qualified, i.e. mgmt-snmp, mgmt-netconf and a SSH authentication request
can send a mgmt* which would result in all management authorization
information to be returned. The appropriate management protocol can then
use this information based on what requests arrive on authenticated SSH
channel.

The other option is to allow for authorization when requests are sent on
top of the SSH channel, this will however require change to protocols
such as RADIUS, Diameter to support explicit authorization from the NAS
to the AAA server.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Nelson, David
Sent: Friday, October 14, 2005 2:40 PM
To: [email-masked]
Subject: RE: [Isms] #19: should RADIUS be exposed outside of SSH?

Salowey, Joe writes...

Yes.

>  For example if the same SSH service is used for SNMP, CLI and NETCONF

> you probably won't know what the SSH client
wants

---

From: "McDonald, Ira" <[email-masked]>
Date: Sun, 16 Oct 2005 10:07:14 -0700

Hi,

A separate port would be a very good idea for SNMP over SSH.

Using the same port for SSH supporting different management
application protocols just reduces the granularity of admin
policy (and therefore reduces the likelihood of widespread
deployment).

Frankly, I cannot imagine any utility for authentication of
either initiator or responder in an SNMP over SSH session
if ISMS doesn't address authorization (i.e., access control).

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Blue Roof Music / High North Inc
PO Box 221  Grand Marais, MI  49839
phone: +1-906-494-2434
email: [email-masked]

> From: [email-masked] 
> [mailto:[email-masked]]On
> Behalf Of Eliot Lear
> Sent: Sunday, October 16, 2005 10:17 AM
> To: Nelson, David
> Cc: [email-masked]
> Subject: Re: [Isms] #19: should RADIUS be exposed outside of SSH?
> 
> 
> Nelson, David wrote:
> We should be very careful how we do this.  We do not want to 
> tie SSHSM 
> to radius or diameter.  In order to even determine this prior to 
> authentication (the specific SNMP subsystem request is made *after* 
> authentication) it seems to me that a separate port is required.
> 
> Eliot
>