Subject: RE: [Isms] ISMS Encryption Requirement

From: "McDonald, Ira" <[email-masked]>
Date: Thu, 21 Oct 2004 09:28:19 -0700

Hi folks,

<Robert Story wrote>

> But this still leaves open the possibility of a response PDU with a
different
> security level than the request PDU, which was my initial objection.

> KH> But even saying _that_ means we have to complicate the GetBulkRequest
code
> KH> to know that it needs to process these MIB elements in a different
way.

> Not just GetBulk, but GetNext as well. Like I said, for get/set requests,
the
> manager should be able to determine the appropriate level before sending a
> request. (though a manager and agent might disagree on what that level
should
> be. but that's getting into policy.)

Changing security _within_ a PDU is very unwise.

And having the responder _degrade_ the security level specified in a request
is simply broken.  Policy should never force broken protocol behaviour.

And all of this discussion is for a corner case requirement.  There is
nothing
to prevent a client (SNMP Manager) from starting two sessions to cope with
different security levels.  The complexity of supporting different security 
levels in the same session is an unreasonable burden.

I dislike this corner case requirement because it rules out the use of all
existing session mode security protocols (which negotiate security
parameters
_once_ at beginning of session) and takes us off into unusual new protocols,
which is no improvement at all over USM/VACM.

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Blue Roof Music / High North Inc
PO Box 221  Grand Marais, MI  49839
phone: +1-906-494-2434
email: [email-masked]

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

---

From: Robert Story <[email-masked]>
Date: Thu, 21 Oct 2004 12:54:37 -0400

On Thu, 21 Oct 2004 09:28:19 -0700 McDonald, wrote:
MI> Changing security _within_ a PDU is very unwise.

I think we are all in agreement here. And nobody proposed that we should (I
though that's what the original message implied, but I was wrong).

MI> And all of this discussion is for a corner case requirement.  There is
MI> nothing to prevent a client (SNMP Manager) from starting two sessions to
MI> cope with different security levels.  The complexity of supporting
MI> different security levels in the same session is an unreasonable burden.

I disagree here. Agents are often resource-constrained. Adding sessions
increases the need for resources, we shouldn't require two sessions when one
can suffice.

MI> I dislike this corner case requirement because it rules out the use of all
MI> existing session mode security protocols (which negotiate security
MI> parameters _once_ at beginning of session)

I don't think that is the case.  As I suggested earlier, the session could have
a 'maximum' security level, which would not necessarily require that all
messages sent via that session are of the same level.

If a session is created as 'authPriv', then keys for encryption would still be
negotiated once at the beginning of the session. But if a message is
presented to the session with a security level of authNoPriv, then that message
could simply be authenticated and not encrypted. Wouldn't that also have some
security benefit, in that it reduces the encrypted data available to an
attacker gathering packets to try and discover the encryption keys?

The session could also have a minimum security level, so that a session created
with a min/max of authPriv would reject an attempt to send an authNoPriv
message.

I think 2 bytes per session structure and a compare or two is much less of a
resource burden on an agent than two separate sessions.

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

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

---

From: "David B Harrington" <[email-masked]>
Date: Thu, 21 Oct 2004 14:04:30 -0400

Hi Robert,

Why are we having this discussion? Is this in scope? Or is this just
an interesting tangent of out-of-scope feature creep?

If it is in scope, can you tell me how it is in scope? Which of the
proposals has the capabilty of supporting this feature using existing
security infrastructure and without violating the architectural
constraints of SNMPv3?

Dbh

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Robert Story
Sent: Thursday, October 21, 2004 12:55 PM
To: McDonald, Ira
Cc: [email-masked]
Subject: Re: [Isms] ISMS Encryption Requirement

I think we are all in agreement here. And nobody proposed that we
should (I though that's what the original message implied, but I was
wrong).

MI> And all of this discussion is for a corner case requirement.
There 
MI> is nothing to prevent a client (SNMP Manager) from starting two 
MI> sessions to cope with different security levels.  The complexity
of 
MI> supporting different security levels in the same session is an
unreasonable burden.

I disagree here. Agents are often resource-constrained. Adding
sessions increases the need for resources, we shouldn't require two
sessions when one can suffice.

MI> I dislike this corner case requirement because it rules out the
use 
MI> of all existing session mode security protocols (which negotiate 
MI> security parameters _once_ at beginning of session)

I don't think that is the case.  As I suggested earlier, the session
could have a 'maximum' security level, which would not necessarily
require that all messages sent via that session are of the same level.

If a session is created as 'authPriv', then keys for encryption would
still be negotiated once at the beginning of the session. But if a
message is presented to the session with a security level of
authNoPriv, then that message could simply be authenticated and not
encrypted. Wouldn't that also have some security benefit, in that it
reduces the encrypted data available to an attacker gathering packets
to try and discover the encryption keys?

The session could also have a minimum security level, so that a
session created with a min/max of authPriv would reject an attempt to
send an authNoPriv message.

I think 2 bytes per session structure and a compare or two is much
less of a resource burden on an agent than two separate sessions.

---

From: Robert Story <[email-masked]>
Date: Thu, 21 Oct 2004 14:17:34 -0400

On Thu, 21 Oct 2004 14:04:30 -0400 David wrote:
DBH> Why are we having this discussion? Is this in scope? Or is this just
DBH> an interesting tangent of out-of-scope feature creep?

No, it is not in scope. It is a tangent spawned by my misinterpretation of the
original message that started this thread. I've repeatedly stated that, and
Kaushuik has repeatedly stated that his intent was only to be able to specify
authNoPriv and authPriv on a per-packet basis. I think his concern is that a
session that is set up as authPriv would encrypt noAuthPriv messages, and he'd
like to avoid that overhead.

---

From: "David T. Perkins" <[email-masked]>
Date: Thu, 21 Oct 2004 12:20:52 -0700 (PDT)

HI,

Yes, the issue is with using SSL/TLS where the "transport"
possibly provides endpoint authentication (the value for
securityName), message integrity and encryption is provided
below in the stack than SNMPv3 messages. And thus,
1) how is this lower layer info passed up?
2) how are the integrity and encryption bits in 
   SNMPv3 messages interpreted (do they have to match
   the security services provided by the lower layer,
   or are they ignored (and the values from the lower
   layer used).
3) the request (and notification) originator loses
   the ability to specify per message auth and encryption
   services, since they are "fixed" by the SSL/TLS
   connection.

Regards,
/david t. perkins