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

From: Michael Baer <[email-masked]>
Date: Mon, 02 May 2005 14:41:37 -0700

Given Ken's status of consensus message this may be too late, but in
any case,

IBK  yes  I think this would work best for the WG goals.  

EK  maybe  Could work, but I don't think it would work as well.  

OOBK  no  Could work, but I have doubts. (I'd really like
           this to be between a maybe and a no, i.e. less than EK
           but greater than no, but that's not a option in our
           voting style.)

>>>>> "Ken" == Ken Hornstein <[email-masked]> writes:

    Ken> ISMS members, There's been a lot of discussion recently on
    Ken> the mailing list about the pros and cons of different
    Ken> security models.  I think the discussion has been good, but
    Ken> unfortunately I don't think it's getting any closer to a
    Ken> consensus (I thank Robert for trying to draw things closer;
    Ken> unfortunately Juergen and I have been rather busy off-line,
    Ken> and I apologize for that).  I know that some on the mailing
    Ken> list have expressed a preference for choosing a security
    Ken> protocol first, but we've been tasked with choosing the
    Ken> architecture first, and I believe that is the appropriate
    Ken> approach.

    Ken> Anyway, I'd like to call for a consensus on the security
    Ken> architecture.  As we all know, the three choices are:

    Ken> - Out of band keying (the architecture used by EUSM)
    Ken> - In-bakd keying (the architecture used by SBSM)
    Ken> - Encapsulation keying (the architecture used by TLSM)

    Ken> What I would like to see is WG members express which
    Ken> architecture(s) they prefer (you can choose more than one,
    Ken> but please, don't choose all three).  Please feel free to
    Ken> state your reasons for your choices, but in the interests
    Ken> of reaching consensus in a reasonable timeframe, I am
    Ken> asking that WG members please refrain from commenting on
    Ken> other people's choices unless they feel that the person has
    Ken> stated a fact which is obviously wrong.

    Ken> Thanks for your time,

    Ken> --Ken

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

-- 
[email-masked]
Michael Baer

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

---

From: "Salowey, Joe" <[email-masked]>
Date: Tue, 3 May 2005 11:43:09 -0700

> Joe,
> 
> Your observations make sense to me for symmetric keying 
> approaches like Kerberos. However, I am having trouble 
> following them to your logical conclusion. I am stumbling 
> because I suspect that any asymmetric keying mechanism, such 
> as PKI, will also require changes to the SNMP packet formats, 
> perhaps including the addition of new fields. Since extending
> SNMPv3 to include both symmetric and asymmetric keying 
> technologies is an explicit goal of mine (i.e., I want SNMP 
> to leverage the major enterprise-wide authentication 
> systems), I don't understand why this particular argument 
> would lead us to prefer OOB keying. Or perhaps I am 
> overlooking something important? If so, I'd appreciate better 
> understanding your insights. Thanks.

[Joe] So you could integrate with public key in (at least) two different
ways.  

1) You could use a public key exchange to establish a shared secret that
is valid for several exchanges.  I believe this is essentially what all
of the proposals suggest doing and is similar to the way TLS, SSH and
IKE work.  In the case of an out-of-band approach the key exchange
protocol would execute outside the SNMP protocol and the resulting keys
would be configured in the SNMP engines.  The out of band key exchange
could be based on public key cryptography and credentials.  The same is
true for in-band and encapsulation except that the key exchange would
happen within SNMP.  As Kaushik mentioned the advantage with out-of-band
is the SNMP protocol does not have to understand how the keying happens.

2) You could protect each SNMP PDU using public key similar to what you
would do with an email message using SMIME or CMS.  In this case each
protocol message is protected with a different key which encrypted under
the senders private key.  I don't think anyone has suggested this since
it would be very complicated, computationally intensive, only work when
all parties had public key credentials, and probably result in really
long messages.