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

From: "Salowey, Joe" <[email-masked]>
Date: Tue, 3 May 2005 14:07:15 -0700

It seems that in order for in-band key exchange to work you would need
to add data and extra processing to SNMP messages to perform the key
exchange.  For example SBSM defines more new ASN.1 SEQUENCES than what
is defined for USM.   In contrast an out-of-band approach like EUSM
defines none.  The amount of implementation work for out-of-band vs.
in-band will be difficult to quantitatively measure for different code
bases.  I do know that in our prototype we were able to leverage a lot
of existing code on agents, managers and AAA.  I primarily want to avoid
inventing a new key exchange protocol and I think we should make as much
re-use of USM as possible.  I would prefer not to burden SNMP
implementations with the added data and processing complexities of key
exchange that in-band requires.  If it came down to creating another
security model different than USM then I would prefer to see an standard
encapsulation mechanism such as TLS. 

Joe

> -----Original Message-----
> From: Wes Hardaker [mailto:[email-masked]] 
> Sent: Tuesday, May 03, 2005 8:44 AM
> To: Salowey, Joe
> Cc: Juergen Quittek; [email-masked]
> Subject: Re: [Isms] CALL FOR CONSENSUS: ISMS Architecture
> 
> >>>>> 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.
> 

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

---

From: Wes Hardaker <[email-masked]>
Date: Tue, 03 May 2005 14:37:26 -0700

>>>>> On Tue, 3 May 2005 14:07:15 -0700, "Salowey, Joe" <[email-masked]> said:

Joe> It seems that in order for in-band key exchange to work you would
Joe> need to add data and extra processing to SNMP messages to perform
Joe> the key exchange.  For example SBSM defines more new ASN.1
Joe> SEQUENCES than what is defined for USM.

I agree that in-band would obviously require more extensions to
exchange keys (hence the word "in" in "in-band").  However, you keep
stating that USM needs to be modified which is not true.  SNMPv3 will
need to be extended through the extension fields that already exist in
the protocol today (and thus it doesn't need to be modified, only
extended...)  USM wouldn't need to be touched at all.  That's my only
point and I'm tired of seeing it said that it would need to be
modified, because it wouldn't need to be.  Even SBSM as is, with a
complete replacement for the message security during PDU transmission,
doesn't modify USM at all.  It does make use of SNMPv3 extension
mechanisms though and I agree it requires new code in SNMPv3 stacks
[3190 lines of code in my prototype SBSM implementation for example].

Now, EK could require 0 modification to existing SNMPv3 stacks.

Joe> If it came down to creating another security model different than
Joe> USM then I would prefer to see an standard encapsulation
Joe> mechanism such as TLS.

We haven't begun to argue about whether something different than USM
is needed or not yet.  I agree that simplicity would be provided by
using an EK approach in order to achieve the needed security
modifications to packet-processing.  The downside is that it's less
versatile and would likely require TCP to support some authentication
services (eg, SSH).  Others may support UDP but aren't deployed at all
yet (DTLS) but that's likely not a big deal because neither is any
in-band approach (aside from kerberized SNMP  which is deployed and
used [1886 lines of code incidentally]).

-- 
Wes Hardaker
Sparta, Inc.