Subject: [Isms] RE: Leverage existing infrastructure

From: "Khanh Nguyen \(khanhvn\)" <[email-masked]>
Date: Tue, 24 May 2005 12:59:43 -0700

> -----Original Message-----
> From: Wes Hardaker [mailto:[email-masked]] 
> 
> Khanh> In the end, I think we should give operators both options: 
> Khanh> (1) SNMP-centric (independent) authentication and
> Khanh> (2) reuse-something-else auth.
> 
> Agreed.  For 1 we have USM.  For 2 we have the results of 
> ISMS that should *not* create another database to maintain.  
> Maybe someone other than you will disagree with me about 
> this.  Who knows.

Telling operators who don't want to (or cannot) reuse 
to 'go away and use USM' is not quite a right solution, I think.

Your survey indicated that none of the existing auth
infrastructure except local accounts had more than 50%  
deployment rate.  No matter what reuse methods we try, we 
cannot guarantee that we can have 100% coverage.  Sometime 
the device just has nothing available/suitable for reuse.
Do you suggest that for these cases operator has no choice
but to use USM?

Even within the same company, you may have devices that are
different in terms of auth reusability, e.g. some devices 
support tacacs+, some may not.  Would operators have to 
deploy two SNMP security models, one for "reusable" devices,
and a completely different one (USM) for "non-reusable" devices?

I think it'll be much better if we can have a single 
SNMP security model that can support both cases.

And last but not least, as Uri Blumenthal pointed out
last week, re-use is only one of the two problems we are 
trying to solve here.  The second problem is USM use of 
long-term keys for encryp & MAC.

The second problem is significant because it addresses
USM security issues (perfect forward secrecy, off-line 
dictionary attacks, and replay attacks).  Forcing people
who cannot reuse to go back to USM is to ignore that 
second problem.  

Again, pls don't take my arguments above as "against reuse".
I am completely for it.  My point is that both SNMP-centric
and reuse-something-else auth should be supported in the 
new security model, and I believe that's an achievable goal.

Regards.

Khanh

> --
> Wes Hardaker
> Sparta, Inc.

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

---

From: Wes Hardaker <[email-masked]>
Date: Tue, 24 May 2005 13:20:24 -0700

>>>>> On Tue, 24 May 2005 12:59:43 -0700, "Khanh Nguyen (khanhvn)" <[email-masked]> said:

Khanh> Your survey indicated that none of the existing auth
Khanh> infrastructure except local accounts had more than 50%  
Khanh> deployment rate.  No matter what reuse methods we try, we 
Khanh> cannot guarantee that we can have 100% coverage.  Sometime 
Khanh> the device just has nothing available/suitable for reuse.
Khanh> Do you suggest that for these cases operator has no choice
Khanh> but to use USM?

I never said we shouldn't support multiple other databases.  In fact I
hope we do.  I hope that the end result will be able to use local
accounts, remote accounts (AAA), maybe X.509 and hopefully ssh
identities.  What I don't want is adding yet another that doesn't
exist which is a parallel DB like LPSK is proposing.  The only reason
to do that, IMHO, is if we can't create a solution without doing that.
Since I'm sure we can, as multiple proposals have provided such
solutions, I don't think that creating another DB is wise.  It adds
complex management burden to the operators and/or implementors that
isn't needed.

Khanh> And last but not least, as Uri Blumenthal pointed out
Khanh> last week, re-use is only one of the two problems we are 
Khanh> trying to solve here.  The second problem is USM use of 
Khanh> long-term keys for encryp & MAC.

We've selected encapsulation as a transport mechanism, which means
we'll likely be using that for the encr and message auth keys.  That
just leaves user authentication, which we should be using other
existing frameworks for (without modification or duplication if at all
possible, which it is).

-- 
Wes Hardaker
Sparta, Inc.

---

From: "Wayne Kading" <[email-masked]>
Date: Tue, 24 May 2005 20:09:56 -0500

Wes,

I believe that addressing the USM security issues identified below in
Khanh's message are very significant.  The next to the last question in your
survey indicates that even if all proposed reuse authentication mechanisms
were provided, that from a third to a half of the users polled would still
need to support SNMPv3/USM.  Therefore, I feel this area needs to be
addressed for both security and market penetration reasons.

Wayne

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Wes Hardaker
Sent: Tuesday, May 24, 2005 3:20 PM
To: Khanh Nguyen (khanhvn)
Cc: [email-masked]
Subject: [Isms] Re: Leverage existing infrastructure

-- 
Wes Hardaker
Sparta, Inc.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Khanh Nguyen (khanhvn)
Sent: Tuesday, May 24, 2005 3:00 PM
To: Wes Hardaker
Cc: [email-masked]
Subject: [Isms] RE: Leverage existing infrastructure

> Maybe someone other than you will disagree with me about 

.
.
.

.
.
.

Regards.

Khanh

---

From: Wes Hardaker <[email-masked]>
Date: Tue, 24 May 2005 22:36:23 -0700

>>>>> On Tue, 24 May 2005 20:09:56 -0500, "Wayne Kading" <[email-masked]> said:

Wayne> I believe that addressing the USM security issues identified
Wayne> below in Khanh's message are very significant.

I agree with this entirely.  I have always complained quite vocally
about USM's security because it doesn't provide a number of things
that I'd like it to do.  But I'm more picky than most too.

Wayne> The next to the last question in your survey indicates that
Wayne> even if all proposed reuse authentication mechanisms were
Wayne> provided, that from a third to a half of the users polled would
Wayne> still need to support SNMPv3/USM.

That result always confused me some.  I'm not sure why USM would still
be used.  Potentially because it was satisfactory to them, or
potentially because they didn't understand the question.

Let me state carefully:

1) I would like a better security solution that USM provides, but
   we'll be getting that through the encapsulation mechanisms we've
   been discussing and thus I haven't talked about it.

2) I do want to reuse authentication databases that exist today (which
   is why SBSM was designed the way it was.  A few things were
   sacrificed in order to get maximum flexibility).

3) I do not think that developing another SNMP-centric scheme is
   beneficial.  I don't care if it's done, as long as it's not
   required.  LPSK, as is, requires it which is all I've ever said I
   disagree with.  It requires a separate authentication system for
   SNMP.  You must keep separate information around to authenticate
   SNMP users, which I don't think is useful when trying to solve #2 above.

-- 
Wes Hardaker
Sparta, Inc.