Subject: RE: [Isms] RE: A Question about SSHSM Username mapping

From: "Nelson, David" <[email-masked]>
Date: Mon, 15 May 2006 17:59:56 -0400

Juergen Schoenwaelder writes...

> > In SSHSM, we currently don't make an explicit access authorization
> > decision at the point of establishing an snmp session.
> > If the person (or principal) can authenticate himself, he is allowed
> > to open an SNMP session.
> 
> In some sense, this is already a first level access control decision.
> The question was "who is authorized to _open_ an SNMP session" and the
> answer I think is "any user how can authenticate".

This is the model used by systems such as SSH.  It is basically an
authentication model.  What may be desired is an authentication and
authorization model.
 
> > But when that person tries to access SNMP data, the access control
> > model (e.g., VACM) determines whether they are authorized to get
> > access to the data.
> >
> > We probably need to address this better, because the current
approach
> > is vulnerable to denial of service attacks from those who have
access
> > to the device, but should not have access to snmp.
> 
> Our code hooks into PAM and you have PAM configuration specifically
> for SNMP. In other words, I am not sure the problem really exists (or
> at least it is not worse than for any other SSH subsystem).

I think the problem is no worse than for any other SSH subsystem.  OTOH,
it seems to me that existing SSH subsystems are about authentication and
not authorization.  For example, if you use SSH to log into a remote
host, the fact that you have authentication credentials available on
that host (locally or remotely), is sufficient to give you a shell
prompt.  Your authorization to access data objects and services is
typically controlled by file access permissions of one sort or another,
implemented within the host OS.

In terms of opening an SNMP session, we can assume that a similar model
applies.   There are existing access control methods for SNMPv3.  One
shortcoming, however, is that the standard PAM interface does not
provide the authorization information -- only an authenticated identity.
In order to take advantage of full integration with existing AAA
infrastructures, such as RADIUS, we have tentatively decided that SSHSM
needs to perform an separate authorization request, after the SNMP
session is initiated from SSH.

The fact that a user may authenticate in some administrative domain, and
is allowed to log onto any workstation in that domain, does not mean
that user should have management access to the network infrastructure.

Mapping authenticated identity to the SNMP securityName is only
sufficient if you plan to store all the valid usernames in each managed
entity.  I think the benefit of adding an authorization phase to SSHSM
is that an authenticated authorization level can be used at each managed
entity to determine whether SNMP access is allowed at all, and if so
what access control should be applied.  In practical terms the number of
unique authorization "names" is small -- akin to the number of groups in
a password authentication system.  It allows the binding of users to
groups to occur in the AAA back end system, and the managed entities to
be configured with a small number of group names for authorization
purposes. 

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

---

From: "Salowey, Joe" <[email-masked]>
Date: Mon, 15 May 2006 16:17:03 -0700

> -----Original Message-----
> From: Juergen Schoenwaelder [mailto:[email-masked]] 
> Sent: Monday, May 15, 2006 2:34 PM
> To: David Harrington
> Cc: [email-masked]
> Subject: Re: [Isms] RE: A Question about SSHSM Username mapping
> 
> On Fri, May 12, 2006 at 11:54:04AM -0400, David Harrington wrote:
>  
> > 2) How do we determine who is authorized to open an SNMP session?
> >  
> > This question has not yet been addressed by the ISMS WG.
> >  
[Joe] I think this is an implementation decision.  An implementation may
wish to authorize access to the SNMP subsystem for some users access and
deny others.  

> > We probably need to address this better, because the 
> current approach
> > is vulnerable to denial of service attacks from those who 
> have access
> at least it is not worse than for any other SSH subsystem). I checked
> the security considerations in the netconf over ssh ID as well and
> there was nothing about denial of service either.
>   
> /js
> 
> -- 
> Juergen Schoenwaelder		    International University Bremen
> <http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 
> 28725 Bremen, Germany
>

---

From: "Kaushik Narayan \(kaushik\)" <[email-masked]>
Date: Mon, 15 May 2006 16:26:17 -0700

Hi David,

Please find my reply inline. 

<snipped>

<Kaushik> I don't think this an SSH issue since SSH is primarily
responsible for transport channel  after successful authentication.
Authorization is well within realm of SNMP and we have really never
addressed how ISMS is going to handle authorization of principals
authenticated externally. I agree with you that requiring securityName
mappings on each SNMP engine really does not do anything to address the
administrative burden we sought fix with ISMS. VACM already has the
concept of groups, group-mapping is the most effective way of addressing
authorization and that's what we had proposed with EUSM. Infact
group-mapping may be leveraged by other management protocols such as
NetConf for authorization of operations.

---

From: "Khanh Nguyen \(khanhvn\)" <[email-masked]>
Date: Mon, 15 May 2006 20:47:46 -0700

PAM interface can be used for authorization.  After a call to
pam_authenticate, application can call pam_acct_mgmt to check if the
user have certain access right.  We've been using PAM succefully to
authenticate and authorize users via TACACS+.

Khanh

> From: Kaushik Narayan (kaushik) 
> Sent: Monday, May 15, 2006 4:26 PM
> To: Nelson, David; [email-masked]
> Subject: RE: [Isms] RE: A Question about SSHSM Username mapping
> 
> Hi David,
> 
> I think the problem is no worse than for any other SSH 
> subsystem.  OTOH, it seems to me that existing SSH subsystems 
> are about authentication and not authorization.  For example, 
> if you use SSH to log into a remote host, the fact that you 
> have authentication credentials available on that host 
> (locally or remotely), is sufficient to give you a shell 
> prompt.  Your authorization to access data objects and 
> services is typically controlled by file access permissions 
> of one sort or another, implemented within the host OS.
> 
> shortcoming, however, is that the standard PAM interface does 
> not provide the authorization information -- only an 
> authenticated identity.
> In order to take advantage of full integration with existing 
> AAA infrastructures, such as RADIUS, we have tentatively 
> decided that SSHSM needs to perform an separate authorization 
> request, after the SNMP session is initiated from SSH.
> 
> The fact that a user may authenticate in some administrative 
> domain, and is allowed to log onto any workstation in that 
> domain, does not mean that user should have management access 
> to the network infrastructure.
> 
> Mapping authenticated identity to the SNMP securityName is 
> only sufficient if you plan to store all the valid usernames 
> in each managed entity.  I think the benefit of adding an 
> authorization phase to SSHSM is that an authenticated 
> authorization level can be used at each managed entity to 
> determine whether SNMP access is allowed at all, and if so 
> what access control should be applied.  In practical terms 
> the number of unique authorization "names" is small -- akin 
> to the number of groups in a password authentication system.  
> It allows the binding of users to groups to occur in the AAA 
> back end system, and the managed entities to be configured 
> with a small number of group names for authorization purposes. 
> 
> 
> <Kaushik> I don't think this an SSH issue since SSH is 
> primarily responsible for transport channel  after successful 
> authentication.
> Authorization is well within realm of SNMP and we have really 
> never addressed how ISMS is going to handle authorization of 
> principals authenticated externally. I agree with you that 
> requiring securityName mappings on each SNMP engine really 
> does not do anything to address the administrative burden we 
> sought fix with ISMS. VACM already has the concept of groups, 
> group-mapping is the most effective way of addressing 
> authorization and that's what we had proposed with EUSM. 
> Infact group-mapping may be leveraged by other management 
> protocols such as NetConf for authorization of operations.
> 
>