Subject: RE: Fwd: [Isms] EUSM key localization details

From: "Blumenthal, Uri" <[email-masked]>
Date: Mon, 15 Nov 2004 12:10:05 -0500

Yes, AAA must receive the snmpEngineID in order to compute localized
key, and AAA should verify authorization. Re. newtributes - a new EAP
method is being defined anyway, right?

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Joseph Salowey
Sent: Monday, November 15, 2004 11:50 AM
To: 'Randy Presuhn'; [email-masked]
Subject: RE: Fwd: [Isms] EUSM key localization details

[email-masked] wrote:
> Hi -
> 
>> From: "Kaushik Narayan" <[email-masked]>
>> To: "Wes Hardaker" <[email-masked]>
>> Cc: <[email-masked]>
>> Sent: Saturday, November 06, 2004 10:33 AM
>> Subject: Re: Fwd: [Isms] EUSM key localization details ...
>> This would mean that agents do-not need to acquire keys to serve an
>> SNMPv3 engine ID discovery request and SNMP Managers can discovery
>> engine IDs and bootstrap the AAA server.
> ...
> 
> Which brings us back to my question at the start of this thread:
> how does the AAA server know *which* of the SNMP engine IDs
> to use?  The information described in the proposal as flowing in
> the RADIUS Key_Request   (Key (App ID),  Calling-Station-ID,
> User-Name) is not sufficient to map to a single engine ID,
> since there may be multiple SNMP engines in a single system.
> 

[Joe] Yes I think we need an attribute to contain the SNMP Engine ID
making
the request.  I'm not sure if we can use existing attributes to convey
this
information, we may need to create a new one.  The AAA server still
should
verify that the engine ID is authorized to the RADIUS client making the
request.  

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

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

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

---

From: "Joseph Salowey" <[email-masked]>
Date: Mon, 15 Nov 2004 10:20:48 -0800

Hi Uri,

We should use existing EAP methods that generate keys, we don't really want
to create special methods for SNMP. 

There are basically three parts to the proposal.

1. Authenticated Key setup between SNMP manager and key server

This protocol should authenticate the user and the key server, establish a
strong key, and be flexible in mechanism.  We suggest using EAP in RADIUS.
The EAP framwework is useful because it integrates with AAA servers for
authentication. The EAP methods used should not be SNMP specific.  

2. Communication of keys from key server to SNMP agent

This requires secure transmission of the correct localized SNMPv3 keys from
key server to agent.  If the key server is co-located with the agent then
this is a local API matter.  If the key server is remote from the agent then
you can gain the benefit that one key setup procedure can be used to set up
a key that can be the basis for security for many agents.  We suggest using
some extensions to RADIUS for this key transport.  It would also be useful
to communicate other parameters such as VACM information to the agent in
this protocol as well.  RADIUS is useful since many entities containing
agents are RADIUS clients as well.  

3. EUSM enhancement to SNMPv3 between agent and manager

This is enhancements to SNMPv3 to support key material that is established
external to SNMP processing.  The main goal here was to keep changes to
SNMPv3 as minimal as possible.  

Joe

[email-masked] wrote:
>  Yes, AAA must receive the snmpEngineID in order to compute
> localized key, and AAA should verify authorization. Re.
> newtributes - a new EAP method is being defined anyway, right?
> 
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Joseph Salowey
>> how does the AAA server know *which* of the SNMP engine IDs to use?
>> The information described in the proposal as flowing in
>> User-Name) is not sufficient to map to a single engine ID, since
>> there may be multiple SNMP engines in a single system.
>> 
> 
> [Joe] Yes I think we need an attribute to contain the SNMP
> Engine ID making the request.  I'm not sure if we can use
> existing attributes to convey this information, we may need
> to create a new one.  The AAA server still should verify that
> the engine ID is authorized to the RADIUS client making the request.
> 
>> Randy
>> 
>> 
>>

---

From: "Tom Petch" <[email-masked]>
Date: Thu, 25 Nov 2004 14:15:14 +0100

I wish you did not use the terms SNMP agent and SNMP manager; I am never
quite sure if that is what you mean, perhaps because manager-manager
communication has been an integral part of network management for me for
ages.

I think SNMPv3 got it right in principle with authoritative and
non-authoratitive engines, but might have found better words, easier to
say, spell and type:-(

I prefer client and server or in my own private jottings use autheng and
nautheng.

Tom Petch
NW Networks

---

From: "David T. Perkins" <[email-masked]>
Date: Fri, 26 Nov 2004 11:19:38 -0800 (PST)

HI,

Tom - it is difficult to determine, since it was somewhat of a
passing reference, but you raised some red flags and may not
understand the SNMPv3 architecture and protocol. The terms
"authoritative and non-authoritative engineIDs" are NOT SNMPv3
protocol terms, but are specific to the user security model (USM).
The concept is required in USM due to the shared value of
a "clock" that is used to help with replay protection, and
to a lesser degree the shared identity (and keys) used for
message integrity and content privacy.

Other security models don't use the terms "authoritative
and non-autoritative engineIDs". Also, with USM these
terms do not map to "operation initiator and responder"
or "client and server".

So, I'm confused as to why you used them in complaining
about use of terms manager and agent. Would you explain.

> I prefer client and server or in my own private jottings use autheng and

Regards,
/david t. perkins

---

From: "David B Harrington" <[email-masked]>
Date: Fri, 26 Nov 2004 16:24:50 -0500

Hi Tom,

Let mne respond to two threads within the current thread.

1) Distinguishing Entities

I suggest the better choice of wording to distinguish the roles of two
SNMPv3 entities is to discuss the application being used, per RFC3413.
Is each role one of command generator, command responder, notification
originator, notification receiver, proxy forwarder, or other
yet-to-be-defined application role? 

We deliberately stopped using agent and manager after the SNMPv2 and
its variations because too many entities do not fit the classic
definition of agent or manager, and the need to keep security vitual
databases on both the agent and receiver made it very complex to
determine whether an emtity was operating in an agent or manager role.

2) Authoritative and the SNMPv3 Architecture

The concept of an authoritative engine is part of the architecture
described in RFC3411 and RFC3412; it is part of the
generateRequestMsg(), processIncomingMsg(), generateResponseMsg() ASIs
between the message-processing subsystem and the security subsystem.
It is important to identify which virtual database should be used for
the security credentials when processing an SNMP message.
	
USM is the first concrete specification of how and when to utilize
authoritative credentials, and the SNMPv3 message format is the first
concrete specification of a message format which includes a
securityEngineID. RFC3412 section 7 is devoted to SNMPv3-message
processing (v3MP), and describes how the v3MP and potentially-multiple
security models share the knowledge of which engine is authoritative.
Another message processing model would be expected to pass the
authoritative engine between subsystems.

Different add-on message processing models and different add-on
security models may impact which engine is authoritative, and no
assumptions should be made that future usage will necessarily be
consistent with the v3MP/USM usage. The use of authoritative is rather
complex, and I recommend that it NOT be used to distinguish the
functional roles of the entities. I recommend it only be used when
discussing a specific security model's approach to authoritative.

General note on ASIs:

Note that RFC3411 and RFC3412 describe conceptual application service
interfaces (ASIs), which are present only to make it easier to develop
add-on modules, such as new security models. The ASIs of RFC3411 and
RFC3412 identify the conceptual information that theoretically is
necessary to share between architectural subsystems (and models of
those subsystems). When a security model uses an authoritative engine,
it shares the identity of the authoritative engine with the messaging
processing subsystem in the architecture via the securityEngineID
parameter of the relevant ASI.

The SNMPv3 design team recommended that the conceptual information
used within a subsystem's model SHOULD NOT be shared with other
subsystems, unless necessary, in order to prevent creating
dependencies between models of different subsystems, i.e. for "data
hiding" reasons. The avoidance of inter-subsystem dependencies was
very deliberately done to allow different models to advance in the
standards track independently of each other. 
 
David Harrington
[email-masked]

> [mailto:[email-masked]] On Behalf Of Tom Petch
> Sent: Thursday, November 25, 2004 8:15 AM
> To: Joseph Salowey; [email-masked]
> Subject: Re: Fwd: [Isms] EUSM key localization details
> 
> I wish you did not use the terms SNMP agent and SNMP manager; 
> I am never quite sure if that is what you mean, perhaps 
> because manager-manager communication has been an integral 
> part of network management for me for ages.
> 
> I think SNMPv3 got it right in principle with authoritative 
> and non-authoratitive engines, but might have found better 
> words, easier to say, spell and type:-(
> 
> I prefer client and server or in my own private jottings use 
> autheng and nautheng.
> 
> Tom Petch
> NW Networks
> > We should use existing EAP methods that generate keys, we 
> don't really
> want
> > The EAP framwework is useful because it integrates with AAA
servers
> for
> > This requires secure transmission of the correct localized 
> SNMPv3 keys
> from
> > key server to agent.  If the key server is co-located with the
agent
> then
> > you can gain the benefit that one key setup procedure can be used
to
> set up
> > a key that can be the basis for security for many agents.  
> We suggest
> using
> > some extensions to RADIUS for this key transport.  It would also
be
> useful
> > to communicate other parameters such as VACM information to 
> the agent
> in
> > external to SNMP processing.  The main goal here was to keep
changes
> to
> > >>> This would mean that agents do-not need to acquire keys to
serve
> an
since 
> > > making the request.  I'm not sure if we can use existing 
> attributes 
> > > to convey this information, we may need to create a new one.
The 
> > > AAA server still should verify that the engine ID is 
> authorized to 
> > > the RADIUS client making the request.
> > >
> > >> Randy
> > >>
> > >>
> > >>