Subject: Re: Re: [Isms] Discussion: Architecture direction for ISMS

From: Kaushik Narayan <[email-masked]>
Date: Fri, 25 Mar 2005 11:56:08 -0800

Hi Wes,

We are looking at using SNMP transport for the Key Setup Protocol
however we still believe the most important design consideration for
EUSM is to re-use existing security protocols the includes taking
advantage of as much of the existing USM works as possible and to
use existing security frameworks such as the GSSAPI.

Here is our summary of the three proposals.

------------------------------------------------------------------------------
              || Security Protocol ||   Key Setup Transport ||
              || Existing |  New    ||   SNMP   |     TLS       ||
------------++-----------+-----------++-------------+----------------++
   SBSM  ||             |   x        ||     x        |                  ||
------------++-----------+-----------++-------------+----------------++
   TLSM   ||    x       |             ||               |       x         ||
------------++-----------+-----------++-------------+----------------++
   EUSM  ||    x       |             ||     x        |                  ||
------------++-----------+-----------++-------------+----------------++

regards,
  kaushik!

> >
> > >>>>> On Mon, 21 Mar 2005 17:47:45 -0800, Kaushik
> > Narayan <[email-masked]> said:
> >
> > Kaushik> We believe that use of in-band and
> > out-of-band keying is not
> > Kaushik> the most important difference between EUSM
> > and SBSM.
> >
> > This is a different argument than you've been
> > previously making.  One
> > of the whole purposes of this discussion was to come
> > to agreement on
> > something, namely an architecture first.
> >
> > In your response you didn't seem to state clearly if
> > you had
> > preferences for one or two of the architectures.  It
> > appears that
> > you're no longer solely considering an out-of-band
> > mechanism which is
> > a very good thing because if we can all agree to
> > move a "little bit"
> > we'll likely end up somewhere that we can at least
> > agree upon even if
> > it's not the ideal place for each of us.
> >
> > Kaushik> We believe the most important differences
> > are
> >
> > So, given that can we concentrate on a preferred
> > architecture first
> > and then battle the USM issue.  This is what we
> > agreed upon in MSP but
> > yet everyone seems to want to argue the USM case
> > instead.
> >
> > Kaushik> ... we had proposed the use of EAP for Key
> > Setup and we plan
> > Kaushik> to suggest the use of TLS or GSSAPI for Key
> > Setup.
> >
> > Given the above statement, I originally thought you
> > had meant either
> > out of band or in-band-underneath would be fine
> > (GSSAPI is out-of-band
> > sort of...  GSSAPI is really an API not an
> > architecture but the
> > current common mechanism (kerberos) is out-of-band).
> >
> > But having re-read what you've said I could see
> > someone proposing TLS
> > on the side to do out-of-band negotiation over TLS.
> > I assume this is
> > not what you're going to propose since it would be
> > somewhat unusual
> > but thought I should double check.
> >
> > So, if you had to pick two (or one) of the
> > architectures (*not*
> > solutions for those architectures) it sounds like
> > you're at least
> > willing to consider "encapsulation" (TLS like) or
> > "out of band" (EAP
> > like) architectures?
> >
> > It sounds like we're (the group as a whole) actually
> > converging on an
> > architecture which is acceptable to everyone, which
> > is a really really
> > good thing.
> >
> > --
> > 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: Fri, 25 Mar 2005 13:25:13 -0800 (PST)

HI,

I don't understand your classification below, since SBSM
uses the existing auth and priv protocols defined for
USM. That is, it uses the same procedure as specified
in RFC 3414, sections 6.2.4 and 6.3 when the HMAC-MD5-96
authentication protocol is being used. Likewise, it uses the
same procedure as specified in RFC 3414, sections 8.2.4 and
8.3 for the DES protocol. In general, going through RFC 3414 
sections 6, 7, and 8, one simply subsitutes "session key"
for "user key" (and "session identifier" for "userName",
and you get what SBSM does. 

> Here is our summary of the three proposals.
Regards,
/david t. perkins

---

From: Wes Hardaker <[email-masked]>
Date: Sat, 26 Mar 2005 22:36:44 -0800

>>>>> On Fri, 25 Mar 2005 11:56:08 -0800, Kaushik Narayan <[email-masked]> said:

Kaushik> We are looking at using SNMP transport for the Key Setup
Kaushik> Protocol

Ok, this is a big improvement because I think it means that the WG is
actually much closer to consensus because we may have the ability to
eliminate the external keying scenario.  Does anyone still feel
attached to this, or can we now concentrate on either underneath
(TLS/SSH-ish)  or internal (SBSM or internal SASL or ...)?
Eliminating one would be a decent step forward.  (Please correct me if
I'm misreading you)

Kaushik> however we still believe the most important design
Kaushik> consideration for EUSM is to re-use existing security
Kaushik> protocols the includes taking advantage of as much of the
Kaushik> existing USM works as possible and to use existing security
Kaushik> frameworks such as the GSSAPI.

Yes, you've made that clear.  Though the WG decided in MSP to discuss
architecture first before discussing *how* to do it.  Reusing as many
existing things vs not is certainly a discussion that we'll have.  I
agree it's a very important one.  But as I've stated before, all the
architectures could reuse USM security and could reuse existing
frameworks.  The consensus in MSP was to select an architecture before
jumping to a solution.  The good news is that we may be closer to
doing that, at which point we can discuss your above points without
getting sidetracked.  We have until the end of April to decide on an
architecture and if we get sidetracked into solution details then we
will be out of luck entirely.

-- 
Wes Hardaker
Sparta

---

From: Kaushik Narayan <[email-masked]>
Date: Mon, 28 Mar 2005 18:26:34 -0800

Hi David,

We classified the definition and usage of SBSMInit1, SBSMInit2,
SBSMInit2Encr, SBSMInit3 and SBSMRunning as new. In contrast,
both EUSM and TLSM are based on combining already-defined pieces
(both SNMP and non-SNMP) together in new ways.

We actually expanded the table with an additional column and
added some explanation for the columns. Please find the table
in attached text file.

The first column in this table refers the re-use of existing USM
protocol for message protection (confidentiality, integrity and
replay) more in terms putting together existing parts of USM in
different ways rather than defining new pieces. The first column
also refers to the use of existing security protocols for key
negotiation. Both TLSM and EUSM use existing security
protocols for key negotiation.

The second column of the table refers to the transport protocol
used to transmit regular SNMP Get/Set/Notify messages.
With SBSM and EUSM regular SNMP messages are transmitted
as either UDP or TCP messages just as they are at  the moment,
i.e., no change whereas for TLSM, they are transmitted in a TLS
session.

The third column of the table refers to the transport protocol used
for the key negotiation. This is the current focus of the WG discussion.
The current EUSM proposal uses an external Key Setup mechanism
which defines the transport but we are seriously considering the option
of performing the Key Setup using SNMP encapsulation especially if
that would help the WG to make progress.

We believe that the choice of the transport for key negotiation is
really based on the transport protocol for the SNMP messages
and we believe that the focus of the WG should be really based on the
first making a decision of the second column, i.e. whether we believe
that we need to use transport based security or security built into
SNMP. Once that decision is made, the next decision will have to
be made on the first column, i.e. whether we need to modify USM
and on the need to use existing security protocols already
defined within the IETF.

regards,
   kaushik!