Subject: RE: [Isms] CALL FOR CONSENSUS: ISMS Architecture

From: "Salowey, Joe" <[email-masked]>
Date: Mon, 2 May 2005 17:37:10 -0700

> -----Original Message-----
> From: Wes Hardaker [mailto:[email-masked]] 
> Sent: Friday, April 29, 2005 7:58 PM
> To: Salowey, Joe
> Cc: Juergen Quittek; [email-masked]
> Subject: Re: [Isms] CALL FOR CONSENSUS: ISMS Architecture
> 
> >>>>> On Fri, 29 Apr 2005 17:56:46 -0700, "Salowey, Joe" 
> <[email-masked]> said:
> 
> Joe> The motivation for EUSM was to implement a solution with minimal 
> Joe> changes to USM.
> 
> For reasons I've still yet to see posted to the list, 
> although I've asked.
> 

[Joe] In-band and encapsulation approaches either require the addition
of new fields to SNMPv3/USM messages, changes to the processing of
SNMPv3/USM messages or both. 

> Joe> For this reason we choose to use out-of-band keying.  I am still 
> Joe> strongly in favor of out-of-band keying.
> 
> Every architecture could use USM underneath for traffic 
> protection, so that's not really a good argument for OOB, IMHO.
> 

[Joe] Out-of-band minimizes the change to SNMPv3 and USM.  An in-band
exchange has more impact on existing processing.

> Joe> I have not been convinced by any of the discussion that 
> out-of-band 
> Joe> keying is any more difficult or problematic than any of 
> the other 
> Joe> methods so I am opposed to both encapsulation and 
> in-band keying as 
> Joe> I believe they both will require more changes to existing USM 
> Joe> implementations.
> 
> If you want to use USM and if you assume it will be used then 
> it probably won't matter which architecture you pick because 
> the results of implementing any of the architectures could be 
> feeding the keys into USM.  This is truly identical for OOB 
> and for IB.  (there may be other reasons for not wanting to 
> pick one or the other, but compatibility with USM can be done 
> with either).  EK is less straight forward, though it could 
> be done that way but I'm not sure you'd want to.
> 
> Joe> If it is shown that another keying architecture is less 
> invasive to 
> Joe> USM or the working group decides that protection 
> mechanisms within 
> Joe> USM need to be replaced then I would reconsider my opposition.
> 
> Can you explain *why* the other architectures are more invasive?
> 
> Lets take a concrete example.  Consider one instance of IBK 
> that has already been defined (just for example, I'm not 
> arguing at the moment that it's the right choice for an IBK 
> implementation because it's not relevant here): SBSM.  The 
> results of the keying exchange of SBSM could simply result in 
> a USM principal ending up with the negotiated keys.  Can you 
> explain how that's affecting USM in some way that OOB wouldn't be?
> 

[Joe] In an in-band approach such as SBSM you need to add new fields and
processing to USM/SNMPv3. In an out-of-band approach that uses USM you
don't.

> --
> Wes Hardaker
> Sparta, Inc.

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

---

From: Wes Hardaker <[email-masked]>
Date: Tue, 03 May 2005 08:44:03 -0700

>>>>> On Mon, 2 May 2005 17:37:10 -0700, "Salowey, Joe" <[email-masked]> said:

Joe> [Joe] In-band and encapsulation approaches either require the
Joe> addition of new fields to SNMPv3/USM messages, changes to the
Joe> processing of SNMPv3/USM messages or both.

No it doesn't.

For in-band, if you do something within a new SNMPv3 security model
(which I realize you probably want but you haven't stated that
clearly) but pass the keys to a USM user at the completion of that
transaction, USM doesn't change at all.  It stays exactly the same.
USM could still be used to protect real SNMP PDU traffic.  Without
modification.  None what so ever.  Only the keying would be in-band.

For encapsulation, you can still use USM underneath in the SNMPv3 part
of the message (say with a security name selected during the
encapsulation exchange) if you so choose.  It would be a waste of
bandwidth but it could be done.  Heck, you could even process it like
you would a USM message if you wanted to burn the CPU cycles.  But you
wouldn't have to modify USM at all, hence you should be just as happy.

If you look at a device as a whole, you *must* modify something.
Somehow someway you need to modify it to get the new keys and/or new
exchange in there.  I don't think OOB has any improvement over the
size of that new code set.  In fact, in my case at least, I think it's
a huge hit over the other two possibilities.  In fact, if I was going
to pick a method that offered the least impact in both terms of
existing stuff in the box and not having to modify the agent I'd
probably pick encapsulation not OOB.  In OOB you still have to inject
the keys which takes a potentially entirely new service and
potentially code to get the keys installed into a running service,
plus potentially vendor interoperability or incompatibility as I've
spelled out previously.  It's a *huge* amount of work in my eyes to
support OOB.  So much so I'm not sure I could ever implement it in a
non-intrusive way.

I don't think comparing only the work required to modify an agent is
the right way to go.  You have to compare the work in modifying
everything needed within a device as well as everything needed within
a manager and potentially other software (radius servers, eg).

Joe> [Joe] In an in-band approach such as SBSM you need to add new
Joe> fields and processing to USM/SNMPv3.

As explained above, that's simply not true.  It would require no
modifications to USM if you wanted to use USM services to protect the
messages themselves.

-- 
Wes Hardaker
Sparta, Inc.