Subject: Re: ISMS working group and charter problems

From: Keith McCloghrie <[email-masked]>
Date: Thu, 8 Sep 2005 08:20:30 -0700 (PDT)

> > BTW, nothing about your note explains to me why you think that this 
> > mechanism should be defined in a Security area WG that is working on a 
> > completely separable problem.

The intent of ISMS is for SNMP to share common security infrastructure,
and in particular, common security infrastructures which are
session-based.  So, ISMS has decided that "session-based security" is
needed, which is an architectural departure from the "datagram-based
security" previously specified by the Net Mgmt Area (to see why, see **
below.)

Therefore, I suggest the problem is only *partially* separable.
Call-Home involves two issues:  1) the passing through
Firewalls/whatever issue which is completely separable, and 2) the
session v. datagram issue which is not separable.  Specifically, the
non-separable part is about who sets up the session, and what types of
messages can be sent on a session which was setup by a device
calling-home.

> >                              If you really think that defining call 
> > home for SNMP is something that the IETF should do, I would encourage 
> > you to get together with Eliot and request a BOF in the OPS area.
> 
> That's because I haven't formed an opinion on it. My main point
> is that this doesn't seem to me to be any sort of wildly divergent
> architectural proposition, at least on the front of who "initiates"
> a connection.  As Harald pointed out, I really can't see how you'd
> prevent some industrious developers from using SNMP in this way
> regardless of how the working group is chartered, and from that
> standpoint it might be better to get ahead of the ball on it if
> it were inevitable, and it does seem to have a fair number of
> security considerations.

Exactly.

My concerns with the charter are:

1. that if the charter declares Call-Home as out-of-scope, then there
will be technical/architectural issues which are relevant but cannot
be discussed because they are out-of-scope, and

2. consequently, the decisions made might well end up such that they
cannot even be extended later to support Call-Home.

3. and if so, nobody will want to define (at a later date) yet another
SNMP Security Model even if that is the only way to support Call-Home.

Keith.

** In "session-based security", only one SNMP user can use the session
at a time.  In contrast, the current SNMP architecture assumes
"datagram-based security", in which security is carried in every SNMP
message independent of any session/connection.  Consider that RFC 3430
(SNMP-over-TCP) says:

   It is RECOMMENDED that implementors consider the security features as
   provided by the SNMPv3 framework in order to provide SNMP security.
   Specifically, the use of the User-based Security Model STD 62, RFC
   3414 [10] and the View-based Access Control Model STD 62, RFC 3415
   [11] is RECOMMENDED.

In USM, each message has its own security, e.g., two different SNMP
users can be using the same TCP connection at the same time.  ISMS's
proposal for SNMP-over-SSH will require all SNMP messages on one SSH
session to be for the same SNMP user.

Also remember that the security parameters of a USM message are
dependent on the PDU type contained in the message (specificially,
whether the sender or receiver is "authoritative").  So, "what types
of messages can be sent on a session which was setup by a device
calling-home" is both a security and an architectural issue.

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

---

From: Dave Crocker <[email-masked]>
Date: Thu, 08 Sep 2005 08:40:39 -0700

> My concerns with the charter are:

will it help to have the public discussion include a candidate revision to the 
charter, so that folks can see concretely what will be changed?

-- 
 
   d/

  Dave Crocker
  Brandenburg InternetWorking
  +1.408.246.8253
  dcrocker  a t ...
  WE'VE MOVED to:  www.bbiw.net

---

From: "Tom Petch" <[email-masked]>
Date: Thu, 8 Sep 2005 19:39:04 +0200

<inline>
Tom Petch

----- Original Message -----
From: "Keith McCloghrie" <[email-masked]>
To: "Michael Thomas" <[email-masked]>
Cc: "Margaret Wasserman" <[email-masked]>; "Harald Tveit Alvestrand"
<[email-masked]>; <[email-masked]>; "Eliot Lear" <[email-masked]>;
"IETF Discussion" <[email-masked]>
Sent: Thursday, September 08, 2005 5:20 PM
Subject: Re: ISMS working group and charter problems

> SNMP Security Model even if that is the only way to support Call-Home.

I think that there is subtext that is missing here.

Call Home was declared out of scope, more or less, for isms before the decision
to use SSH was taken (the suggestion was made on the isms list to set up a BOF
in the Operations Area to explore Call Home).  The significance is that SSH is
not perceived as a good fit for Call Home, whereas a different protocol, seen as
less suitable in other regards, might be.  So if the community at large comes to
regard Call Home as a mandatory requirement, then that would be construed as
saying that SSH is the wrong protocol (which may be what this discussion is
really about:-).

<snip>

---

From: Sam Hartman <[email-masked]>
Date: Thu, 08 Sep 2005 15:30:28 -0400

>>>>> "Tom" == Tom Petch <[email-masked]> writes:

    Tom> I think that there is subtext that is missing here.

    Tom> Call Home was declared out of scope, more or less, for isms
    Tom> before the decision to use SSH was taken (the suggestion was
    Tom> made on the isms list to set up a BOF in the Operations Area
    Tom> to explore Call Home).  

I'm not sure this is accurate, but I don't think it matters.

    Tom> The significance is that SSH is not
    Tom> perceived as a good fit for Call Home, whereas a different
    Tom> protocol, seen as less suitable in other regards, might be.
    Tom> So if the community at large comes to regard Call Home as a
    Tom> mandatory requirement, then that would be construed as saying
    Tom> that SSH is the wrong protocol (which may be what this
    Tom> discussion is really about:-).

I don't believe that it is true that ssh is not perceived as a good
fit for call home.  I think the strongest statement I've seen in that
regard is that ssh is not the solution netconf chose for call home, so
we might end up with incompatible solutions if ISMS chooses a
different solution than netconf.

Note that the mandatory to implement solution for netconf is based on
ssh and does not support call home.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 8 Sep 2005 22:05:47 +0200

> ssh and does not support call home.

1) I see lots of people using tools like MIB browsers, snmp command line
   tools called from fancy scripts, monitoring packages such as cacti
   and nagios (these were even used on the IETF network in Paris if I
   recall correctly) and all these packages share the feature that the
   "manager" does not have a fixed transport address but takes the
   initiative to talk to an "agent" when there is need to do so. In
   other words, all these existing and deployed applications simply
   won't work with call home easily since they would require to
   implement some rather magic logic to dispatch SNMP traffic via
   a locally centralized connection manager.

2) It is important to talk about ssh and to not reduce the problem to
   just TCP. As far as I understand ssh, authentication is not
   symmetric because ssh has a clear buildin client/server role
   (servers authenticated via host keys while clients are 
   authenticated via passwords or publickey mechanisms).
   So in the context of ssh, it does have quite some impact who
   establishes the transport connection. (Unless there is a "turn"
   feature in _ssh_. I am not aware of such a mechanism, but I am
   happy to learn.)

3) For those not following ISMS closely, it might be useful to know
   that originally was another proposal (EUSM) which tried to build on
   USM messages and tried to integrate USM with AAA infrastructures.
   This approach did have some rough support but did melt down because 
   of some inappropriate use of EAP. (I can't explain the details since
   I never really understood the _technical_ concern.) Once EUSM was
   off the table, the WG converged to SSH for a very simple reason:
   SSH is already on many routers/bridges/hosts and you find it even
   on power strips these days. Netconf also requires SSH as the
   mandatory to implement transport. Hence, using SSH as a unifying
   mechanism to securely access the various management interfaces
   on a box has some promises wrt. ease of deployment.

I agree with those who said that CH is an architectural change and I
have yet to see a concrete proposal how CH via ssh can be achieved.

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany

---

From: Sam Hartman <[email-masked]>
Date: Thu, 08 Sep 2005 16:40:55 -0400

>>>>> "Juergen" == Juergen Schoenwaelder <[email-masked]> writes:

    Juergen> 2) It is important to talk about ssh and to not reduce the problem to
    Juergen>    just TCP. As far as I understand ssh, authentication is not
    Juergen>    symmetric because ssh has a clear buildin client/server role
    Juergen>    (servers authenticated via host keys while clients are 
    Juergen>    authenticated via passwords or publickey mechanisms).
    Juergen>    So in the context of ssh, it does have quite some impact who
    Juergen>    establishes the transport connection. (Unless there is a "turn"
    Juergen>    feature in _ssh_. I am not aware of such a mechanism, but I am
    Juergen>    happy to learn.)

Authentication is sometimes symmetric; it is not in the case of
passwords.  For authentication methods like public key or GSS, it is reasonably symmetric.

--Sam

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 8 Sep 2005 23:15:08 +0200

> passwords.  For authentication methods like public key or GSS, it is

The networking boxes I have access to all use password authentication
because they like to stick the password into RADIUS/TACACS...

I am not sure what "reasonably symmetric" means. Who authenticates
whom and in which way if the server establishes a connection to the
client with public key or GSS?

/js

---

From: Keith McCloghrie <[email-masked]>
Date: Thu, 8 Sep 2005 14:28:39 -0700 (PDT)

Hi Juergen,

>    just TCP. ...

This is very true.  Your SNMP-over-TCP (RFC 3430) is still based on
each message carrying all of its own security.  In contrast, the not
yet complete proposal for SNMP-over-SSH is different because each SNMP
message is going to inherent security properties from the SSH session.
So, for example, if requests are allowed to be sent in both directions
across the same session, then a request sent in one direction across a
session are sent by the same user as a request sent in the other
direction over the same session.

> have yet to see a concrete proposal how CH via ssh can be achieved.
 
As I see it, to prevent SNMP-over-SSH from being the same architectural
change, constraints need to be imposed on which SNMP messages can be
sent in which direction on a SSH session.  The decision on whether to
have such constraints is within the proposed scope of the WG.  Thus,
that architectural change is within the scope of the WG, and therefore
requiring the same architectural change is not a valid reason to rule
Call Home out-of-scope.

Keith.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 08 Sep 2005 17:36:02 -0400

> client with public key or GSS?

SSH servers don't establish connections to SSH clients.
An SSH server is authenticated as part of key exchange.
An SSH client is authenticated as part of user authentication.

In some cases, the same kinds of credentials can be used in either 
direction.  For example, an RSA key pair can be used either to authenticate 
a host (as a host key) or to authenticate a user (via the publickey 
userauth method).  Similarly, if the Kerberos GSSAPI mechanism is used, the 
same Kerberos principal can be used in either a client or a server role, 
provided the Kerberos infrastructure is configured to allow such usage for 
that principal.

-- Jeffrey T. Hutzelman (N3NHS) <[email-masked]>
   Sr. Research Systems Programmer
   School of Computer Science - Research Computing Facility
   Carnegie Mellon University - Pittsburgh, PA

---

From: Eliot Lear <[email-masked]>
Date: Mon, 12 Sep 2005 08:01:52 +0200

Tom,

> in the Operations Area to explore Call Home).\

CH was declared out of scope after IETF63, which is when the decision to
use SSH was made.

Eliott

---

From: Eliot Lear <[email-masked]>
Date: Mon, 12 Sep 2005 09:24:51 +0200

Juergen,

>    a locally centralized connection manager.

Indeed I do not advocate deleting the existing model where the manager
contacts the agent.  But the tools you mention will almost assuredly
need to be modified no matter the outcome of this debate, because they
will need to incorporate SSH.

> 
> 2) [Consider SSH, and not just TCP aspects]

I agree, and Keith McCloghrie has answered this question better than I
could.

>    on a box has some promises wrt. ease of deployment.

This jives with my understanding of the group's logic.

> have yet to see a concrete proposal how CH via ssh can be achieved.

Funny you should mention this.  I've mentioned several approaches on
this list and others several times, while the group converged on using
SSH without having a single draft available at the time.  It was indeed
impressive that the group had gone from (at least) four separate viable
drafts down to zero by the end of IETF-63.

Eliot

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 12 Sep 2005 10:26:46 +0200

> will need to incorporate SSH.

Sure, tools need to be modified, no doubt about that.  I just wanted
to point out with my message that for a certain percentage of the
tools out there, CH will be cumbersome to implement and use since
these tools tend to come and go and it is rather unlikely that they
will go through a local centralized connection manager which can
provide a static transport endpoint to call home. Since in the
environments I am most familiar with these tools heavily dominate, I
once wrote that CH is OK for me as long as we can make it work without
making the traditional model more difficult.

> drafts down to zero by the end of IETF-63.

As I said during the meeting: I do not subscribe to this "no single
draft" argument. Some people have done a fair amount of work to think
about the architectural extensions needed for transport mapping
security which you happily refer to in the BEEP document. The option
of SSH is mentioned in the architectural document, even though we did
not went to the glory details of all the options that were on the
table back then (TLS, SASL, DTLS, SSH). In fact, I fail to see how you
get the conclusion that we went down to zero drafts by the end of
IETF-63.

/js

---

From: Eliot Lear <[email-masked]>
Date: Mon, 12 Sep 2005 12:03:49 +0200

Just to clarify:
> The option

The four I had in mind were TLSM, EUSM, SBSM, and SNMP/BEEP.  Prior to
the meeting the WG had ruled out the first three and during the meeting
the fourth was also shelved, leaving none.

It is true you mentioned SSH in your draft but that was far from a
specification.

This is now history as I see it.

Eliot

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 12 Sep 2005 15:04:27 +0200

> the fourth was also shelved, leaving none.

This does not match my recollection. My understanding was that the WG
decided prior to the IETF-63 that it will follow the transport mapping
security model (TMSM) approach, which was initially called "transport
layer security model" (TLSM). Under the discussion during the IETF-63
meeting were the selection of transport layer security protocols that
could be used, such as TLS, SSH, DTLS, and BEEP. This is inline with
what <draft-kaushik-isms-btsm-01> says:

   This document leverages the TMSM framework and describes the use of
   the BEEP for securing SNMPv3.  This specification describes BEEP
   Transport Mapping Security Model.

I don't think BEEP was even on the table when the discussions between
EUSM, SBSM and TMSM was made - at least it is not mentioned in the
evaluation document <draft-ietf-isms-proposal-comparison>.

/js

---

From: Eliot Lear <[email-masked]>
Date: Mon, 12 Sep 2005 16:05:10 +0200

Juergen Schoenwaelder wrote:

> layer security model" (TLSM).

Which is the architectural model extracted from TLSM.

> Under the discussion during the IETF-63

Juergen asked that it be presented at IETF-63, which is why I included it.

Eliot

---

From: Keith McCloghrie <[email-masked]>
Date: Mon, 12 Sep 2005 07:40:07 -0700 (PDT)

Margaret,

> None of this seems very material to the ISMS discussion, though...
> 
> Today SNMP (whether it is running over UDP or TCP) doesn't have the 
> call home feature.  Do you really think it is reasonable to tie the 
> addition of that feature to the definition of a new security 
> mechanism for the existing SNMP protocol?  If so, why?
 
Today's SNMP (whether it is running over UDP or TCP) has datagram-based
security (or no security).  What the ISMS WG is proposing to do is to
introduce session-based security.  The definition of session-based
security will need to decide how to tie the security in one direction
with the security in the other direction, and the factors involved in
such a tie include a subset of the requirements for Call Home.

> IMO, we need to try to do our work in manageable chunks in the right 
> groups/areas.  A security area working group working on a new 
> security mechanism for the existing SNMP model is one chunk.  Perhaps 
> an OPS area WG working on an optional SNMP call home mechanism is 
> another...?  I don't see how the level of change/disruption to the 
> vendor community is substantially affected by whether these two 
> separate mechanisms are defined in one IETF working group or two.
 
If there are going to be two WGs, then the split between them needs to
be non-overlapping.  With the split you propose, there is a common
subset of the two, and if the common subset is defined in different WGs,
they are likely to make incompatible decisions, i.e., the Call Home
won't be able to work over session-based security.

Keith.

---

From: Keith McCloghrie <[email-masked]>
Date: Tue, 13 Sep 2005 10:00:06 -0700 (PDT)

Dave,

I support the "alternative" you are recommending.

Thanks,
Keith.

> As primary editor of the SSH draft (SSHSM), I spoke with Eliot last
> week. I agree that it is difficult for him to develop a reasonable
> proposal that piggybacks on the SSH draft, because the SSH draft is so
> incomplete.
> 
> I am not convinced that SNMP needs to add a new call-home (CH)
> functionality, nor that this feature is needed in SNMP now, but there
> is a danger that CH might never be possible if we don't consider its
> impact on the SSHSM model before SSHSM is cast in stone. If it
> complicates the SSHSM model, I would prefer to not include it; a new
> model could be developed to replace or supplement the SSHSM model if
> demand increases for this functionality.
> 
> I recommended to Eliot that he contribute some text for the SSH
> document, describing the CH functionality and proposed elements of
> procedure, that I could include as an appendix to the SSHSM document
> so the WG could review his proposal, and then the WG could decide
> whether it should remain as an appendix, be incorporated into the SSH
> document, be split out as a separate document, or be abandoned
> altogether. I felt this was a reasonable alternative to making the
> decision whether CH is or is not in scope at this time. He has not yet
> had a chance to develop the text and send it to me. 
> 
> David Harrington
> [email-masked]
> 
> 
> > -----Original Message-----
> > From: [email-masked] 
> > [mailto:[email-masked]] On Behalf Of Eliot Lear
> > Sent: Monday, September 12, 2005 3:53 PM
> > To: Sam Hartman
> > Cc: IETF Discussion; [email-masked]; [email-masked]
> > Subject: [Isms] ISMS charter broken- onus should be on WG to fix it
> > 
> > Sam,
> > 
> > I believe the approach you have proposed is quite simply wrong.  As
> an
> > AD you're supposed to provide technical oversight and not 
> > simply hold a
> > popularity contest.  If you have technical questions or wish to
> > challenge me on a technical point, I think that's fair game.
> > 
> > As I've written, the path we are headed down technically will not
> work
> > in the face of firewalls and NATs, and nobody has refuted this.
> > 
> > Furthermore you've heard from a reasonably large customer (Boeing)
> as
> > well as your predecessor on the prevalence of such middle boxes that
> > demonstrates the complexity of today's environment and the 
> > need for this
> > sort of functionality as part of the solution.
> > 
> > You've heard from an author of SNMP that the major 
> > architectural change
> > is the use of session based security and NOT CH, the same from the
> > former O&M AD and IETF chair.  You've heard from a service provider
> as
> > well as numerous members of the community who see the problem.
> > 
> > You may or may not have yet heard from other standards bodies 
> > but if you
> > were to delay it is quite possible they will chime in since one was
> > specifically interested in this sort of function.
> > 
> > The amount of changes required to support CH cannot fully be 
> > ascertained
> > until more of the the [Todo]s are filled in with Dave's draft, but I
> > don't imagine the work would be much more than:
> > 
> >  - specifying how to initiate the connection and if necessary turn
> it
> >  - the identity used for requests received from command 
> > generators that
> >    did not initiate the connection along with potential
> prepopulating
> >    of various tables
> >  - an appendix of how the SNMP-TARGET-MIB would be populated
> >  - a discussion on when to initiate connections and what to do when
> >    they fail (mind you this is needed anyway regardless of CH)
> >  - security considerations involving firewalls, blocking, etc.
> >  - possibly one additional table describing the state of SSH peer
> >    connectivity (which probably wouldn't be bad to have anyway).
> > 
> > Decide for yourself if you think this is a substantial amount of
> text,
> > but I won't leave it to your imagination for long.  I will 
> > attempt this
> > week to post a derivative of the draft that Dave is working on to
> give
> > people an idea of what the changes would be.
> > 
> > Again it's difficult to diff an incomplete specification.
> > 
> > Eliot
> > 
> > >>>>>>>>>>> "Eliot" == Eliot Lear <[email-masked]> writes:
> > > 
> > > 
> > >     Eliot> I request an extension of the deadline for comments to
> > >     Eliot> September 21st on the following basis:
> > > 
> > >     Eliot>  - the period of comment has been less than a week, far
> > >     Eliot> shorter than the normal period of IETF-wide review.  -
> of
> > >     Eliot> the time allotted, the principle instigator of 
> > this review
> > >     Eliot> has been absent from debate for five days due to prior
> > >     Eliot> commitments.  That was me.
> > > 
> > > Hi, Eliot.  I have not made any determination as yet about whether
> I
> > > will pull ISMS from the Thursday telechat and am unlikely to make
> a
> > > final determination until the time of that telechat.
> > > 
> > > 
> > > When I originally ruled call home out of scope I gave you some
> > > suggestions for how to approach things from a process 
> > standpoint.  In
> > > evaluating your request I will consider how much progress has been
> > > made on these issues so far and on whether it is likely 
> > that you could
> > > make additional progress on these issues by September 21.
> > > 
> > > Let us go back and consider my original advice to you:
> > > 
> > >   When the charter is sent to me for IESG review, ask me to 
> > send it out
> > >   for external review (IETF wide) rather than just 
> > approving it; I will
> > >   honor such a request.  You will need a proposal ready to 
> > present to
> > >   the community when the charter comes out for review.  The
> proposal
> > >   should include proposed modifications to the charter to 
> > make call home
> > >   in scope.  In addition you probably want to answer the following
> > >   concerns:
> > > 
> > >   * People believe that architectural changes to SNMP 
> > should happen in
> > >     the management not security area.  Either convince them 
> > that this is
> > >     OK in the security area, propose moving the working group, or
> > >     propose splitting the work appropriately.
> > > 
> > >   * Address the concerns about the lack of MIBs and other 
> > facilities for
> > >     managing call home.  Have a proposal ready for what is 
> > involved in
> > >     doing the work.
> > > 
> > > 
> > >   * Understand concerns Bert is likely to raise and respond to
> them.
> > > 
> > > 
> > > 
> > > so, here are some specific questions related to our progress to
> date
> > > on these items.  Answering these questions will help me determine
> > > whether extending the review period to September 21 is likely to
> be
> > > productive.
> > > 
> > > 1) Have you proposed a specific set of charter changes?  Who has
> > >    supported these charter changes?
> > > 
> > > 2) How have you addressed the specific concerns about the 
> > location of
> > >    the work ?  Who has agreed with your proposed resolution?
> > > 
> > > 3) Is there a consensus emerging that CH needs to be solved 
> > as part of
> > >     ISMS?  This is the part where additional time is most likely
> to
> > >     help you, but I think it fair to ask who has supported
> blocking
> > >     ISMS on CH so far.  Note that people who support CH but who
> > >     believe it could be done in a separate working group or who
> have
> > >     not expressed an opinion do not count.  They may well count
> for
> > >     justifying support for a CH BOF or for justification of a
> > >     publication request for an individual submission adding 
> > CH to the
> > >     SNMP architecture.
> > > 
> > > 
> > > 4) What response have you given to concerns about whether the
> > >    architectural extensions for CH are sufficiently well 
> > defined?  Who
> > >    has supported this proposal?
> > > 
> > > 
> > > 
> > > 5) How are your discussions going with Bert to resolve his
> concerns?
> > >     What about other key members of the management 
> > community who have
> > >     expressed concerns?
> > > 
> > > 
> > > 
> > > Here's how I'm going to make a decision.  I believe that in order
> to
> > > get a change to the SNMP charter it is necessary to make
> significant
> > > progress on all of these issues.  I'm going to evaluate your
> answers
> > > and consider whether I think the progress to date makes it 
> > likely that
> > > you will have sufficient support for a new charter by September 21
> > > without significant opposition.  In other words whether the 
> > community
> > > and IESG can agree to the new charter by the end of the 
> > review period.
> > > If the progress to date makes it likely that we're headed in that
> > > direction, I'll grant the request.  Otherwise I will ask the IESG
> to
> > > approve the charter on Thursday.
> > > 
> > > 
> > > There's an internal issue that may well prevent the charter 
> > from being
> > > announced before the 21st even if no formal extension is granted.
> > > 
> > > 
> > > --Sam
> > > 
> > 
> > 
> > 
> > Isms mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/isms
> > 
> 
> 
> 
> Isms mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/isms
>