Subject: RE: [Isms] Discussion: Architecture direction for ISMS

From: "Blumenthal, Uri" <[email-masked]>
Date: Fri, 15 Apr 2005 14:15:52 -0400

> In URI's message below, he has the the example
> "For USM, it could be dynamically created entry with
> usmUserName=securityName="msoukup" ..."
>
> This would not work!

But it will! Se below.

> If one was to attempt to "reuse USM", then
> on session establishment, session keys would be created and
> a session identifier would be created. The session identifier
> (when reusing USM) HAS GOT TO BE the msgUserName field of
> the UsmSecurityParameters sequence (which is the value of
> of the msgSecurityParameters field of SNMPv3 messages.

Exactly. And this msgUserName will match either the dynamically-created
entry in usmUserTable with usmUserName=msoukup, or an existing entry in
the table becomes operative and authorized for this session (and gets
keyed).

> The value of msgUserName name would be temporal, lasting
> only the duration of the session, but also unique during
> its existance.

Yes. This wa my first idea - I think it's the best solution. But it is
also possible to dynamically key ("turn on") existing entries this way.
It works either way.

On Fri, 15 Apr 2005, Blumenthal, Uri wrote:

> Martin, I don't know RADIUS well enough - but if RADIUS User-Name is
> just the name that RADIUS just authenticated, then it's not what we
need
> here. If returned User-Name may be different from the original user
> identity under which user asked RADIUS for
authentication/authorization
> - then it's OK.
>  
> ________________________________
> 
> From: Martin Soukup [mailto:[email-masked]] 
> Sent: Friday, April 15, 2005 8:53 AM
> To: Blumenthal, Uri; [email-masked]'
> Subject: RE: [Isms] Discussion: Architecture direction for ISMS
> 
> 
> 
> 	Ah - yes. The return of this information (User-Name) in the
> Access-Accept would be supported through configuration of any standard
> RADIUS server.
> 	 
> 	martin.
> 
> 		-----Original Message-----
> 		From: Blumenthal, Uri [mailto:[email-masked]] 
> 		Sent: Friday, April 15, 2005 10:58 AM
> 		To: Soukup, Martin [CAR:5K50:EXCH]; [email-masked]
> 		Subject: RE: [Isms] Discussion: Architecture direction
> for ISMS
> 		
> 		
> 		Every existing infrastructure has its own way to
> identify its users. More often than not, these identitites do not
match.
> One of the complaints wrt. SNMPv3 deployment is the fact that its set
of
> identities does not [necessarily] match those other ones - and thus
user
> datastore has to be filled during provisioning or configuration time.
> Thus when a RADIUS user "msoukup" request SNMP access and is
> authenticated+authorized, RADIUS must tell SNMP engine what identity
to
> use in the SNMP traffic packets. For USM, it could be dynamically
> created entry with usmUserName=usmSecurityName="msoukup", or a
reference
> to an already-existing one (then RADIUS should tell which, or there
> should be a rule by which the SNMP engine can figure it out by
itself).
> For other systems - perhaps they can be made to just directly take the
> identity that RADIUS just authorized - but I don't think it would be
any
> easier.
> 
> 
> ________________________________
> 
> 			From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Martin Soukup
> 			Sent: Friday, April 15, 2005 4:10 AM
> 			To: [email-masked]
> 			Subject: RE: [Isms] Discussion: Architecture
> direction for ISMS
> 			
> 			
> 
> 			RADIUS "Access-Accept" indicates a successful
> authenthentication response for a user. 
> 
> 			The Access-Accept already returns a
> "Session-Timeout", defined as "Sets the maximum number of seconds of
> service to be provided to the user before the session terminates. This
> attribute value becomes the per-user "absolute timeout."".
> 
> 			RADIUS is commonly used to return policy (e.g.
> VACM group mapping) and specific uses have been standardized. 
> 
> 			This definitely fits well with EUSM, if
> something which can be tunneled over RADIUS can generate the key
> binding. This is why I like RADIUS.
> 
> 			Uri, I'm not entirely sure what you meant by
> "identity to use" below since authentication presumes an identity was
> already provided?
> 
> 			Martin. 
> 
> 			> -----Original Message----- 
> 			> From: [email-masked] 
> 			> [mailto:[email-masked]] On Behalf
> Of Randy Presuhn 
> 			> Sent: April 14, 2005 8:37 PM 
> 			> To: [email-masked] 
> 			> Subject: Re: [Isms] Discussion: Architecture
> direction for ISMS 
> 			> 
> 			> 
> 			> Hi - 
> 			> 
> 			> > From: "Blumenthal, Uri"
> <[email-masked]> 
> 			> > To: "Thierry Moreau"
> <[email-masked]> 
> 			> > Cc: <[email-masked]> 
> 			> > Sent: Thursday, April 14, 2005 5:22 PM 
> 			> > Subject: RE: [Isms] Discussion: Architecture
> direction for ISMS 
> 			> ... 
> 			> > So in case of RADIUS, the "access granted"
> should be accompanied by: 
> 			> > 
> 			> >  - generated fresh keying for this session
> (including its 
> 			> life-time); 
> 			> >  - identity to use for this connection (as
> probably nobody wants to 
> 			> > configure user database on the SNMP agent
> :-); 
> 			> >  - mapping of that identity onto an existing
> VACM group. 
> 			> ... 
> 			> 
> 			> Sounds a lot like EUSM.  (not that that'd be a
> bad thing) 
> 			> 
> 			> 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

---

From: "David T. Perkins" <[email-masked]>
Date: Fri, 15 Apr 2005 12:03:12 -0700 (PDT)

HI,

Uri, please don't get wrapped up with defending a small mistake
on your part.

There is a big difference between a direct mapping of identity
presented at session initiation to an entry in the USM table,
and the creation, insertion, and removal of entries (with,
of course, unique user name values) in the USM table due to
session establishment and termination. 

Whether or not you create and delete entries in the USM table
(or set existing entries to "active" and "notInService") is
not the issue. (And note, use of "active" and "notInSevice"
is an inappropriate usage.) The issue is what identity to
use (since when USM is "reused", the session message integrity
check (MIC) key is the USM auth key, and the session message
encryption key is the USM priv key). If you use a direct
mapping then you have have at most one simulanious session
per identity! 

So, to recap, if one wanted to "reuse USM" with session setup
done either "out of band" or even "in band", then the
straight forward approach is the following for setting
up a session initiated by a command generator to
a comand responder:
1) Disable USM from use except for a new service that manages
   the dynamic USM entries.
2a) With out of band session set up, the command
   generator authenticates directly with this new service
   using a yet to be defined application protocol.
2b) With in band session set up, the command generator
    sends SNMP messages as done by SBSM using the conents
    of the msgSecurityParameters field to authenticate
    with with a new service.
3) The new service then creates a session identifier (which
   is the temporal USM user name), keys, (and other things,
   like max session lifetime), inserts an entry in the
   USM table, inserts an entry in the to group table,
   and returns this info to the command responder.
   (With out of band, this info is returned a fields
   in the application protocol. With in band, this
   info is returned in the msgSecurityParameters field.)
4) If an explicit "end of session" is needed (which, I believe
   is a good thing), then the command generator (or command
   responder) communicates with the new service, which
   then removes the USM and to group table entries.
5) The new service would "wake up on schedule", and remove
   USM and to group table entries that had reached the
   end of their lifetimes.

Is the above do-able? Sure! Is the above a good thing to do?

I don't believe so, since I believe it is way too fragle,
is bloated, and could probably be more work than just
a new security model. However, I might use a subset of
it as a proto-typing and/or proof of concept for a
new security model.  

Regards,
/david t. perkins