Subject: [Isms] ISMS session summary and draft minutes

From: Juergen Quittek <[email-masked]>
Date: Wed, 03 Aug 2005 18:25:50 +0200

Dear all,

Below please find a summary of our session yesterday.

Please find the detailed draft minutes at
<ftp://ftp.netlab.nec.de/pub/isms/IETF63/0-isms-minutes-ietf63.txt>.
Many thanks to Martin for taking the minutes!

We had a long discussion and probably not every statement was captured
correctly in the minutes.  Please check them.

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

===================================
IETF-63 ISMS Session Summary
Tuesday August 2, 14:00 h - 16:00 h
===================================

In April the WG achieved (very rough) consensus on using an
encapsulated keying architecture (as used by the TLSM proposal).
At this meeting the WG progressed the decision on a transport
protocol to be used by ISMS.  Candidate protocols were TLS+SASL,
SSH, DTLS, and BEEP.

Among the proposals, DTLS is the only one based on UDP.  Since
DTLS is not yet commonly deployed and not extensively tested,
it was eliminated from the discussion after the WG agreed that
UDP transport is not necessarily required for the ISMS solution.
For all of the remaining three protocols there was support in
the WG.  Among them, SSH had clearly the strongest support,
mainly, because SSH is already widely deployed and used in network
management and thus could best achieve the goal of integrating the
ISMS solution into existing security infrastructures.  Within the
session there was a consensus on choosing only one protocol as work
item and there was rough consensus that this protocol would be SSH.
The consensus still needs to be confirmed on the mailing list.

Decisions made:
  - ISMS will work on one transport protocol only
  - Use SSH as transport protocol

Action items:
  - confirm WG consensus on decisions on the mailing list (August)
  - draft new charter, discuss on mailing list (August)
  - start work on SSH-based solution

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

---

From: Juergen Quittek <[email-masked]>
Date: Thu, 04 Aug 2005 15:31:39 +0200

Dear all,

Juergen Schoenwaelder sent a lot of comments on the
draft of the session minutes (Thanks a lot Juergen!).
Please find an updated version at
<ftp://ftp.netlab.nec.de/pub/isms/IETF63/1-isms-minutes-ietf63.txt>

Please continue checking them and send your comments.

Thanks,

    Juergen

---

From: "David B Harrington" <[email-masked]>
Date: Thu, 4 Aug 2005 14:19:15 -0400

Hi,

The work done by Juergen and I on the "TLSM" proposal really is about
the architectural extension required to make a transport-mapping
security model (TMSM) viable. To differentiate a TLS security model
from a transport mapping approach, I prefer to have us all use the
term TMSM rather than TLSM, so we can keep TLSM to refer to a
TLS-specific security model.

dbh

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Juergen Quittek
> Sent: Thursday, August 04, 2005 9:32 AM
> To: [email-masked]
> Subject: Re: [Isms] ISMS session summary and draft minutes
> 
> Dear all,
>

---

From: "David B Harrington" <[email-masked]>
Date: Thu, 4 Aug 2005 14:55:46 -0400

Hi,

I'll try to improve the [DH] ... Lines, but I see that most o fmy
comments are not in the jabber log online. Don't know why.

(DH) We need UDP for certain purposes, but non UDP for other purposes
(DH) ...
Should be 
(DH) We need UDP for certain purposes, but non UDP can be used for
other purposes. We need UDP to troubleshoot broken networks, but TCP
would be good for downloading large tables when the network is running
fine. 

----
(ER) SSH is back on the list
(DH) ...
(EL) If Dave's point is that we can use what we have, it is fine.

I think this discussion has not been captured well, and it's hard to
determine the context of my comments. I beleive this was probably a
discussion about Netconf finding SSH limited for things like
notiifcations, and my point would have been that the SNMPv3
architectuire provides for multiple co-existing security models, so
notifications could always be sent using a different security model,
such as USM, than the request-response traffic, so it wouldn't
necessarily need to be in an SSH security model (although it would be
desirable).

[of course, since I was typing this into jabber in real-time, my
comment would have been somewhat shorter...
---
(DH) Pick a deadline!
Should be
[DH} let's get a proposal started. I'm willing to work on fleshing out
the SSH portion of TMSM IFFFF somebody with knowledge of SSH helps
craft the text. Who is willing to be the security-side co-editor for
an SSH document?
[DH] Add one item to the charter: do an SSH proposal and pick a
deadline.
[DH] I am willing to try to get a draft written by the end of August
if co-editors are available.
---
Because jabber comments were not being relayed to the meeting, the
meeting never heard comments from the group of people who volunteered
to edit the SSH draft, including the comments that an interim was a
no-go for most of the volunteer editors.

---
Many of the jabber comments never got relayed, and when they did they
were often not not very accuratekly relayed, and, since the note-taker
had to relay them, they were not included in the meeting notes. That
the jabber scribe was the same as the note-taker, and the same as the
relayer made this largely impossib;e. 

The isms jabber log at ietf.xmpp.org contains more details on what was
being discussed over jabber. The notes should probably reflect some of
those comments. I didn't bother making more comments because I knew
they wouldn't get relayed.

The log looks to be missing the first half hour or so of the meeting.
I logged in for the complete meeting, but the log is missing most of
the early part of the meeting. 

Support for jabber participants really should be improved in the
future for ISMS; the chairs really need to be more mindful of this, as
Sam pointed out on a number of occasions. The problems were similar
last time in ISMS.

David Harrington
[email-masked]

---

From: Juergen Quittek <[email-masked]>
Date: Mon, 15 Aug 2005 02:00:23 +0200

Dear all,

There is another update of the minutes of our meeting
with changes suggested by David Harrington and Bert Wijnen.

Please find it at
<ftp://ftp.netlab.nec.de/pub/isms/IETF63/2-isms-minutes-ietf63.txt>

Thanks,

    Juergen

---

From: Eliot Lear <[email-masked]>
Date: Mon, 15 Aug 2005 15:15:14 +0200

Juergen,

In the minutes, Sam Hartman is reported to have said the following:

> (SH) Speaking as an AD, requiring to come one solution focusing the
>      effort.

My recollection is that these were not Sam's words.  My further
recollection is that Sam said something closer to his "strong personal
preference [for one solution]", but that he did NOT require the working
group to come to consensus on one solution.

Sam, am I correct or do the minutes correctly reflect what you said?

Eliot

---

From: Sam Hartman <[email-masked]>
Date: Mon, 15 Aug 2005 14:17:19 -0400

>>>>> "Eliot" == Eliot Lear <[email-masked]> writes:

    Eliot> Juergen, In the minutes, Sam Hartman is reported to have
    Eliot> said the following:

    >> (SH) Speaking as an AD, requiring to come one solution focusing
    >> the effort.

    Eliot> My recollection is that these were not Sam's words.  My
    Eliot> further recollection is that Sam said something closer to
    Eliot> his "strong personal preference [for one solution]", but
    Eliot> that he did NOT require the working group to come to
    Eliot> consensus on one solution.

    Eliot> Sam, am I correct or do the minutes correctly reflect what
    Eliot> you said?

The minutes definitely do not reflect what I said; thanks for drawing
this to my attention.

As an AD, I think there needs to be one mandatory to implement
solution.  There can be other solutions, but that should be because
there is a market demand for the other solutions or because the other
solutions work in different environments. However if we have multiple
solutions it needs to be because we believe multiple solutions are
needed not because we are unable to make a decision between solutions.

--Sam

---

From: Juergen Quittek <[email-masked]>
Date: Mon, 15 Aug 2005 21:33:49 +0200

Eliot and Sam,

Thanks for the corrections.  I will update the minutes accordingly.

    Juergen