Subject: [Isms] prague meeting minutes

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 20 Apr 2007 12:12:06 +0200

Hi,

the ISMS meeting minutes can be found at:

http://www3.ietf.org/proceedings/07mar/minutes/isms.txt

Please take a look and let me know if something needs to be changed.

/js

-- 
Juergen Schoenwaelder		 Jacobs University Bremen
<http://www.eecs.iu-bremen.de/>	 P.O. Box 750 561, 28725 Bremen, Germany

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

---

From: "tom.petch" <[email-masked]>
Date: Wed, 25 Apr 2007 15:08:02 +0200

Good to see compact  minutes.

I don't know what was said at the meeting about issues #1 to #6 so this may be
matters arising but the minutes seem somewhat at variance with the discussions
on the list beforehand.

Issue #1 I thought agreed that responses MUST rather than SHOULD go back on the
same channel else there was a security exposure
but that that linked into Issue #3 which on the list was about session reuse
rather than 'transport does not know the difference between requests and
notifications' and seemed to peter out without reaching a consensus. (In
passing, this referenced the use of ports 161 and 162 which leaves me confused
in a ssh tranport context so I am posting that separately).

Tom Petch

---

From: "David Harrington" <[email-masked]>
Date: Wed, 25 Apr 2007 12:51:52 -0400

Hi,

The minutes loook good. There are a couple corrections, and some
additonal explanation that might help others understand them better.

In the minutes, it says "Dave went through the resolution of the
transport mapping model last call comments:" There is no "transport
mapping model" document; There is a Transport Subsystem, a Transport
Security Model, and an SSH Transport Model. The discussion at that
point in the presentation was about the Transport Subsystem document
last call.

Issue#1:

The Transport Subsystem architecture document will reflect the SNMPv3
WG's decision that **architecturally** this is a SHOULD.
The decision is security-model-dependent, and the Transport Security
Model will make it a MUST.

<explanation>
The Transport Subsystem architecture document will avoid adding CLRs,
and continue to reflect the SNMPv3 WG's decision that
**architecturally** it is a SHOULD, because there may be future
extensions (e.g. new security models) where, for some acceptable
reason, it is not a security exposure and therefore not a MUST. We
should assume that designers of future security models will be just as
smart as we are, and given the technologies and best current practices
at that time, will make the right decisions for their security models.

The WG reached consensus that this is a security issue; the security
models are the right place to address this issue. For USM and TSM,
this mismatch could be a security exposure, so they make #1 a MUST. In
TSM, the use of the same transport parameters is addressed in section
4.2, bullet 1), where the transport parameters are extracted from the
securityStateReference. 

To resolve the interrelationship of #1 with #3, the unpublished
updated draft adds another parameter to the tmStateReference to tell
the transport model that this must be the same session that the
request came in on, not a new session identified by the same
parameters (transportdomain/address,securityname/level).
</explanation>

Issue #3:

Only the transport model knows about transport sessions, and the
transport model does not know the content of the pdu, so it cannot
tell the difference between a request/response and a notification.
What the transport model can tell is what transport address and what
securityName it is told to send to (by the SNMP application). If the
**application** wants to use different sessions for different types of
pdus, then it can do so by using different transport addresses or
different securityNames.

Part 3. 

There is a fourth option that isn't mentioned in the minutes - d) the
development of a new access control model. But development of a new
access control model is out of scope of the current charter.

dbh

---

From: "tom.petch" <[email-masked]>
Date: Fri, 27 Apr 2007 18:17:32 +0200

Yes that is much clearer on SHOULD and MUST.  From the minutes, or from the list
discussion of the issue tmsm#1, I would not have known that this is what we
agreed but I do concur with the agreement.  (I hope that Wes does too, since it
was he who made me aware of the significance of MUST).

I agree too that when the application is able to choose the session. then it
does so by transportAddress and securityName to which I would add, at least at
the
architectural level if not for all models, securityModel and securityLevel.

Tom Petch

----- Original Message -----
From: "David Harrington" <[email-masked]>
To: "'tom.petch'" <[email-masked]>; <[email-masked]>;
<[email-masked]>
Sent: Wednesday, April 25, 2007 6:51 PM
Subject: RE: [Isms] prague meeting minutes

---

From: "David Harrington" <[email-masked]>
Date: Fri, 27 Apr 2007 14:38:46 -0400

Hi,

The transport session is NOT specified by securityModel; the transport
model does not know about securityModel. The securityModel value is
meaningful in the messaging subsystem, the security subsystem, the AC
subsystem, the application subsystem, and the dispatcher, but not in
the transport subsystem. 

On an incoming message, the securityModel is not known until the MPM
extracts it from the message; the tmStateReference cache prepared by
the transport model does not contain the securityModel. 

On outgoing, the securityModel may be involved in choosing the
transport model and transport address and the security model can set
these variables from the securityStateReference, for use by the
transport model, but the value of the securityModel variable is not
used by the transport model.

I used to think this was meaningful in transport as well, but realized
it could not be, and removed references to it. If you spot a place in
the drafts where securityModel is used in the transport model, please
point that out to me so I can fix it.

dbh

> -----Original Message-----
> From: tom.petch [mailto:[email-masked]] 
> Sent: Friday, April 27, 2007 12:18 PM
> To: David Harrington; [email-masked]; [email-masked]
> Subject: Re: [Isms] prague meeting minutes
>