Subject: [Isms] design decisions in SBSM

From: Wes Hardaker <[email-masked]>
Date: Wed, 02 Mar 2005 22:22:23 -0800

I thought I'd write down a quick history of how SBSM came about and
the trade offs that were made when designing it.  Many of the issues
that are being discussed today were long ago thought about when
putting together SBSM and although the working group may very well
chose a different path at various decision points, I thought it would
be helpful to at least outline how and why the SBSM draft came about.

Additionally there has been a lot of discussion on the mailing list
lately (yay) but since I was away in Japan at Apricot for a week I'm
trying to catch up and I hope this message will summarize my views on
a lot of the topics that have been discussed lately.

The first realization, and the primary focus of the working group,
was simply that a fair number of people weren't using SNMPv3 because
it required them to use a different security infrastructure (USM
accounts) than they had in their current deployed systems.  This is
long known, and is why ISMS was created in the first place.

A much more subtle second point is that I believed (and I think I can
safely say David believed) that if SNMP ever required another system
they didn't have or required modifications to existing systems that it
would result in less use of SNMP.  As I've mentioned recently multiple
times, SNMP is always a "secondary service" to the rest of the
services on the box.  SNMP is a service that you turn on out of
necessity in order to help manage the other services.  This isn't a
bad thing, it's simply why SNMP exists.  It exists to help support
other services.  But that means that if there is any barrier to being
able to use SNMP, it'll make it harder for operators to turn on since
they've already declared themselves "too busy" to manage anything
else.  Thus the 99% case transformation path, IMHO, from a box out of
the box:

     A                  B               C           D             E

  Open package      Set up            deploy     Set up         Turn on
  Get the box    -> Features it    -> on      -> management  -> SNMP
                    was bought for    network    (SNMP)

Certainly sometimes multiple parts of these steps may be combined.
Especially when deploying new boxes into an existing network, it's
likely that an existing configuration set that may combine steps B and
D will be done at once.  However, for new boxes with new features or
new networks, I (we) believed that B would always be done first.

What does B above entail?  It requires a number of things.

  B.1   Creation of login accounts and/or changing of default
        administrator passwords.
  B.2   Creating other security services so that operators can log in
        remotely via telnet/ssh/whatever.  This may require creating a
        host key, installing user public keys, creating local accounts,
        setting up radius, etc...
  B.3   Setting up configuration for the services they bought the box
        for.  This could be router configuration, firewall rules, QoS
        handling, ...  IE, the purpose of the box.  This could be done
        either at a console or over the network using the security
        services set in B.2.  If done over the console, B.2 may not be
        needed as what was done in B.1 was likely enough.

Regardless, I believe that these steps would always result in a box
with pre-existing security infrastructure.  Requiring later than in
step D above that SNMPv3 required additional security setup would mean
a delay in the user's desire to do so.  Fine-tuning firewall rules
would be much more important than setting up a new security
infrastructure.

With SNMPv3/USM as is, D was required to be:

  D.1  set up USM names and keys/pass-phrases
  D.2  set up VACM access rights

So, what needed to be done to remove either of these steps to increase
the speed at which a user could get to point E would mean simply not
doing them.

To remove D.1 it would require relying completely on the services that
had been set up in B.1 and B.2 above.  Requiring any other
infrastructure aside from what was already available meant that you
couldn't completely remove D.1.  You could potentially reduce the
impact, but the step would always be there unless you were totally
reliant on other services.  My (our) goal was to eliminate D.1
entirely, which meant not just making USM deployment easier but
eliminating it entirely from scope.  I'll come back to this again in a
minute as this was a major point behind many of the decisions that
were later made.

Another side note about removing the D.1 requirement:  It means that
you must at all times be able to fallback to whatever existing
fallback mechanism was available.  IE, if you offered radius but yet
had to fall back to USM in times of trouble that means you haven't
eliminated the D.1 step in setting up a network.  Even if you were
falling back to a single root-equivalent USM user, it means that user
had to be set up and maintained.  It is much more important, IMHO, to
fall back to other security mechanisms that operators are already
planning on relying on when network troubles are encountered.  EG, if
they're using radius generally but plan on falling back to local
accounts or SSH in times of trouble, then to entirely eliminate D.1
the resulting solution to the problem must be able to handle this.

D.2 (VACM setup) is impossible to remove entirely, as you don't want
to grant access rights out of the box of course.  David and I
discussed this at length for a long time.  He argued that we should do
something to provision VACM records directly in the resulting
solution.  But I argued that we shouldn't tie them together both
because a coupling was not needed, was not potentially wanted for all
environments and would, worse,would delay the authentication half of
the solution (the removal of D.1) from deployment since it would
increase the work to be done.  We both agreed, however, that something
should be done in the future.  (By the way, I think what was done in
EUSM is a wonderful solution to the D.2 reduction problem.  My only
caveat is that it requires a central authorization infrastructure to
do that distribution.  Many will see this as a plus, however.).

So given those requirements being the most important, the next step
was to decide what authentication mechanisms were important.  Dave and
I had many discussions about that and never did come to a great
agreement on which ones should be worked on first, etc.  The WG
discussions seem to be proceeding on similar lines.  The ones that we
considered fairly critical:

  local accounts
  ssh (the survey results weren't around at the time; this was mostly
       because we knew it was fairly popular and because netconf was
       going to mandate it as a transport so it seemed very wise to
       use it).
  radius
  x.509
  ...

Pretty much the list mirrored the list that we saw in the survey
results.  The fill-in-the-blanks from the survey showed a few others
we forgot about, like LDAP.  The problem with the list, of course, is
that if you really want to accomplish D.1 from above (the complete
reliance on other authentication infrastructures) it is very difficult
to accommodate the entire list.  The differences in operation between
the two 3 alone are hugely different (local-accounts, ssh-keys,
radius).

[aside: another requirement not discussed much to date is that there
was a desire to have the result to be transport independent.  It
should be usable over UDP, TCP, AAL5, ...  Our clients make use of
multiple transport types and limiting the security options they could
pick from to a single or small set of transports seemed counter to
their desires]

So, when thinking about the best way to accommodate everything a
number of things were considered.  Some of the extensible mechanisms
were considered (eg, EAP, SASL) but the issue with these were that
none of them supported all of the above mechanisms.  At the time, EAP
mechanisms existed for doing local accounts, eg, but were not
documented as such and people were told in the hallway that you could
use OTP or GTC to accomplish that (I've now heard both from different
people; I thought OTP was the only one that would work but I'd have to
go re-read to trust either at this point.  It's been too long).
However, EAP looked like the best solution to accommodate as many as
possible using an existing protocol.

However, I never wanted to run it in parallel with SNMPv3.  IE, when I
was considering EAP I was only thinking about it potentially tunneled
through the security parameters within the SNMPv3 packet.  But at that
point, you still need to deal with message protection for it since EAP
itself doesn't provide for that (PEAP and EAP-TLS do and would have to
be used).  It would also require only key-generating mechanisms, of
which few were in existence at the time.  I never wanted to run it
along side SNMPv3 simply because the architectural ramifications of
dealing with that within an OS get to be very complex when trying to
deal with portability, interaction with multiple software components,
etc.  I'll explain this in a separate message though as it's an entire
topic in itself.  However, EAP would likely never accommodate SSH
authentication which was a large problem since both other NM schemes
(netconf) were going to require it and it was very popular with
operators.  Thus in order to achieve complete reliance on existing
deployed infrastructures, SSH support capability became a must.

The other decision that occurred at this time and is related to the
last paragraph is that of if nothing else was available that could
make use of as much of the existing infrastructures as possible, the
choice was to go with something like EAP and hope that in the future
other EAP authentication mechanisms would begin to support the other
popular security mechanisms.  It was more important, in my mind at
least, that we achieve deployment sooner rather than later and knowing
the speed at which multiple IETF working groups have been known to
manage to co-produce interacting frameworks to achieve a common good
was, um, slow I decided it would be best to roll-our-own.  This, I
think, is the largest of the decisions that is different between my
thinking and the other proposals.  The reason behind it was solely to
accommodate as many existing infrastructures (without change) as soon
as possible.  It offered the greatest flexibility but at a significant
cost: that the protocol was going to have to be new.  In order to
mitigate that as much as possible, an existing known secure exchange
protocol was selected to base the work off of.  A number were
considered, but SIGMA looked to be the best for multiple reasons:

  1) It had been well analyzed
  2) It had been proven secure (at least no one has countered the
     proof yet).
  3) It offered identity protection, which wasn't a requirement but
     was a nice-to-have in my customers eyes.  (and the survey results
     confirmed this saying with 86/149 saying it would be useful,
     31/149 saying it wouldn't be, and 32/149 abstaining from
     answering).
  4) It had been used in other protocols, although often in the
     alternate mode.
  5) the number of packet exchanges to bring up a session was small

However, even if that protocol was followed it doesn't prove that the
specification following it would be clear of all potential mistakes.
Certainly you can follow something known to be secure but make a
mistake in applying it to your particular problem.  Additionally, the
order in which things happened in the new SBSM protocol (IE, the
elements of procedure ordering) that were unrelated to the usage of
the SIGMA exchange protocol would need to be analyzed.  These problems
were documented in the ID as problems with this particular solution
direction.  It is, by far, the biggest of the problems facing it.
We've always admitted to that.  To some, it may be an unacceptable
path based on this downside.  That is certainly a fair opinion, though
I don't agree with it because I think the benefits in this case far
exceed the problem space.

The payoff for this route is nice.  It is fairly easy to support
multiple authentication systems and thus the achievable deployment
would be potentially very large.  It also required no interactions
with other WGs, thus speeding the process along, and required no
modifications to existing security infrastructure and their related
protocols or software.  That was the gain we wanted most.

In order to reduce the potential problems with negotiation issues of
unsupported features, the options being negotiated were limited to the
bare minimum with no room for future feature creep (I expected
complaints about this actually, but never got any).  I was hoping to
keep the list shorter than it is, but SNMP requires a number of things
that aren't easily avoided (engineID exchange, for example, so the
default contextEngineID can be discovered).  The list functionally
boiled down to engineID, replay windowing, message authentication type
(SHA, MD5), message encryption type (DES, AES), key-exchange
parameters, identity type, identity and proof of identity.  There are
not a bizzilion options to pick from, but some negotiation had to be
done.  Compression was added later.

We did try and reuse existing mechanisms wherever possible.  EG, the
current USM HMAC forms (MD5 and SHA1) were reused as well as the
current encryption types and modes.  This was done to help limit the
footprint of the new system as much as possible.  (and anyone who had
implemented the DH experimental mib likely already had DH around as well).

The SBSM result is really divided into two parts.  The first part, is
described above, which is the creation of a session.  The second part
is how the real SNMP commands get sent over the session.

Once the setup of a session had been accomplished and was done
internally to the packet, the actual runtime information is very
limited.  It was reduced to the bare minimum as well and is quite
short: the session identifier, the message sequence number, the
authentication, encryption and compression parameters.  The message
authentication and encryption were treated as identically as possible
to how USM does things.  The USM format itself was not reused for
various reasons.

1) real replay support was desired since SNMP is being used more and
   more in complex manners (see midcom) and since operators never
   write scripts [at least that I've seen] that make use of the test
   and increment counters.  [I'm convinced that replay of things like
   TRAPs and INFORMs is a problem that merely hasn't reared its head
   yet.  Even GETs I think shouldn't be replayed, but that's another
   argument].

2) The session identifier needed to uniquely identify a session, not a
   user like the USM packet had in it.  The session identifier was
   needed to uniquely identify the session properties (keys, for example).

My point is writing most of the above is multi-fold:

1) Much of this is not well spelled out in the SBSM draft, and it
   should have been as it would have helped understanding.

2) If we're going to go forward with one solution, I wanted to make
   sure that the motivations behind why the choices that resulted in
   SBSM were made.  The primary and strongest goal was to enable
   end-users to deploy SNMP with security without modifying and by
   completely reusing their existing authentication infrastructure.
   This is the most paramount goal of ISMS.  Unfortunately, I think I
   might be in the minority in thinking that absolutely no changes to
   existing authentication infrastructures should be needed or that
   reusing existing security infrastructures is an absolute.

-- 
Wes Hardaker
Sparta

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

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 03 Mar 2005 06:11:16 -0800

Wes Hardaker <[email-masked]> wrote:
> cost: that the protocol was going to have to be new.

This is really a striking argument because basically it comes down to
"working with others is too much trouble". 

Yes, it certainly is easier to design something when you don't have
people looking over your shoulder, but at least in the security area, it
seems to take quite some time to get a new protocol right.  We're
*still* finding problems in IKEv2 and TLS, after 10 years. Is there
any reason to believe that the same situation won't obtain with SBSM?

>  In order to

Wes, every time you've mentioned SIGMA you've mentioned that it's
been proven secure. While this is certainly a nice to have,
it really buys you a lot less than one would imagine. In particular,
I strongly suspect that the proofs of security only hold when you're
NOT composing it with a whole bunch of arbitrary authentication
schemes with strengths that don't match the public key authentication
schemes that SIGMA is based on.

> would be potentially very large.

I'm extremely skeptical of this claim. I hear you saying that it's easy
to support multiple authentication systems but the current SBSM just has
stub markers for where these authentication systems would in principle
go if you were going to put them in. Both IKE and TLS have exactly the
same kind of cutouts and yet every time we go to add a new form of
authentication (by this I don't mean some new public key algorithm but
rather something fundamentally new, like passwords) it takes years
because the security properties of the composed protocol are not
necessarily the same as the security properties of the individual
protocols.

I would also note that it's a little surprising that you claim
that supporting multiple authentication mechanisms is a feature
of designing a new protocol and yet your solution for supporting
a number of them seems to be to punt the problem off to EAP:

   Although not defined yet, the EAP identification mechanism will      
   support a number of important identification concepts missing from   
   the previous mechanisms, such as Generic Token Card, One Time
   Password, and two factor authentication support.

Doesn't this argue for just using EAP?

The major argument you're making for designing a new protocol is
time to market. I think you're dramatically underestimating the
difficulty of getting a security protocol from -03 stage to
finished stage. In my opinion, at this stage in the game it
would be far easier to simply use IKE and add whatever
authentication mechanisms it lacks that you think you need. This
would have the advantage of giving you a protocol that actually
does something and is standardized today and would let you
leverage work that is *already* going on to add additional
authentication mechanisms to IKE (see, for instance,
draft-eronen-ipsec-ikev2-eap-auth).

-Ekr

---

From: Robert Story <[email-masked]>
Date: Thu, 3 Mar 2005 09:20:18 -0500

On Thu, 03 Mar 2005 06:11:16 -0800 Eric wrote:
ER> Wes Hardaker <[email-masked]> wrote:
ER> > It was more important, in my mind at
ER> > least, that we achieve deployment sooner rather than later and knowing
ER> > the speed at which multiple IETF working groups have been known to
ER> > manage to co-produce interacting frameworks to achieve a common good
ER> > was, um, slow I decided it would be best to roll-our-own.
ER> 
ER> This is really a striking argument because basically it comes down to
ER> "working with others is too much trouble". 

But I think it is a well-known problem within the IETF. If you tie your work to
the output of another WG, and that WG gets bogged down in issues unrelated to
what you need (or worse, the WG gets shut down), where does that leave you?

ER> it seems to take quite some time to get a new protocol right.  We're
ER> *still* finding problems in IKEv2 and TLS, after 10 years. [...]
ER> The major argument you're making for designing a new protocol is
ER> time to market. I think you're dramatically underestimating the
ER> difficulty of getting a security protocol from -03 stage to
ER> finished stage. In my opinion, at this stage in the game it
ER> would be far easier to simply use IKE and add whatever
ER> authentication mechanisms it lacks that you think you need.

I've had this same thought. The nice thing about IKE is that it is already
defined. i.e. we don't have to worry about the WG getting shut down. And since
IPv6 requires it, it's likely to already be available on lots of boxes...

-- 
Robert Story; NET-SNMP Junkie
Support: <http://www.net-snmp.org/> <irc://irc.freenode.net/#net-snmp>

You are lost in a twisty maze of little standards, all different.

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 03 Mar 2005 06:26:25 -0800

> what you need (or worse, the WG gets shut down), where does that leave you?

Yes, but we also have plenty of cautionary tales about how we were just
going to whip out this alternative protocol in no time and then years
later...

The good news in this case, however, is that both IKE and EAP are
already in existence and do *something*, even if they don't 
have every single feature that you want.

-Ekr

---

From: Robert Story <[email-masked]>
Date: Thu, 3 Mar 2005 10:13:42 -0500

On Thu, 03 Mar 2005 06:26:25 -0800 Eric wrote:
ER> > But I think it is a well-known problem within the IETF. If you tie your
ER> > work to the output of another WG, and that WG gets bogged down in issues
ER> > unrelated to what you need (or worse, the WG gets shut down), where does
ER> > that leave you?
ER> 
ER> Yes, but we also have plenty of cautionary tales about how we were just
ER> going to whip out this alternative protocol in no time and then years
ER> later...

Heh. Also very true.

ER> The good news in this case, however, is that both IKE and EAP are
ER> already in existence and do *something*, even if they don't 
ER> have every single feature that you want.

Right, though I'd lean more towards IKE, for the reasons I stated before.

---

From: Robert Story <[email-masked]>
Date: Thu, 3 Mar 2005 10:20:26 -0500

On Wed, 02 Mar 2005 22:22:23 -0800 Wes wrote:
WH> A much more subtle second point is that I believed (and I think I can
WH> safely say David believed) that if SNMP ever required another system
WH> they didn't have or required modifications to existing systems that it
WH> would result in less use of SNMP.

I agree. 

WH> What does B [device setup] above entail?  It requires a number of things.
WH> 
WH>   B.1   Creation of login accounts and/or changing of default
WH>         administrator passwords.

I think this is the biggest single argument for making local accounts the 'must
implement' system. It's universal, and doesn't require any external services.

Not knowing much about RADIUS, can someone explain how it is different from
local accounts, from the originators perspective? Doesn't the originator pass
the same information to the device (userid/password)?