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

From: David Harrington <[email-masked]>
Date: Fri, 12 May 2006 11:54:04 -0400

Hi,

-----Original Message-----

         I've been doing research on a new SNMPv3 security model,
using PKI for entity identity verification. However, after the two
entities performed handshake and verified the identities of each
other, I got no idea how to map the identity (e.g. the subject of the
public key certificate) to SNMPv3 dependent SecurityName. 

I think SSHSM has to solve the same problem, but I read through
draft-ietf-isms-secshell-02.txt, and was still unable to understand
how and where SSHSM decides if the SSH dependent username is
authorized to be mapped to a specific SecurityName. Where are the
access rights of the entities stored? Does the mapping happen at the
RADIUS server? So could you please help to specify the mapping
process? 

Realize that I am muddling my way through these questions myself. But
let me try to answer them for you.
 
1) How does one map from an SSH identity to an SNMP identity?
 
How an authenticated identity is mapped to the securityName is
implementation-dependent. It is not standardized.
 
In SSHSM, the default mapping is the "identity transform" - the name
used by SSH in the "user name" field in SSH is the name that gets
mapped to securityName. 
 
Implementations may choose to use a different mapping of their own
choice. One way to allow for such a mapping would be to have a MIB
module with a mapping table. It would have to be pre-populated with a
translation table between what SSH authenticates and an SNMP
securityName, which would make it harder to deploy than using the
identity transform.
 
2) How do we determine who is authorized to open an SNMP session?
 
This question has not yet been addressed by the ISMS WG.
 
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. 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.
 
We deliberately chose to only discuss the connection between SNMP and
SSH, and not to address whether SSH seeks authorization information
from RADIUS or other AAA server to make its access decision. That is
an SSH implementation and deployment decision.
 
David Harrington
[email-masked]
[email-masked]
[email-masked]

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 15 May 2006 23:33:31 +0200

On Fri, May 12, 2006 at 11:54:04AM -0400, David Harrington wrote:
 
> 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".

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

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