Subject: [Isms] draft agenda for Minneapolis

From: Juergen Quittek <[email-masked]>
Date: Thu, 24 Feb 2005 17:52:33 +0100

Dear all,

Below please find a draft agenda for our Minneapolis session.

Any comments?

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

=============================================

Integrated Security Model for SNMP WG (isms)
IETF #62
Monday 7, 2005 : 1930-2200
============================================

Chairs:

Ken Hornstein   <[email-masked]>
Juergen Quittek <[email-masked]>

AGENDA:

  1) Agenda bashing, WG Status                     ( 5 min)

  2) Proposal Comparison                           (45 min)
     - presentation of
       draft-ietf-isms-proposal-comparison-00.txt

  3) Discussion of WG direction                    (30 min)
     - on which solution approach will the WG
       focus its efforts?

  4) Charter discussion                            (45 min)

  5) Update of the EUSM proposal (optional)        (20 min)
     - draft-kaushik-snmp-external-usm-02.txt

  6) Wrap up                                       ( 5 min)
     - action points, schedule for evalaution

INTERNET DRAFTS:

Comparison of Proposals for Integrated Security Models for SNMP
(Simple Network Management Protocol)
http://www.ietf.org/internet-drafts/draft-ietf-isms-proposal-comparison-00.txt

Transport Layer Security Model (TLSM) for the Simple Network
Management Protocol version 3 (SNMPv3)
http://www.ietf.org/internet-drafts/draft-schoenw-snmp-tlsm-01.txt

A Session-Based Security Model (SBSM) for version 3 of the Simple
Network Management Protocol (SNMPv3)
http://www.ietf.org/internet-drafts/draft-hardaker-snmp-session-sm-03.txt

External User Security Model (EUSM) for version 3 of the Simple
Network Management Protocol (SNMPv3)
http://www.ietf.org/internet-drafts/draft-kaushik-snmp-external-usm-02.txt

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

---

From: "David T. Perkins" <[email-masked]>
Date: Thu, 24 Feb 2005 12:58:27 -0800 (PST)

HI,

I would like to see a few changes made. 

Before item #2 below,
lets add a 10 minute review of the problem that is to
be solved and review of the operational scenarios.

Then, after item #3 below, add time to talk about
EVAL #2, since EVAL #1 is fatally flawed, and we
need to do another one, with probably a different
team.

As I pointed out, the -02 version of EUSM is radially
different from the -00 version, and closes the gap
between it and SBSM. Lets add a new item to see what
can be done to get a proposal that blends the two. 

The -02 EUSM depends on two NEW protocols - the
key setup protocol and the Key Request Protocol.
These are new, and a short presentation about them
would be useful.

Regards,
/david t. perkins

---

From: Kaushik Narayan <[email-masked]>
Date: Thu, 24 Feb 2005 18:24:43 -0800

Hi All,

We would like the clarify that EUSM -02 draft does not have
anything new. The use of EAP as the Key Setup Protocol
was the basis of our original proposal. The only thing that
has been changed in this draft is that we took the Evaluation
team's advice and explained how the proposal could support
authentication systems such as Kerberos, X.509 etc.

Also, there aren't any new protocols introduced in this revision.
In fact, it was an explicit design decision for EUSM that we
would use existing protocols like EAP/RADIUS.

regards,
   kaushik!

---

From: "David T. Perkins" <[email-masked]>
Date: Thu, 24 Feb 2005 18:44:43 -0800 (PST)

HI,

Interesting.... If it's the same, then it doesn't
support Kerboros, X.509 etc. nor local accounts.

However, I believe the proposal has really been changed.
It does, require two new protocols, which are the
key setup and key request protocols. Maybe, not
new from -00 to -02, but new, in that they are
not defined in RFCs on the standards track, nor is
there existing running code in commercial off the shelf
products that I'm of. 

I can't tell if you are open or not to creating a
blended approach using technology from EUSM and
from SBSM. What is your position on this?

What is your position on the three small changes
that I suggested in a previous EMAIL. What are
the pros and cons?

Regards,
/david t. perkins

---

From: Juergen Quittek <[email-masked]>
Date: Fri, 25 Feb 2005 10:49:33 +0100

Hi David,

> be solved and review of the operational scenarios.

I'd very much appreciate starting discussions on
different understandings of the WG goals and operational
scenarios as soon as possible on the mailing list.

It is a good idea to remind the WG of its goals and to
clarify them.  However, goals and operational scenarios
are the titles of sections 2.2 and 2.3 of the comparison
I-D.  So, I expect the presentation of the I-D to cover
these issues.

If you have a view that differs from what is stated in
the comparison I-D, then I suggest that you prepare
bring these issues to the mailing list and - depending
on the progress of the discussion - prepare some slides
stating your view.  If we do not agree on our goals and
operational scenarios, we will add this discussion to
the agenda.

> need to do another one, with probably a different

This issue fits well in #3.  During #2 there is time for
identifying flaws in the evaluation.  After we have got
an idea of the list of flaws and their severity, we can
discuss the issue in #3.

But anyway, let's try to progress the  discussion on
flaws of the evaluation I-D as far as possible on the
mailing list before the Minneapolis meeting.

> between it and SBSM.

Version -02 was not yet subject of the evaluation.
It is intentionally discussed at the end of our session.
We will discuss our WG direction rather independent
of this version.  However, if time allows we can discuss
at the end of the session whether or not this
modification of EUSM follows the way we want to go.

>                       Lets add a new item to see what

This discussion will be part of #3 and #4.  The
evaluation I-D came to the conclusion that neither
of the three proposals matches all recommendations.
It suggests taking EUSM as starting point for developing
an ISMS that also integrates features of the other
proposals.  We will discuss which features of the three
proposals need to be integrated.  You may call this
'blending' them.

> These are new, and a short presentation about them

I take this as a recommendation for Kaushik concerning
the outline of his presentation on suggested EUSM
modifications.

Thanks,

    Juergen

---

From: "David T. Perkins" <[email-masked]>
Date: Fri, 25 Feb 2005 08:34:34 -0800 (PST)

HI,

I appreciate your response, but I got lost in the
details. Were you going to change the agenda?

Regards,
/david t. perkins

---

From: Juergen Quittek <[email-masked]>
Date: Fri, 25 Feb 2005 20:05:31 +0100

Hi David,

> details. Were you going to change the agenda?

Your points:

  - 10 minute review of WG goals:
    Fits well in the current agenda.  It's part of #2 anyway.
    You are welcome to provide input for this, for example in
    form of slides.  Still, we should try to discuss this
    issue as far as possible before the meeting.

  - Talking about eval team#2:
    Fits well in item #3 (discussion of WG direction)
    Setting up a new eval team is a change of plan and
    needs to be discussed in #3.

  - EUSM -02:
    The presentation at the end is rather for information.
    I think we could focus on our main targets.  Whether or
    not the progress from EUSM -01 to -02 is useful for
    achieving our goals can be discussed after we made our
    decisions.

In summary: no visible change of the agenda, but your issues
are well covered.

Thanks,

    Juergen

---

From: Kaushik Narayan <[email-masked]>
Date: Fri, 25 Feb 2005 15:40:46 -0800

Hi David,

Please find my reply inline.

>there existing running code in commercial off the shelf

We am not sure about your above statement.

EUSM does not define new protocols but mandates the of use
existing protocols for Key Setup and Key Request. The introduction
of the terminology of Key Setup Protocol and Key Request Protocol
was done based on the recommendations to describe the EUSM
proposal in more generic terms.

To summarize EUSM continues to uses continues to uses EAP
(as defined in RFC 2278) as what we now call the "Key Setup Protocol" -
this term was not present in draft-kaushik-snmp-external-usm-01.txt, but
the use of EAP was there,  and the use of EAP is unchanged in
draft-kaushik-snmp-external-usm-02.txt. In other words, this is only a
change in terminology.

Similarly, in case we need to use the optimization of using a single
master session key to distribute keys to multiple SNMP engines,
then we will need to use the RADIUS as what we now call the
"Key Request protocol",  the use of RADIUS is unchanged and
still continues to be as defined in.

http://www.ietf.org/internet-drafts/draft-zorn-radius-keyreq-03.txt

As far as relation to existing RFCs and running implementation.

EUSM will use the EAP-TLS protocol defined in RFC2716 as the
EAP method to support authentication systems such as Kerberos,
X.509 and local accounts.

The PEAPv2 specification defined in

http://www.ietf.org/internet-drafts/draft-josefsson-pppext-eap-tls-eap-10.txt

will be used as the EAP method for key setup to support RADIUS.

EAP will use RADIUS transport for EAP as defined in RFC3579. In case
of Key Setup between SNMP engines using EAP-TLS, EUSM will use
the multi-hop PANA protocol as specified in

http://www.ietf.org/internet-drafts/draft-ohba-multihop-eap-00.txt

In case, we do not use the optimization of key generation for multiple
engines, then SNMP engines can obtain keys after Key Setup via
mechanisms described in RFC3579 for RADIUS authentication.

RFC2278, RFC2716, RFC3579 and PEAPv2 are fairly well implemented.
Multi-hop PANA is currently implemented part of 802.1x solutions.

>that I suggested in a previous EMAIL. What are

   If the WG were to decide that merging the two proposals was
   the way forward, then of course we would agree to do so, but we
   don't believe that is the best approach nor do we believe that the
   changes that you are suggesting are "small".

regards,
  kaushik!

---

From: Ken Hornstein <[email-masked]>
Date: Mon, 28 Feb 2005 11:23:02 -0500

>X.509 and local accounts.

(WG chair hat off)

Upon reading RFC2716, I've discovered that it only mentions Kerberos
(and Public Key) once.  Specifically, it says:

Through the use of EAP, support for a number of authentication schemes
may be added, including smart cards, Kerberos, Public Key, One Time
Passwords, and others. To date however, EAP methods such as [6] have
focussed on authenticating a client to a server.

It doesn't really mention how this will happen.  If you look at the EAP
document (RFC3748), it doesn't explain how you could use Kerberos or
PKI with EAP either (I looked at PEAP, but that seems to focus only on
protecting the EAP exchange, rather than doing certificate validation
as part of the EAP authentication).

Maybe I'm missing something, but it seems like there's a bit of handwaving
here.

--Ken