Subject: RE: [Isms] Agenda item

From: "Blumenthal, Uri" <[email-masked]>
Date: Thu, 3 Mar 2005 12:50:15 -0500

IMHO, we need to:

1. Realize that most of "good" security protocols have two 
   [almost-]independent parts: 

     - establishment part that offers strong end-point authentication, 
       policy application, deciding upon the crypto algorithms to use,
       creation of dynamic Security Association, keys, etc.

     - traffic protection part, that simply takes one packet at a time
       and applies authentication, confidentiality and (optionally)
       freshness algorithms to it, with the keys provided by 
       establshment part.

2. Realize that current SNMPv3 USM security is essentially only the 
   2nd - i.e. traffic protection part. It is analogous to IPsec 
   with manually keyed SA (*not* IKE with manual keying!).

3. Realize that the "establishment part" can provide keys etc. to
   any traffic protection part, including USM.

4. Realize that USM can take keys from any "establishment part",
   including IKE and EAP.

5. Realize that if we pick a good existing protocol for the
   "establishment part" and design a nice interface to it
   (call it "Session Manager Model" :-), we may
   use any old or new "Security Model" with it. 

My preference is IKEv2. I certainly can live with EAP. I want it
cleanly separated from the actual traffic protection, so they
are interchangeable.

If that design is accepted - session establishment is clean, as
packets requesting new session will carry Security Model tag that
points at the "establishment" model (which in turn will invoke 
IKE, or just run EAP encapsulated within). While the protected 
SNMP traffic would carry the tag of "traffic"  Security Model, 
such as USM.

IMHO, EUSM seems to head in this direction. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Sharon Chisholm
Sent: Thursday, March 03, 2005 10:46 AM
To: [email-masked]
Subject: RE: [Isms] Agenda item

hi

It still sounds like a loophole left in the charter to me. But, even by
your
accounts these additional 'improvements' are only a secondary priority
but
are what seem to be preventing the working group from moving forward. 

I would propose the following

1) Confirm that wg consensus and its charter is to address additional
'needs' as a secondary consideration in the solution
2) Very quickly determine what this minimal set of 'needs' is
3) Move forward with eUSM since it seems to be the best choice to meet
the
primary needs of the working group and see what changes are needed to
address these secondary 'needs'.

Sharon

-----Original Message-----
From: Wes Hardaker [mailto:[email-masked]] 
Sent: Thursday, March 03, 2005 10:23 AM
To: Chisholm, Sharon [CAR:5K50:EXCH]
Cc: [email-masked]
Subject: Re: [Isms] Agenda item

>>>>> On Thu, 3 Mar 2005 10:16:22 -0500 , "Sharon Chisholm" 
>>>>> <[email-masked]> said:

Sharon> I think you (and others) are reading too much into this one 
Sharon> sentence. The sentence is too ambiguous and should probably have

Sharon> been caught when the charter was drafted. I don't think it was 
Sharon> intended as a blank check to solve whatever problems people 
Sharon> thought would be interesting to solve. Integrating SNMPv3 
Sharon> security into existing infrastructure (and improving operational

Sharon> complexity) is the primary goal of this working group. I say 
Sharon> solve that first and then look at 'me too' problems.

Having helped write much of the charter, all the wording was fairly
carefully written and reviewed both by the WG and the IESG members. The
intent of the creation of the working group was to fix problems, and
that
included integration (most importantly) and other security issues
(secondary).  However, it is not a blank check as the wording says "meet
the
security and operational needs of network administrators".  IE, you
can't
throw anything at it if it's not needed.  That "needs" word in there is
rather important.  I don't think the WG has come to consensus on what is
"needed" exactly however.

-- 
Wes Hardaker
Sparta

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

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

---

From: "David T. Perkins" <[email-masked]>
Date: Thu, 3 Mar 2005 11:09:41 -0800 (PST)

HI,

URI, your summary outlines the approach that we have
taken with the SBSM proposal. It seems like you
believe that only EUSM "seems to head in this
direction". Or maybe you were just giving
an example. What is your view on whether or
not the SBSM follows this approach?

Note that if you have tried to deploy and use
SNMPv3/USM, then you would really be troubled
with the "freshness" (replay protection) that
is used. It really causes problems with configuration
for sending secured informs, and results in
excesive network traffic. I'm not sure people
realize these operational problems caused
by USM's design. Since USM
doesn't use sessions (or maybe you can say
it has a really long session that is started
with a user rekeying), that what was done
was a somewhat reasonable approach. But
with sessions, other approaches can be
taken for replay protection that have
much lower operational costs.

Let me repeat the high level architecture
that, I believe, describes the ideal solution:

System A        
--------
System where management apps are run.
User (or management daemon) has knowledge
about the system(s) to be managed.
Information to manage the system is
a) an identifier for the managed system
b) a transport address to use to send
   management traffic. (This may not be
   the address of the managed system
   because a proxy may be used.)
c) a supported mechanism to prove
   the identity of the managed
   system. (Note, in USM, when
   proxy is used, the security
   relation is with the proxy
   and not the managed system.)
d) an identity for the user or
   daeman and proof

System B
--------
The managed system.
Has an identity, and proof.
Has rules on how managers
are authenticated. These
may be based on manager identity,
manager transport address,
manager ingress interface,
time of day, day of week, etc.
The rules specify how to
verify identity, such as
use local accounts, use
a Radius server, use
a TACACS+ server, etc.
For each external
authenication server,
there must be configuration
set up. For example for
each Radius server, it's
IP address and shared
secret must be configured.

System C
--------
A system that runs an authentication service.
The service can be Radius, TACACS+, Kerberos,
etc.

The above is the classic diagram in the EAP
specificatio, with system A being the "peer",
system being the authenticator, and system C
being the "backend authentication server".
  
So, is this the architecture that you want,
do do you want another? 

> IMHO, EUSM seems to head in this direction. 
Regards,
/david t. perkins