Subject: RE: [Isms] Reminder: ISMS proposals due October 18th

From: "McDonald, Ira" <[email-masked]>
Date: Sun, 10 Oct 2004 09:14:00 -0700

Hi,

I'm strongly in favor of consideration of TLS
(or rather DTLS, per Eric Rescorla's draft, so
that connection-mode issues/behaviors are not
introduced).

I'm willing to be a co-editor, but we'd need
a more expert SNMPv3 co-editor too.  Perhaps
Juergen Schoenwaelder would be interested? 

Cheers,
- Ira, co-editor of Printer MIB v2 and Finisher MIB

PS - The latest draft of DTLS (19 July 2004) is:

ftp://ftp.ietf.org/internet-drafts/draft-rescorla-dtls-01.txt

Ira McDonald (Musician / Software Architect)
Blue Roof Music / High North Inc 
PO Box 221  Grand Marais, MI  49839
phone: +1-906-494-2434
email: [email-masked]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of Juergen Quittek
Sent: Sunday, October 10, 2004 10:01 AM
To: [email-masked]
Subject: Re: [Isms] Reminder: ISMS proposals due October 18th

--On 08.10.2004 14:16 h -0400 Ken Hornstein wrote:

> Howdy everyone,
>
> This is just a friendly reminder to everyone that ISMS candidates
submissions
> are due by October 18th (the cutoff for -00 submissions for the upcoming
> IETF).  Submissions do not need to be full-fledged, but should at least
give
> a general overview of the proposed solution.

At the BoF session in San Diego, five proposals were under discussion:

  - EUSM - External User security Model
    draft-kaushik-snmp-external-usm-00.txt
  - KSM - Kerberos Security Model
    draft-hornstein-snmpv3-ksm-02.txt
  - SBSM - Session-Based Security Model
    draft-hardaker-snmp-session-sm-02.txt
  - MIASMA - Minimally Integrated Access Security Module Application
    <http://www.ietf.org/proceedings/04aug/slides/isms-6/index.html>
  - TLS - Transport Layer Security
    no presentation but some participants considered this as a candidate

For EUSM, KSM and SBSM we have current Internet drafts and I think
all of them are sufficient for evaluating the proposal (although
more elaboration would be desirable in one or the other case).

There has been no visible activity concerning MIASMA and TLS.

Does anybody have a strong feeling that these should be considered
in our evaluation of proposals?  If yes, please speak up on this
list and/or contact Randy Presuhn ([email-masked])
for MIASMA or Juergen Schoenwaelder ([email-masked])
for TLS.

> In addition to this deadline, if you want your proposal considered as a
> candidate by the WG, you must respond to this note to the WG mailing
> list with the file name of the proposal draft.

Please do so also for the three proposals where there are already I-Ds
available.  We need a contact person for each proposal who is willing
to answer questions from the evaluators.  (In the IPFIX protocol
evaluation we called these people 'protocol advocates'.)

Thanks,

    Juergen
-- 
Juergen Quittek        [email-masked]       Tel: +49 6221 90511-15
NEC Europe Ltd.,       Network Laboratories        Fax: +49 6221 90511-55
Kurfuersten-Anlage 36, 69115 Heidelberg, Germany   http://www.netlab.nec.de

_______________________________________________
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: Wes Hardaker <[email-masked]>
Date: Sun, 10 Oct 2004 19:23:24 -0700

>>>>> On Sun, 10 Oct 2004 09:14:00 -0700, "McDonald, Ira" <[email-masked]> said:

Ira> I'm strongly in favor of consideration of TLS (or rather DTLS,
Ira> per Eric Rescorla's draft, so that connection-mode
Ira> issues/behaviors are not introduced).

Part of the motivation the ADs had in making a early deadline was to
not delay for protocol options that don't have energy behind them.  In
my view, there are two solutions which meet my security needs: SBSM
and the potential TLS.  Thus, I would love to see a TLS solution
documented so we should consider it.  Eric's draft, however, is not a
solution that can be considered by the WG, IMHO.  It is a building
block (a very good one), but it itself is not complete.  There are
many other issues to be worked out.

I guess the chairs will have to decide what a minimum candidate must
consist of.  But just saying "lets use TLS" isn't sufficient, IMHO
without a better description of how it will be used, how
authentication will be done within it, how it will be passed to the
SNMPv3 layer, how any other SNMPv3 specific things will be done on top
of it (such as engineid learning), etc.  I think all these problems
are solvable, and I'd encourage someone to put together a quick draft
describing the architecture they'd like to propose that solves the
whole problem not just the transport problem.

-- 
Wes Hardaker
Sparta