Subject: [Isms] isms beijing meeting agenda

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 26 Oct 2010 09:10:55 +0200

Hi,

we have a meeting slot at the upcoming IETF meeting (Wednesday
15:10-16:10). The goal of the meeting is to have a technical
discussion of the proposed Kerberos security model, followed by a
rechartering discussion. I have uploaded a draft agenda:

http://www.ietf.org/proceedings/79/agenda/isms.txt

For those presenting the proposed Kerberos security model, please make
sure that I receive your slides well before the meeting (Wednesday
morning the latest) since we may have remote participants.

The chairs would also appreciate to receive input for the new charter
before the meeting, either complete proposals or just text fragments
covering suggested work items. It is also fine to iterate proposals on
this list, of course.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 26 Oct 2010 12:52:42 +0200

Having  a strawman proposal for a new charter would help focusing the
discussion on this point. 

Dan

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Juergen Schoenwaelder
> Sent: Tuesday, October 26, 2010 9:11 AM
> To: [email-masked]
> Subject: [Isms] isms beijing meeting agenda
> 
> Hi,
> 
> we have a meeting slot at the upcoming IETF meeting 
> (Wednesday 15:10-16:10). The goal of the meeting is to have a 
> technical discussion of the proposed Kerberos security model, 
> followed by a rechartering discussion. I have uploaded a draft agenda:
> 
> For those presenting the proposed Kerberos security model, 
> please make sure that I receive your slides well before the 
> meeting (Wednesday morning the latest) since we may have 
> remote participants.
> 
> The chairs would also appreciate to receive input for the new 
> charter before the meeting, either complete proposals or just 
> text fragments covering suggested work items. It is also fine 
> to iterate proposals on this list, of course.
> 
> /js
> 
> -- 
> _______________________________________________
> Isms mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/isms
>

---

From: Wes Hardaker <[email-masked]>
Date: Tue, 26 Oct 2010 07:57:18 -0700

>>>>> On Tue, 26 Oct 2010 09:10:55 +0200, Juergen Schoenwaelder <[email-masked]> said:

JS> The chairs would also appreciate to receive input for the new charter
JS> before the meeting, either complete proposals or just text fragments
JS> covering suggested work items. It is also fine to iterate proposals on
JS> this list, of course.

Here's a rough proposal for a new charter:

    The Simple Network Management Protocol version 3 (SNMPv3) provides
    message security services through the security subsystem.
    Previously the ISMS Working Group defined a Transport Subsystem, a
    new Transport Security Model, and a Secure Shell Transport Model,
    a TLS Transport Model, a method for authenticating SNMPv3 users
    via the Remote Authentication Dial-In User Service (RADIUS) and a
    method to dynamically provision the VACM from AAA services.

    Since the time of publication, the TLS Transport Model (TLSTM)
    [RFC5593] has been implemented by at least two vendors and
    interoperability tests have been conducted.  Also implemented by
    the vendors in order to support this transport was the components
    making up the transport subsystem [RFC5590], the Transport
    Security Model [RFC5591] and the Context EngineID Discovery
    Mechanism [RFC5343].  The results of the interoperability tests
    between the vendors needs to be documented and any work required
    to advance the documents to Draft standard needs to be undertaken.

    Additionally, new work will be undertaken to define a Kerberos
    Security Model (KSM) that can offer support for protecting SNMP by
    Kerberos Network Authentication Services.  Kerberos is a trusted
    third-party authentication protocol that provides a centralized,
    transport-independent mechanism for performing authentication,
    distributing authorization information, and securing traffic
    between a Kerberos instrumented client and server.

    The current goal of the ISMS working group is two-fold: to advance
    the TLSTM and other required RFCs (listed above) to Draft Standard
    and to develop and a method for securing SNMPv3 traffic using
    resources provided by the Kerberos Network Authentication Service.

    The new work must not modify any other aspects of SNMPv3 protocol as
    defined in STD 62 (e.g., it must not create new PDU types).

    The working group will cover the following work items:

    - Document the interoperability results from testing of the TLS
      Transport Model [RFC5593], the Transport Subsystem [RFC5590],
      the Transport Security Model [RFC5591] and the Context EngineID
      Discovery Mechansim [RFC5343] and advance the documents to Draft
      status.

    - Define a Kerberos Security Model for use with SNMPv3

    Goals and Milestones
    Dec 2010    Publish initial revised copies of RFC5593, RFC5590,
                RFC5591 and RFC5343 if changes are needed to the documents.
    Dec 2010    Publish an initial copy of a TLSTM implementation report
    Jan 2011    Submit the TLSTM implementation report any revised
                copies of the RFCs to the IESG for publication in
                February as Draft status.

    Nov 2010    Initial version of a KSM document
    ???         Submit documentation on the KSM to the IESG

-- 
Wes Hardaker
Cobham Analytic Solutions

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 27 Oct 2010 12:16:52 +0200

> Here's a rough proposal for a new charter:

Thanks for getting this going. I have modified your text to remove
some redundancy. For the TLS advancement, I have modified the timeline
a bit to be hopefully more realistic. I think we first need to have
the interoperability reports to decide which of the documents need
what kind of changes. I also added a WG last call as a separate
milestone plus some time to work through any WG last call comments.  I
think this looks more realistic and since we can't advance before six
months have passed, there is not much difference anyway.

For the Kerberos Security Model, I think there should be a short but
strong motiviation included in the charter explaining why a Kerberos
Security Model is needed in addition to what we have. This question
surely will be asked by the IESG (and it already has been asked).

And just to be clear about the process: The WG chairs will first
determine whether there is WG support for each of the proposed two
work items. Afterwards, we will discuss the charter text based on what
we are preparing now. In other words, the fact that we discuss
proposals of a potential new charter here does not mean that a
decision has already been taken that the WG will work on these two
items. We are just trying to be prepared. (I also changed the subject
line to make this hopefully clearer.)

/js

---

From: Wes Hardaker <[email-masked]>
Date: Wed, 27 Oct 2010 07:15:30 -0700

>>>>> On Wed, 27 Oct 2010 12:16:52 +0200, Juergen Schoenwaelder <[email-masked]> said:

JS> Thanks for getting this going. I have modified your text to remove
JS> some redundancy.

Much of the redundancy was due to me copying the format of the existing
charter, which was very redundant!

JS> For the TLS advancement, I have modified [...]

You didn't include your modified version in your post.

JS> I think this looks more realistic and since we can't advance before
JS> six months have passed, there is not much difference anyway.

The original draft versions of the SNMPv3 docs were sent to the IESG
before the 6 months had expired.  They just weren't published until the
6 month mark, and I was hoping to do the same not "be speedy" but
because I don't expect much work and don't see a benefit to dragging it out.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 27 Oct 2010 16:37:30 +0200

> You didn't include your modified version in your post.

There is an attachment; at least there was one when the email went
out.

> because I don't expect much work and don't see a benefit to dragging it out.

It is always possible to be faster than the milestones state on the
charter. ;-)

/js

---

From: Wes Hardaker <[email-masked]>
Date: Wed, 27 Oct 2010 09:28:38 -0700

>>>>> On Wed, 27 Oct 2010 16:37:30 +0200, Juergen Schoenwaelder <[email-masked]> said:

JS> There is an attachment; at least there was one when the email went
JS> out.

Doh!  Bad mail reader hiding that button from me so well.  Sorry.
-- 
Wes Hardaker
Cobham Analytic Solutions

---

From: "t.petch" <[email-masked]>
Date: Fri, 29 Oct 2010 12:40:30 +0200

----- Original Message -----
From: "Juergen Schoenwaelder" <[email-masked]>
To: "Wes Hardaker" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, October 27, 2010 4:37 PM

> > >>>>> On Wed, 27 Oct 2010 12:16:52 +0200, Juergen Schoenwaelder
> There is an attachment; at least there was one when the email went

There was still an attachment when it reached me:-)

I think that the references to not modifying STD62 are wrong in that that is no
longer the standard to which we work; rather, that has been updated by RFC5590
and so it is RFC5590 that we should now be respecting.

This is a very practical consideration with the current KSM draft which appears
to ignore RFC5590 totally.

Tom Petch

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 29 Oct 2010 14:10:30 +0200

On Fri, Oct 29, 2010 at 12:40:30PM +0200, t.petch wrote:
 
> I think that the references to not modifying STD62 are wrong in that
> that is no longer the standard to which we work; rather, that has
> been updated by RFC5590 and so it is RFC5590 that we should now be
> respecting.

I think we should be explicit about STD62 and RFC5590. Here is the new
text:

    The new work must not modify any other aspects of SNMPv3 protocol
    as defined in STD 62 (e.g., it must not create new PDU types) and
    it must be consistent with RFC 5590.

/js

---

From: "t.petch" <[email-masked]>
Date: Sat, 30 Oct 2010 18:24:07 +0200

---- Original Message ----- 
From: "Juergen Schoenwaelder" <[email-masked]>
To: "t.petch" <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, October 29, 2010 2:10 PM
>     it must be consistent with RFC 5590.

Looks good to me

Tom Petch