FW: securityName

So veryone can read and/or chime in

Thanks,
Bert 

-----Original Message-----
From: Murwin William-LWM008 [mailto:[email protected]]
Sent: donderdag 28 augustus 2003 15:47
To: 'Wijnen, Bert (Bert)'
Subject: RE: securityName


Please feel free to post this, I was not subscribed to the mailing list at the time I sent this email. 

Thanks again,

Will Murwin


-----Original Message-----
From: Wijnen, Bert (Bert) [mailto:[email protected]]
Sent: Thursday, August 28, 2003 7:55 AM
To: Murwin William-LWM008; [email protected]
Subject: RE: securityName


The snmpUsmMIB is for the USM (User-based Security Model).
The snmpCommunityMIB is for the SNMPv1 or SNMPv2c CSM 
(Community-based Security Model, see sect 5 of RFC3584).

So they are clearly different and so you would (in my view) never
have a usmUserTable entry for Community String.

Now, what both USM and CSM do, is they map their specific
security model name into a generic securityName, as per
the figure in sect 3.2, page 25 in RFC3411.

The model dependent security ID for USM is the userName as
transported in the msgUserName in the USMSecurityParamters in an 
SNMPv3 message (RFC3414, sect 2.4. on page 16).

the model dependent security ID for CSM is the communityName
as transported in the community in the SNMPv1 or SNMPv2c message
(as per the definitions in sect 4 of RFC1157, page 16, or
 sect 3 of RFC1901, page 5).

Each of those model dependent security IDs needs to be mapped in a
common ID, namely the securityName.

The mapping from USM userName to securityName is a 1-1 mapping, 
so user Bert in USM also results in securityName Bert and so it 
results in an entry Bert in the usmUserTable.

The mapping from a community (communityName) into a securityName
is not a 1-1 mapping; instead it is mapped via the snmpCommunityTable
into a securityName as defined by snmpCommuntySecurityName.
So theoretiucally, if there was a communityName Bert, then you can
also map that into securityName Bert. and so one could allow
Bert access via SNMPv1/v2c and SNMPv3. If such is wise and
well organised is a matter of taste and policy.

This securityName is then used in the VACM (RFC3415) to grant or 
deny access to various parts of the MIB.

In addition to the securityName, also the securityModel 
and the securityLevel are part of the decision to allow 
or disallow access to MIB information. That is:

You will notice that in the VACM  (figure in sect 3.1 of RFC3415
helps a lot here) the mapping into a groupName takes both 
securityName and securityModel into account. And so you can choose
to make [Bert, USM] and [Bert, CSM] to be in the same group
or in different groups.

Even if you DO put them in the same group, the viewName(s) to which
the group(s) to which Bert belongs take again the securityModel and
the securityLevel into account when deciding to which ones Bert
has access.

Hope this helps/explains.

Thanks,
Bert 
p.s. Do you mind if I post this answer to the SNMPv3 WG mailing list,
so others can see it and/or chime in if needed?

> -----Original Message-----
> From: Murwin William-LWM008 [mailto:[email protected]]
> Sent: donderdag 28 augustus 2003 1:32
> To: '[email protected]'
> Subject: securityName
> 
> 
> Bert,
> 
> 	I have a quick question for you about a gray area 
> between RFC 3584 "Coexistence between Version 1, Version 2, 
> and Version 3 of the Internet-standard Network Management 
> Framework" and RFC 3414 "User-base Security Model (USM) for 
> version 3 of the Simple Network Management Protocol (SNMPv3)".
> 
> Does an agent that has an entry in the "snmpCommunityTable", 
> need to have an entry in the "usmUserTable" where 
> the "usmUserSecurityName" equals the 
> "snmpCommunitySecurityName", for a manager to have SNMPv1/2c 
> coexistence access to that agent if there is their is an 
> instance of "vacmSecutiryToGroupTable" where the instance of 
> vacmSecurityName equals the "snmpCommunityTable".
> 
> I don't see it explicitly call for a  
> "snmpCommunitySecurityName" to be equal "usmUserTable" for 
> coexistence to work.
> I RFC 3584 explicitly says that  "snmpCommunitySecurityName" 
> is a "securityName" and the
> RFC 3414 say that "usmUserSecurityName" is a "securityName". 
> 
> Any light you can shine on the subject is greatly 
> appreciated. I thought about this an both having and not 
> having an entry in the 
> "usmUserTable", and can think of reason for doing this either way.
> 
> Thanks,
> Will 
> 
> P.S. 
> 
> ______________________________
> William Murwin
> Broadband Communications Sector
> Motorola Inc.
> Email: [email protected]
> Tel: (508) 851-8385
>