Subject: [Isms] Discussion: Architecture direction for ISMS

From: Ken Hornstein <[email-masked]>
Date: Fri, 18 Mar 2005 18:40:14 -0500

Greetings all,

As you all know, the outcome from the ISMS working group meeting was that
due to a number of events, we are now tasked with deciding on the architecture
to use for ISMS.  As discussed in the meeting, there are three obvious choices,
which neatly correspond to the three proposed ISMS protocols.  Note that
choosing a security architecture doesn't necessarily mean we have to choose
the particular proposed protocol; my expectation is that once we pick a
particular architecture, we'll develop a new protocol based on that
architecture.

As I see it, we have the following architectures to choose from.  Note that
when I say "features", I'm not making a decision on whether or not a feature
is good or bad; it's just some of the more important points to consider.
I have no doubt others will have other features to bring up about each
architecture.

- "Out of Band Keying"

  This is the approach chosen by EUSM.  Essentially, a seperate protocol
  exchange is conducted between the manager and agent (or a third party)
  and a key is then established/derived for use with standard USM.

  Features:

  - Can make use of existing USM (already-analyzed protocol).
  - Likely wide variety of IETF protocols to use as out-of-band keying protocol
  - Encryption/checksum modes limited to ones supported by USM
  - Extra care would be required to assure keying material derived from
    out-of-band exchange is matched with a particular USM session.

- "In Band Keying"

  This is the approach taken by SBSM.  The security protocol is
  contained within SNMP payloads and likely whatever protocol is chosen
  will have a way to secure the PDU contents.

  Features:

  - Requires new SNMP security model.
  - Is more in line with the traditional way security is applied to
    application protocols.
  - Exact privacy/integrity details will need to be specified by this or
    other protocol (depending on which framework is chosen).

- "Encapsulation keying"

  This is the approach taken by TLSM.  An encapsulation protocol (such
  as TLS) is used to "wrap" SNMP payloads.  A traditional USM could be
  run underneath this protocol.

  - Likely requires no changes to SNMP protocol.
  - Is used by a number of other protocols with a great deal of success.
  - _May_ require the use of TCP.
  - Traditional TLS only performs authentication for some mechanisms, may
    require additional work to support other authentication schemes.

I am sure that others will have additional features to add to the ones
I've listed above.  Anyway, please, anyone that has any thoughts, please
lets get them out there!

--Ken

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

---

From: "David T. Perkins" <[email-masked]>
Date: Fri, 18 Mar 2005 17:26:22 -0800 (PST)

HI,

The Keying architecture is only one part of the problem
to be solved.

On "Out of Band" vs "In Band", both EUSM and SBSM can be modified
to use either. The result of keying is:
 1) a session Identity
 2) a master session key from which the MIC and encryption keys
     are derived
 3) mutual authentication
 4) the "auth protocol" and "priv protocol" (SNMP terminology) to
    be used for MIC and encryption during normal message exchange
 5) other session parameters (such as activity timeout, or rekeying)
 6) if possible, the group to be used

Note that 3rd party keying as described in EUSM will not work
with Radius, since Radius servers cannot remember state. If a
single one was modified to do so, this would create a problem
for supporting Radius server groups (the state would have to be
made available to all Radius servers in the group).

During the IETF meeting, there were some investigation into
what other protocol could be used. The ICOS BOF covered
security background and presented some possible approaches.
As was pointed out on the ISMS mailing list, and at the WG
meeting, that technology based on EAP is outside the realm
of applicabillity. See
http://www.drizzle.com/~aboba/IETF62/icos/ietf62_eap_applicability.ppt

In the ICOS BOF, another contender IKEv2 (and IKEv1) were discussed.
It turns out that IKEv1 could possibly be used, but its
replacement, IKEv2 is strictly for IPSEC and not for other uses.

Another choice was SASL. However, SASL doesn't do the job by
itself, and other work would need to be done.

Other candidates include GSSAPI and PANA. The EUSM specification
identifies PANA. However, no analysis has been done so far
to understand the issue with using GSSAPI and PANA.

Uri & Eric (and other security people) please chime in if
I missed something.

The other parts of the architecture are
1) when running, what will be done for session identification,
   and what will be done for replay protection. EUSM proposes
   the use what was done for USM. However, the user name
   and IP address is ambiguous, since in many cases on
   SNMP managers, there are concurrent SNMP manager applications
   that are running that do not use the same "SNMP engine"
   and are unaware of the existance of each other. Also,
   the USM replay protection requires use of a loosely
   synchronized clock and choosing an authoritative SNMP
   engine. This is much more complicated than needed, once
   a session based approach is used. SBSM uses a different
   and simplier approach for session identification and
   replay protection.

2) Setting up sessions for delivering notifications. This
   is tricky, since the notification sender has a security
   name (a security model independent identity) that it want
   to deliver a notification to. However, a notification
   receiver may support multiple identites. How to do mutual
   authentication, can be a little tricky in this case.

That's it so far. 

> I've listed above.  Anyway, please, anyone that has any thoughts, please

Regards,
/david t. perkins

---

From: Robert Story <[email-masked]>
Date: Mon, 21 Mar 2005 17:00:43 -0500

On Fri, 18 Mar 2005 17:26:22 -0800 (PST) David wrote:
DTP> On Fri, 18 Mar 2005, Ken Hornstein wrote:
DTP> > - "Encapsulation keying"
DTP> > 
DTP> >   This is the approach taken by TLSM.  An encapsulation protocol (such
DTP> >   as TLS) is used to "wrap" SNMP payloads.

DTP> 2) Setting up sessions for delivering notifications.

Speaking of notifications, isn't there an issue with the transport approach
and notifications? Doesn't net-conf suffer from this issue? Specifically,
sending a notification when the notification destination doesn't have an
existing open session with the notification generator.

-- 
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: "David B Harrington" <[email-masked]>
Date: Mon, 21 Mar 2005 18:05:36 -0500

Hi,

The TLSM document mentions  in section 4.6 the possible need to create
a new session to send a notification, if no session is currently open.

The ability to send asynchronous notifications is not subject to the
same issues as netconf. 

To get netconf 1.0 published faster, the netconf WG punted on the
notification issue. Part of the issue for netconf is that processing
must be done sequentially - there is only one channel, and XML
messages must be handled in line-by-line order, and each message must
be parsed completely to ensure well-formed, valid XML, and Netconf
messages can be very large because they are just streaming text, and
may need to contain all the configuration commands for a complex
device. There is no reasonable way to send asynchronous notifications
in the middle of a netconf stream. I think the single global lock
issue may also impact netconf's ability to send notifications while an
incoming message is being processed, but further research may show
that it doesn't.

I don't think it would be wise for a TLSM design to punt on addressing
the notification issue. TLSM is still underspecified, but I don't
expect it to necessarily be constrained to only one channel in a
session or to only one session between entities. SNMP explicitly does
not guarantee the ordering of the processing of varbinds, does not
require that all varbinds are validated before processing begins, and
does not impose a message ordering requirement. While using a
secured-TCP-based transport might permit multiple SNMP messages to be
sent in the same session, I expect that for backwards compatibility,
the size of a single message will still be constrained by the
currently implemented SNMP buffer sizes in managers and agents, so
current SNMP rules and guidelines about message size will probably
still apply, at least for a while. SNMP messages are frequently
parallel-processed and SNMP tends to use table locks rather than a
global lock, so sending a notification to another entity while
processing a varbind list from that same entity should not really be a
problem from the SNMP side of the equation.

David Harrington
[email-masked]

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Robert Story
> Sent: Monday, March 21, 2005 5:01 PM
> To: [email-masked]
> Subject: Re: [Isms] Discussion: Architecture direction for ISMS
>

---

From: Robert Story <[email-masked]>
Date: Mon, 21 Mar 2005 18:47:16 -0500

On Mon, 21 Mar 2005 18:05:36 -0500 David wrote:
DBH> The TLSM document mentions  in section 4.6 the possible need to create
DBH> a new session to send a notification, if no session is currently open.

Right. My question is, is this scenario something that happens in the existing
infra-structure?  I'm not familiar with TLS, but I do use SSH as a transport,
and I'm guessing TLS is similar. It's a one way thing. So using it to receive
unsolicited notifications when there is no existing session requires setup on
the notification receiver's side that does not exist in the current
infra-structure. And it's very unlikely that a management station will have a
session established with every device it manages (especially if there are 100k+
nodes, like the networks Eric is always talking about).

DBH> I don't think it would be wise for a TLSM design to punt on addressing
DBH> the notification issue.

I agree. A new security model that can't do everything the previous one would
would be DOA.

On the other hand, in the absence of a session, notifications could be sent
using existing USM. If informs were used, an intelligent manager could drop the
first inform and establish a session with the notification originator,
hopefully in time for the retry to come over the newly established session.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 22 Mar 2005 01:05:56 +0100

> nodes, like the networks Eric is always talking about).

RFC 3430 might be useful reading material here. The text in section 2.3
says that the notification originator is responsible to establish any
TCP sessions needed to deliver a notification to the interested targets.
A summary of several options discussed while RFC 3430 was produced is 
contained in Appendix A.

/js

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

---

From: Kaushik Narayan <[email-masked]>
Date: Mon, 21 Mar 2005 17:47:45 -0800

Hi Ken,

We believe that use of in-band and out-of-band keying is not the most
important difference between EUSM and SBSM. EUSM could use an
in-band Key Setup via using SNMPv3 noAuthnoPriv Notification
messages (similar to SNMPv3 engine ID discovery).

We believe the most important differences are

1. EUSM attempts to ONLY solve the problem of "integration of USM with
existing authentication systems". We retain the USM and it's processing
entirely and only add capability to provision keys used by USM.

2. EUSM completely relies on existing authenticated key exchange
mechanisms that have been well defined, implemented and analyzed, we
had proposed the use of EAP for Key Setup and we plan to suggest the
use of TLS or GSSAPI for Key Setup.

We do plan to put an EUSM -03 draft with changes based on the recommendation
on EAP usage. We have got feedback that the use of the RADIUS server to 
distribute
keys is not desirable. We plan to remove the parts that describe the use of 
RADIUS
for Key Request and the use of the RADIUS server to distribute keys to 
multiple agents
in the EUSM -03 draft.

regards,
    kaushik!

---

From: Wes Hardaker <[email-masked]>
Date: Mon, 21 Mar 2005 21:06:18 -0800

>>>>> On Fri, 18 Mar 2005 18:40:14 -0500, Ken Hornstein <[email-masked]> said:

Ken> - "Out of Band Keying"

Ken> This is the approach chosen by EUSM.  Essentially, a seperate protocol
Ken> exchange is conducted between the manager and agent (or a third party)
Ken> and a key is then established/derived for use with standard USM.

That's a EUSM specific solution.  Any of the given architectures could
support shoving keys into USM and I think that is a separate issue
(the use of USM or something else) and should be treaded separately.
All three of the architectures (or deviations to the existing
protocols) could feed keys to USM or to something different.  Let's
forget about USM for the time being and concentrate just on keys.
Yes, they're highly interrelated but I suspect if we don't separate
the issues we'll never come to an agreement.

Ken> Features:

Ken> - Can make use of existing USM (already-analyzed protocol).

They can all do this somehow or another.

Ken> - Likely wide variety of IETF protocols to use as out-of-band
Ken>   keying protocol

Yes, but the architectures of those other systems are often very
different.  As I explained in a previous note (which I'm not going to
repeat here), SNMP has potentially many components running on a
device.  The choices for how to deal with this problem result in
either: 

  1) interoperability between all SNMP *and* key-distribution-protocol
     stack vendors on a given device.
     [4 SNMP stack vendors and 4 key dist. vendors = 16 possibilities]

  2) run one independent keying service per SNMP service on the
     device.
     [the result being N-2*N ports open, where N is the number of SNMP
     related ports open with one new one per service.].

One of the goals of this working group is to reuse existing
mechanisms.  I do not think that existing keying exchanges are used
today in many cases that we can reuse here.  EAP and IKEv2 have been
shown to be not-very-good fits (to say the least) and that doesn't
leave anything else but kerberos.  Kerberos is actually a nice
solution to the above problem, as it is ticket based and the tickets
have service names/keys attached to them.  However, kerberos isn't
in wide use (unfortunately) and it would still require modification to
the SNMP protocol to get the key from the ticket put into the service.

Ken> - Encryption/checksum modes limited to ones supported by USM

Again, this is not a fact of the architecture but of EUSM's
implementation.  We agreed in MSP to talk about the architecture
features more than the solution features.

Ken> - Extra care would be required to assure keying material derived from
Ken> out-of-band exchange is matched with a particular USM session.

External keying protocols really need a key identifier and a
destination identifier.

In summary, I'm not a fan of an external keying protocols for this
situation [it's the only one I'm not a fan of actually].  I've used
them many times in other situations where they have worked well, but I
don't think it's a good fit for SNMP at all.  The complexity discussed
in a previous message above and above cause too many problems when I
considered trying to implement it in a number of the stacks I work
with (the open source ones being Net-SNMP, OpenSNMP & Net-Policy).  It
simply couldn't be done without breaking the high level of portability
of some of those projects in the process of adding external keying.

Additionally, I don't see an existing deployment of this technique
that makes me want to marry it to SNMP.  Many of the external keying
protocols are definitely being used, but they're not being used
heavily.  IKE doesn't exist in most devices.  EAP doesn't exist in
many devices (I'd argue "most" but I don't have numbers to back that
up).  Kerberos doesn't exist in most devices and doesn't have wide
deployment.  If half of our point is to reuse what is available and
deployed today, I don't think it's wise to go down this road as we'd
be breaking from our goals.  I do not believe that operators today are
using seperate keying mechanisms for 99% of what they do.  It has
great penetration into only parts of small, not-complete markets (such
as VPN and WAP environments) but not for the rest of the deployed
enterprises.  At least based on the discussions I've had with users.

----------------------------------------------------------------------

Ken> - "In Band Keying"

Ken> This is the approach taken by SBSM.  The security protocol is
Ken> contained within SNMP payloads and likely whatever protocol is chosen
Ken> will have a way to secure the PDU contents.

Ken> Features:

Ken> - Requires new SNMP security model.

They all do.  Well, TLSM hasn't actually stated that.  EUSM is a new
security model with a low new footprint as it reuses the message
payload and protocol steps (a big reuse) but requires a new security
number on the wire (and thus at least a small change to existing
stacks, though it's the smallest of them all).

SBSM requires a new security model for use in negotiating keys, which
requires new code for doing so within the SNMP stacks.  It could reuse
USM for running-session traffic, but again I'll save that argument for
a later date when we get to that point.

Ken> - Is more in line with the traditional way security is applied to
Ken> application protocols.

Interesting phrasing ;-)  It is more traditional, but it's also the
tradition that is often hated by many to be fair.  That being said, as
I explained in a previous message there was a reason I went with this
approach after considering the others.  I won't repeat that here.

Ken> - Exact privacy/integrity details will need to be specified by this or
Ken> other protocol (depending on which framework is chosen).

***

More features:
- transport independent (UDP, TCP, AAL5, ...).  I can't predict the
  future use of the protocol, and thus this is a nice-to-have in my
  opinion (besides the fact that I have a fair number of users using
  it over non UDP/TCP transports; a lot more than I'd expect actually)

----------------------------------------------------------------------

Ken> - "Encapsulation keying"

Ken> This is the approach taken by TLSM.  An encapsulation protocol (such
Ken> as TLS) is used to "wrap" SNMP payloads.  A traditional USM could be
Ken> run underneath this protocol.

[there may be issues with running USM underneath but it is possible]

Ken> - Likely requires no changes to SNMP protocol.

I disagree.  I think it would be unwise to at least not assign a new
security model number.  USM and any TLSM based session should have
different identifiers, IMHO.  (I'd actually assign one per each TLSM
base transport personally).  It has only been discussed a little bit 

Ken> - Is used by a number of other protocols with a great deal of success.
Ken> - _May_ require the use of TCP.

Existing commonly in-use versions certainly well.  There is no
current widely-deployed underlying transport that doesn't use TCP.

I'm not convinced we should dump UDP and move to TCP, but I think DTLS
will hopefully cover this ground for this spot if it goes forward.

I think a "Encapsulation keying" provides a nice warm feeling because
it's able to use commonly deployed and in use mechanisms (namely TLS
and SSH), but it does suffer problems as well namely that the number
of transports to choose from are fairly limited and are restricted to
UDP and TCP based transports, but then again that does cover 99% of
the cases.  The other nice thing about the encapsulation is that it
provides protection better than what USM itself provides and since you
get that for free (assuming we pick reasonable transports) then the
whole USM/new-model argument is pretty much moot.  It's also been
implemented before by a number of people.

In summary, I'd be happy with an Encapsulation Keying mechanism though
I don't think we'd get quite the deployment level that we might
achieve with an "In Band Keying" mechanism it'd still be fairly high
(certainly significantly higher than current SNMPv3).

-- 
Wes Hardaker
Sparta

---

From: Wes Hardaker <[email-masked]>
Date: Tue, 22 Mar 2005 20:23:39 -0800

>>>>> On Mon, 21 Mar 2005 17:47:45 -0800, Kaushik Narayan <[email-masked]> said:

Kaushik> We believe that use of in-band and out-of-band keying is not
Kaushik> the most important difference between EUSM and SBSM.

This is a different argument than you've been previously making.  One
of the whole purposes of this discussion was to come to agreement on
something, namely an architecture first.

In your response you didn't seem to state clearly if you had
preferences for one or two of the architectures.  It appears that
you're no longer solely considering an out-of-band mechanism which is
a very good thing because if we can all agree to move a "little bit"
we'll likely end up somewhere that we can at least agree upon even if
it's not the ideal place for each of us.

Kaushik> We believe the most important differences are

So, given that can we concentrate on a preferred architecture first
and then battle the USM issue.  This is what we agreed upon in MSP but
yet everyone seems to want to argue the USM case instead.

Kaushik> ... we had proposed the use of EAP for Key Setup and we plan
Kaushik> to suggest the use of TLS or GSSAPI for Key Setup.

Given the above statement, I originally thought you had meant either
out of band or in-band-underneath would be fine (GSSAPI is out-of-band
sort of...  GSSAPI is really an API not an architecture but the
current common mechanism (kerberos) is out-of-band).

But having re-read what you've said I could see someone proposing TLS
on the side to do out-of-band negotiation over TLS.  I assume this is
not what you're going to propose since it would be somewhat unusual
but thought I should double check.

So, if you had to pick two (or one) of the architectures (*not*
solutions for those architectures) it sounds like you're at least
willing to consider "encapsulation" (TLS like) or "out of band" (EAP
like) architectures?

It sounds like we're (the group as a whole) actually converging on an
architecture which is acceptable to everyone, which is a really really
good thing.

-- 
Wes Hardaker
Sparta