Subject: Re: [Isms] RE: Call for consensus

From: Keith McCloghrie <[email-masked]>
Date: Thu, 18 Aug 2005 06:48:53 -0700 (PDT)

Bert,

After a (cold) reboot, an agent will typically send a coldStart
notification.  If that notification is to be sent via a TCP-based
transport mapping, then the agent has to setup the TCP connection.
The notion of "trap-based polling" has been part of SNMP since the
beginning, wherein an agent sends a notification to a manager and the
manager decides to send requests to the agent based on the information
contained in the notification.  What Eliot describes is equivalent to a
"trap-based polling" scenario for a notification such as coldStart.

Keith.

> Thanks Eliot. Your explanantions are very useful
> (at least to me). 
> 
> So based on what you say, then I see:
> - Call-Home is a new function that we do not have
>   in current SNMPv3. 
> - Call-Home is not a specific issue w.r.t. the 
>   WG charter, which is (in my view) to develop
>   a securityModel that provides better integration
>   with existing operational security infrastructure.
> - Call-Home is also not available (in the mandatory
>   to implement) NetConf over SSH. So it cannot be
>   assumed to be available in that environment.
> - You may have uncovered/presented a feature that
>   operators may need or want, but I do not think 
>   that that feature falls in this WG's charter, the
>   more since you explain that it is not well enough
>   defined/available in NetConf (mandatory parts) and
>   also not in current SNMPv3.
> - So if such a feature is indeed needed/wanted, then 
>   it seems something that may need separate attention.
>   Possibly in a separate WG, possibly as individual
>   submission, Possibly in Netconf as a follow on
>   work item, and maybe later (or at lower priority)
>   in ISMS. But I claim it is not the primary task of
>   this WG to focus on it.
> 
> Just my individual opinion.
> Bert
> p.s. Hope you feel much better today!
> 
> > -----Original Message-----
> > From: Eliot Lear [mailto:[email-masked]]
> > Sent: Thursday, August 18, 2005 07:39
> > To: Wijnen, Bert (Bert)
> > Cc: [email-masked]; Margaret Wasserman; Andy Bierman
> > Subject: Re: [Isms] RE: Call for consensus
> > 
> > 
> > Good morning, Bert.
> > 
> > I'm sorry for the delayed response- out sick yesterday.  
> > Please see below.
> > 
> > > Pls write a short paragraph or two that explains exactly
> > > what you mean with "call home". I think it is a term
> > > that means something in your mind, and possibly something
> > > else in my (or other peoples) mind(s). So having a good
> > > definition, so we all know what we're talking about is
> > > (I think) a good thing.
> > 
> > "Call home" is the act of the managed element initiating the transport
> > connection to the manager for the purpose of being managed in 
> > some way.
> >  An example of a "call home" function would be any of the 
> > various update
> > mechanisms in your Microsoft Windows / Apple / SuSE Linux software
> > update services.
> > 
> > This function is used explicitly for several reasons.  First, many
> > elements are unavailable through firewalls or NATs largely because the
> > firewall does not support transport of other than specific 
> > UDP functions
> > such as DNS and/or NTP and/or certain gaming applications.
> > 
> > Second, there is an inherent security benefit for devices that do not
> > have to (TCP/SCTP) LISTEN or otherwise accept random UDP requests as
> > SNMP does since the lower levels filter out communications that the
> > device didn't establish.  The level of benefit is of course tied to
> > whether or not TLS is run atop the connection or IPSEC is run 
> > below it,
> > but from a configuration perspective the latter isn't all that easy.
> > 
> > > 
> > > Then, I'd like to know where/how you think current SNMPv3
> > > provides it. That makes it much easier for me to map
> > > the concept onto things I know.
> > 
> > The current SNMP does not provide this function.  Were we to 
> > add it the
> > identities mapped must be explictly mentioned in the draft.  
> > TCP offers
> > us important opportunity, however, that would not have come up had UDP
> > remained the transport of choice in ISMS.
> > 
> > > 
> > > Then I'd like you to uncover some more of the "obliqueness"
> > > of where how it is done in NetConf (over BEEP). You seem to 
> > > claim (implicit) that NetConf "consciously decided to have
> > > a call-home" functionality, but I am not so sure they did.
> > 
> > As you can read from the BEEP draft either side may initiate the
> > connection.  We didn't use the term "call home", that's all.  The
> > design-team had a discussion on this point and Margaret claimed that
> > since the function was available to BEEP it needn't be present in all
> > mappings.  While I didn't think much of the answer at the time (I
> > prefered all mappings to offer all functions), since I could do what I
> > wanted to do in BEEP I was happy enough.  I've CC'd Margaret 
> > and Andy as
> > they can check my memory and notes (much of this occurred on 
> > the phone).
> > 
> > > In any event, if they have it via the NetConf over BEEP
> > > mechanism, then they cannot assume it will be present,
> > > because only NetConf over SSH is mandatory to implement.
> > 
> > When we offer the same service we should use the same method to
> > accomplish the task.  As I've written, I'm not wedded to BEEP but I do
> > think we need this capability in either and we should implement it in
> > the same way.  At the very least it has the potential to simplify
> > administration while the other method has more than the potential to
> > complicate it.  You're also re-using the same code paths which is good
> > for security, not to mention efficiency.
> > 
> > Does this answer your questions sufficiently?
> > 
> > Eliot
> > 
> 
> _______________________________________________
> 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: Keith McCloghrie <[email-masked]>
Date: Thu, 18 Aug 2005 08:22:36 -0700 (PDT)

Bert,

> For the example you cite, I wonder
> - SNMPv3 over UDP stays as a mandatory transport I would think
>   (We say so in the SNMP specs) 
> - The coldStart to me seems not sensitive from a security point
>   of view (or so I think, others may think different), 
>   so I do not see why it could not be sent unauthenticated
>   (i.e. noAuthNoPriv) via a TRAPv2 on UDP.
> - And then after that, the manager can setup a connection to the
>   agent, no?

I gave coldStart as an example, but the issue is not specific to
coldStart -- the same situation could occur for many different
types of notification.  If a TCP-based transport mapping has the
limitation that coldStart and many other types can not be sent
securely unless a manager already has a connection open to the
agent, then I would suggest the WG should change its mind and
reinstate UDP-based transports.
 
> I am not saying that a call-home (as I now better understand what 
> it means) is not a usefull feature, I am saying that it seems 
> to add extra requirements or an extra problem that this WG was
> not intended to solve. And we have (had at least) trouble enough
> to focus on the things we ARE supposed to work on.

I disagree that it is "extra".  I suggest that the WG is only now
coming to grips with the issues inherent in using a secure TCP-based
transport mapping for the capabilities which have been part of SNMP
since RFC 1157.

Keith.

> > From: Keith McCloghrie [mailto:[email-masked]]
> > Sent: Thursday, August 18, 2005 15:49
> > To: [email-masked]
> > Cc: [email-masked]; [email-masked]; [email-masked]

---

From: "David B Harrington" <[email-masked]>
Date: Thu, 18 Aug 2005 11:48:10 -0400

Hi,

I have always thought that for certain purposes, we need to retain
USM. This may be one of those purposes.

Assuming a model where the notification sender needs to request an NMS
to "call-home", the N-S will need to be configured with the address of
the NMS. Configuring a shared secret, especially if the target is a
fixed application rather than a user, would not seem to be a major
problem. The TCP security resolves the multiple, dynamic user problem
(which I think is still going to be highly limited since only IT
personnel are likely to have SNMP rights anyway. So USM is not an
onerous approach to solving this problem.

That said, Elliot and I have already talked about him contributing
some text for the SSH document, possibly including a discussion of
call-home functionality. So I'll add the call-home text to the SSH
document, in the section on notifications or in an appendix, have it
reviewed by the other editors for wordsmithing, and publish it to the
WG for consideration and discussion with the rest of the SSH solution.

Is that a fair approach for everybody?

David Harrington
[email-masked]

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Keith McCloghrie
> Sent: Thursday, August 18, 2005 11:23 AM
> To: "Wijnen, Bert (Bert)"
> Cc: [email-masked]; [email-masked]

---

From: Keith McCloghrie <[email-masked]>
Date: Thu, 25 Aug 2005 11:27:05 -0700 (PDT)

Take the example I gave where (TMSM, joe) uses XXX-ACM, and (USM, fred)
uses VACM.  Then, if the authentication information contained in, say,
a RADIUS response can be mapped to (TMSM, joe), then the authorization
information in that same RADIUS response can be mapped to XXX-ACM.
Similarly, if the authentication information contained in some other
kind of response can be mapped to (USM, fred), then that response's
authorization information can be mapped to VACM.

Keith. 

PS. Please forgive me for discussing proposals which are outside the
scope of this WG's charter.

> Hi Keith,
> 
> Thank you for your comments. I agree with them.
> 
> I hope I wasn't too subtle. I agree that populating a vacm table from
> a security model is **broken** and do not believe it should be done
> that way. Some proposals seem to argue for that solution, and while it
> is one way to achieve the mapping, it has serious architectural
> problems to do it that way. 
> 
> Thank you for reinforcing this.
> 
> If populating the vacm table is done as part of VACM, where does the
> information come from? How do you maintain the cryptographic binding
> between the authentication and the authorization? RFC 3411 provides
> the model/level/name triplet in the ASIs to provide such binding. But
> how does one use that from within VACM to access e.g. RADIUS
> attributes for authorization?
> 
> dbh 
> 
> > Sent: Thursday, August 25, 2005 8:55 AM
> > To: [email-masked]
> > Subject: Re: [Isms] Multiple access control models
> > 
> > Dave,
> > 
> > Forwarded message:
> > > From: "David B Harrington" <[email-masked]>
> > > To: <[email-masked]>
> > > Date: Wed, 24 Aug 2005 17:14:53 -0400
> > > Subject: [Isms] Multiple access control models
> > > 
> > > Hi,
> > > 
> > > I think #1 can be achieved by describing in an ISMS 
> > security model how
> > > the vacmSecurityToGroupTable gets populated by additional 
> > sources, and
> > > augmenting the VACM MIB module with source information; 
> > this info can
> > > also provide the information necessary to delete 
> > session-specific rows
> > > when the session closes. 
> > > 
> > > There are two major architectural problems with this 
> > approach - it is
> > > totally dependent on VACM being the only ACM model the solution
> will
> > > work with, and any security model that utilizes AAA to populate
> the
> > > table creates dependencies between specific models in the security
> > > subsystem and specific models in the AC subsystem. That is 
> > contrary to
> > > the RFC3411 architectural philosophy.
> > 
> > Note that the vacmSecurityToGroupTable is defined in RFC 3415
> > (i.e., in VACM, not in *any* security model) and is not referenced
> in
> > any other SNMPv3 RFC.  Thus, "describing in an ISMS security model
> how
> > the vacmSecurityToGroupTable gets populated by additional sources"
> is
> > obviously broken.
> > 
> > If #1 is achieved by a solution which has problems, then by 
> > definition,
> > that solution will have problems.  But that's the solution's 
> > fault, not
> > #1's fault.
> > 
> > If instead, "how the vacmSecurityToGroupTable gets populated by
> > additional sources" is defined as part of VACM, then there are no
> such
> > problems.
> > 
> > Also, I think the way in which multiple access control models can
> > co-exist is for the particular Access Model (used to resolve an
> > "isAccessAllowed" test) to be determined by the securityName, i.e.,
> > the Access Control Model is determined by 
> > (securityModel,securityName).
> > So, for example:
> > 
> > -- today:           (USM, fred) uses VACM 
> >           and       (USM, joe) uses VACM 
> > -- add in future:   (TMSM, fred) uses VACM
> >           and       (TMSM, joe) uses the XXX Access Control Model
> > 
> > where the XXX Access Control Model would have its own MIB table
> > corresponding to vacmSecurityToGroupTable, and each
> > (securityModel,securityName) would either have a row in
> > vacmSecurityToGroupTable or in XXX's corresponding table, not in
> both.
> > 
> > keith.
> > 
>