Subject: [Isms] Thoughts on Encapsulation

From: Sam Hartman <[email-masked]>
Date: Thu, 05 May 2005 08:11:57 -0400

The following thoughts are presented as an individual.  I'm trying to
give a background on all the sorts of things you could do with
encapsulation for SNMP.  I may miss some things and I may over
simplify things.

So there are several different security technologies you might want to
support.  I'd argue that you probably want to support more than one.

1) TLS/SASL.  The combination of TLS and SASL go well together.  You
   typically use one or both.  In one common mode, TLS is used to
   authenticate the server (responder) to the client.  The server has
   a cert and the client does not.  You then use SASL to authenticate
   the client to the server.  TLS is used to protect the session.
   Another common mode supported by the TLS+SASL option only involves
   SASL.  You use a SASL security layer that provides mutual
   authentication to provide both data confidentiality and integrity
   to the session  and to authenticate both parties.  This SASL-only
   mode is used by Kerberos.  A third mode involves only TLS.  Both
   the client and server have certificates.  This actually often looks
   like the first mode because the SASL external mechanism is used to
   signal that TLS has provided the client authentication.

2) Ssh.  This provides for authentication  using public keys, Kerberos
   and passwords among other options.  I'd look at the netconf over
   ssh document as a starting point for how to do this.

3) DTLS.  DTLS is probably going to be important because it provides
   UDP support.  The catch with DTLS is going to be figuring out how
   to authenticate the client to the server if the client doesn't have
   credentials.  You could use SASL while not supporting security
   layers but doing so will make the Kerberos camp quite unhappy.

I'd also recommend trying to treat notifications as no different than
any other message.  Try two approaches and see which works out best.
The first is to try using the existing security context for
notifications.  The second is to try treating notifications as their
own security context; most of the mechanisms discussed work if you let
the notifier be the client/initiator.  The party receiving
notifications will need credentials but that's actually probably OK.

Here are some things I'd recommend against.  Note that these
recommendations are not things that would cause me to reject a
solution so much as things that would cause me as an individual to
have a bunch of questions about why you were taking that approach.

1) Supporting TLS and SASL without supporting all three modes as
   described above.

2) Using ssh keys but not ssh.

3) Assuming that SASL can be used in a datagram-like manner without
    ordering and reliable delivery.

4) Using Kerberos directly (*)

5) Using/recommending the Kerberos TLS ciphersuites.  The Kerberos ssh
   support is fine though.

6) Using raw public-key operations.

7) Extracting the session key from a SASL mechanism.  That's just not
supported by SASL implementations.

(*) It may be that SASL is not good enough for the datagram case and
thus you may want to provide for future extension to GSS.  That might
look a lot to some like raw Kerberos; it certainly would be
complicated.  I'm a bit concerned that UDP support is going to end up
complicated.

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

---

From: Eliot Lear <[email-masked]>
Date: Thu, 05 May 2005 15:45:37 +0200

Sam,

Reading your message and that of others, I have a question for the group 
as to whether EK implies that the entire SNMP packet will be 
encapsulated or whether a very simple SASL/TLS dance is done to generate 
a session key used in a packet that looks just like USM/UDP?

There are benefits to either.  Encapsulating gets you through firewalls 
more easily (and some people view this as a drawback), while costs you 
something in performance.  Doing the key dance costs you almost nothing 
in additional performance but may add some administration complexity 
given that there are now two connections needed to maintain SNMP 
connectivity.

Eliot

---

From: Wes Hardaker <[email-masked]>
Date: Thu, 05 May 2005 07:11:25 -0700

>>>>> On Thu, 05 May 2005 15:45:37 +0200, Eliot Lear <[email-masked]> said:

Eliot> Reading your message and that of others, I have a question for the group 
Eliot> as to whether EK implies that the entire SNMP packet will be 
Eliot> encapsulated or whether a very simple SASL/TLS dance is done to generate 
Eliot> a session key used in a packet that looks just like USM/UDP?

If that session key is no longer user during the session (IE, you take
it and start using SNMPv3/USM directly) then it's OOB not EK isn't it?

-- 
Wes Hardaker
Sparta, Inc.

---

From: Eliot Lear <[email-masked]>
Date: Thu, 05 May 2005 16:21:18 +0200

> it and start using SNMPv3/USM directly) then it's OOB not EK isn't it?

Heck I don't know.  I've been viewing OOB as a three three party 
exchange, and EK as a two party exchange.  Whether it was a single 
connection or multiple connections between the two parties was a bit of 
a different question.

Eliot

---

From: Wes Hardaker <[email-masked]>
Date: Thu, 05 May 2005 07:31:06 -0700

>>>>> On Thu, 05 May 2005 16:21:18 +0200, Eliot Lear <[email-masked]> said:

Eliot> Heck I don't know.  I've been viewing OOB as a three three party 
Eliot> exchange, and EK as a two party exchange.  Whether it was a single 
Eliot> connection or multiple connections between the two parties was a bit of 
Eliot> a different question.

I don't think OOB has ever said the number of partys involved are 3.
IKE, which many people have been considering as a potential OOB
solution, is a 2 party exchange much of the time.  As is EAP some of
the time as well.

-- 
Wes Hardaker
Sparta, Inc.

---

From: Eliot Lear <[email-masked]>
Date: Thu, 05 May 2005 16:35:23 +0200

> solution, is a 2 party exchange much of the time.  As is EAP some of

Not the way it was discussed in the group, tho.  The EAP exchange was 
between agent and radius server, as I understood it.  But look, we've 
gotten away from my basic question.  Was what people intended an 
augmentation to RFC 3417?  Put another way, was anyone else pondering 
other than an augmentation to RFC 3417?

Eliot

---

From: "Tom Petch" <[email-masked]>
Date: Sun, 8 May 2005 11:38:10 +0200

I would find it most helpful at this stage to have a picture of the way
TLSM/TMSM fits in with the
architecture of SNMP (as in RFC 3411 s3.1.3) ie a follow up to

"TODO: Insert drawing here..."

from

SNMPv3 Transport Mapping Security Model  section 3.2

Tom Petch

---

From: "David B Harrington" <[email-masked]>
Date: Sun, 8 May 2005 13:09:02 -0400

Hi,

I hate doing ASCII art, but here you go.

USM approach:

The security model is encapsulated by the messaging model, because the
messaging model needs to (for incoming messages)
1) decode the ASN.1 (messaging model)
2) determine the SNMP security model and parameters (messaging model) 
3) decrypt the encrypted portions of the message (security model)
4) translate parameters to model-independent parameters (security
model)
5) determine which application should get the decrypted portions
(messaging model), and
6) pass on the decrypted portions with model-independent parameters.
This is largely dependent on having SNMP-specific message security and
parameters.

--------------------------------------------------
|                                                |
| ---------------------      ------------------  |
| | SNMP applications | <--> | access control |  |
| ---------------------      ------------------  |
|         ^
|         |
|         v
| ---------------------------------------------  |
|                            ------------------  |
|   SNMP messaging      <--> | decryption +   |  |
|                            | translation    |  |
|                            ------------------  |
| ---------------------------------------------  |
|         ^
|         |
|         v
| -----------------------------------------------|
| | transport mapping                            | 
| -----------------------------------------------|
|         ^
|         |
|         v
| -----------------------------------------------|
| | transport layer                              |
| -----------------------------------------------|

TLSM approach: 

The order of the steps differ and may be handled by different
subsystems:
1) decrypt the encrypted portions of the message (transport layer)
2) determine the SNMP security model and parameters (transport
mapping)
3*) translate parameters to model-independent parameters (transport
mapping)
4) decode the ASN.1 (messaging model)
5) determine which application should get the decrypted portions
(messaging model)
6*) translate parameters to model-independent parameters (security
model)
7) pass on the decrypted portions with model-independent security
parameters  
This is largely based on having non-SNMP-specific message security and
parameters.

The transport mapping model might provide the translation from (e.g.)
TLS user to securityName in step 3, OR 
The TLS user might be passed to the messaging model to pass to a
TLSM/TMSM security model to do the translation in step 6, if the WG
decides all translations should use the same translation table (e.g.
the USM MIB).

--------------------------------------------------
|                                                |
| ---------------------      ------------------  |
| | SNMP applications | <--> | access control |  |
| ---------------------      ------------------  |
|         ^
|         |
|         v
| ---------------------------------------------  |
|                            ------------------  |
|   SNMP messaging     <--> | translation*    |  |
|                            ------------------  |
|----------------------------------------------  |
|         ^
|         |
|         v
| -----------------------------------------------|
|                            ------------------  |
|  transport mapping   <--> | translation*    |  |
|                            ------------------  |
| -----------------------------------------------|
|         ^
|         |
|         v
| -----------------------------------------------|
|                            ------------------  |
|   transport layer     <--> | decryption     |  |
|                            ------------------  |
| -----------------------------------------------|

Hope this helps,
David Harrington
[email-masked]

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Tom Petch
> Sent: Sunday, May 08, 2005 5:38 AM
> To: [email-masked]
> Subject: [Isms] A picture is worth a 1000 words
>

---

From: "Tom Petch" <[email-masked]>
Date: Mon, 9 May 2005 15:39:41 +0200

Sam,

In which part of your dichotomy would you place 

draft-ietf-tls-psk-08.txt

Tom Petch

---

From: Sam Hartman <[email-masked]>
Date: Mon, 09 May 2005 12:55:29 -0400

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

    Tom> Sam, In which part of your dichotomy would you place

    Tom> draft-ietf-tls-psk-08.txt

I don't think it fits well into ISMS.  You *could* ues it.  If you did
I'd expect you to then use SASL external.  But it only works well if
you already have TLS PSKs configured somehow.  It doesn't work well
with RADIUS or other existing mechanisms.

Same goes for any TLS SRP solution only more so.

Don't get me wrong: if your organization wants to deploy SRP or TLS
PSKs that's great.  You'll get better security; you'll have all sorts
of warm fuzzy feelings.  You won't be using the infrastructure you
have today though and supporting existing infrastructure is the goal
of ISMS.

Naturally I'm going to be concerned if we come up with an ISMS
solution that won't work with potential future infrastructures.  I
don't see that happening though.

---

From: "Tom Petch" <[email-masked]>
Date: Tue, 10 May 2005 21:10:43 +0200

Thanks for that.  What caught my eye in it was
"avoid the need for public key operations.  This is useful if TLS is used in
performance-constrained environments with limited CPU power."
which fits my image of many agents.  A challenge I always see in SNMP security
is that the server (agent) is the thin skinny device that may not be capable of
too much while the client (manager) has the power and resources available - role
reversal compared with most  client-server systems: and I see server
authentication of client (eg set operation) as a pressing need.

And to quote Wes (yet one more time) operators' survey
"Of the various authentication systems in use at that time by the
people that responded:

  66%  local accounts
  49%  SSH-keys
  40%  Radius
  29%  TACACS+
  14%  X.509 Certificates
  10%  Kerberos"

Tom Petch