- [C#1] 2.2.1
[Sumanth] Are TMSM TMSP
and TMSM MPSP really independent as defined in the
figure?
Also see: comments on
2.2.2.2 (C#5) and 4.2 (C#8)
No. But ascii
art makes it hard to fit all connections within the line length limits of
an I-D.
They are connected,
through the cache references, passed through the
ASIs.
- [C#2] 2.3.1
[Sumanth] This leaves a lot to the security
model definitions. Can we make it a requirement for the security models to
define constraints listed here.
I'm not sure I
understand your concerns here. The TMSM only defines an architecture, and the
security models need to provide the details of the specification. But there
are certain behaviors we need to know are standardized regardless of the
security model being used. So do you want the TMSM to do less and give the
security models more freedom to define their behaviors, or do you want
the TMSM to impose additinal requirements on the security models, giving the
security models less freedom?
- [C#3] 2.3.3, 1st para
(pg 19):
"The cryptographic
protocols used to establish keys for a TMSM-based security model session
SHOULD ensure that fresh new session keys are generated for each
session."
[Josh] Would this rule out
TLS session resumption, which uses an abbreviated handshake to resume a cached
session? Shouldn't this be a
transport protocol security issue, not a TMSM issue?
[Sumanth] My assumption is
that 'session resumption' should be allowed (e.g. TLS). Can we include this
explicitly and have some considerations (when to use and when not
to).
Since this is a SHOULD
and not a MUST, I think there is room for a TLS resume to be included in a TLS
model. Given that there is a SHOULD here, the TLS model should justify when it
is acceptable to not follow the TMSM SHOULD. I think that would the right
place to discuss the TLS-specific option of session resumption (as well as in
security consdierations of such a TLS model).
- [C#4] 2.2.2.1, 4th para
(pg 14):
"Hence, the authentication
of a transport layer identity plays an important role and must be considered
by any TMSM, and user authentication must be available via the transport layer
security protocol."
[Josh] Should avoid
talking about "user authentication."
There are no "users" in the abstract model, only securityNames. Perhaps the requirement is for of some
form of peer principal authentication.
Yes.
- [C#5] 2.2.2.2, final
para (pg 15):
"This may be highly
undesirable, however, if it creates a dependency between a security model and
an access control model, just as it is undesirable that the TMSM approach
creates a dependency between a TMSP and an MPSP."
[Josh, Sumanth] While I
agree that interdependence between a security model and an access control
model is undesirable, I don't equate that with the dependency between a TMSP
and an MPSP. I think the latter
is unavoidable in cases where the transport provides all security functions,
even though SNMP expects them to come from the message processor. The SM-specific MPSP would seem to
have to be tailored to the TMSP capabilities in all cases. In fact, they might be bound together,
even though they provide two separate abstract interfaces.
The RFC3411
architecture does not permit having security provided at a lower layer. The
conceptual modularity is important to maintain, but we blew it, so now we need
to accommodate having security performed at different places depending on the
security model (TMSM vs USM). That's unfortunate, but unavoidable at this
point.
- [C#6] 2.3, 3rd para (pg
17):
"It is important to note
that the architecture described in [RFC3411] does not include a session
selector in the Abstract Service Interfaces, and neither is that done for this
architectural extension, so an SNMP application cannot select the session
except by passing a unique combination of securityName, securityModel, and
securityLevel."
[Josh, Sumanth] Add
"transport address" to the list of items used to select the session. This would then be consistent with the
text in 2.3.1.
done
- [C#7] 4.2 (pg
25):
[Josh] The TMSM is
described as an entity with an (abstract) interface with a specific TMSM-based
security model below it, but in general the TMSM isn't otherwise described as
a component. It would seem more
clear to talk about the TMSP here, or perhaps the TMSM TMSP, with the TMSP
providing sendMessage() and recvMessage(), and a security-model-specific TMSP
instance providing txMessage(), rxMessage(), openSession(),
etc.
[Josh] The value of the
layering between sendMessage() and txMessage(), and between recvMessage() and
rxMessage() (the layering between a generic TMSP and a SM-specific TMSP) is
not obvious.
It would seem, at the least, that
the securityModel would need to be passed to sendMessage() in order to allow
this generic layer to locate the specific TMSP. If this is retrieve by the generic
TMSP from the tmStateReference (implied by section 7), then section 7 must be
normative about some of the required content of
tmStateReference.
[Josh] Since the
recvMessage() ASI is implemented by the Dispatcher and called by the TMSP, it
doesn't seem to make sense that tmStateReference is an OUTPUT. It should be an INPUT, since I believe
it is produced by the TMSP and provided to the Dispatcher, as is also true for
the incomingMessage. The same
would seem to be true for the tmStateReference argument in rxMessage(). Similarly, why would sessionID be an
OUTPUT, indicating it is produced by the Dispatcher?
There has been
some discussion about whether to define a generic transport mapping
subsystem (which RFC3411 should have done), and then treat SSHSM-TPSM as
simply a transport mapping to SSH, and so on.
- [C#8] 4.2 (pg
26):
If the use of sessions is
hidden by the TMSP, then it isn't clear why the ASI to the SM-specific TMSP
provides openSession() and closeSession() mechanisms. Further, the sessionID is not INPUT to
any ASI other than closeSession(), so what is the point of allowing one to
open a specific session?
Similarly, what is the point of producing sessionID from the
sendMessage() call? The
Dispatcher has no obvious use for a sessionID (and no ASI to close a
session).
Eliminated sessionID.
The combination of transport and securityNML provide the needed index into the
LCD.
- [C#9] 6.2, para 4 (pg
28):
"[discuss] We need to
discuss what the meaning of authoritative would be in a TMSM environment,
whether the specific services provided in USM security from
msgSecurityParameters still are needed, and how the Message Processing model
provides this information to the security model via generateRequestMsg() and
processIncomingMsg() primitives."
[Josh] While
"authoritative", as relates to the setting of securityEngineID is defined
clearly in RFC 3412, I don't think TMSM can make any blanket statements about
whether securityEngineID (the authoritative SNMP entity) is needed by the
underlying security model. There
may be TMSM-based security models that model themselves on USM for
authentication of the connection originator (client), while using transport
mechanisms for authentication of the server, and require securityEngineID to
be used in a way similar to USM.
If it isn't used, then it would be up to each specific TMSM model to
state that.
Likewise, I think it's up
to the specific TMSM model to define the use of
msgSecurityParameters.
[Josh]
Regarding "authoritative",
this has been discussed on the mailing list and this is in agreement with the
current consensus (?) -- refer issue #1 on the mailing
list
Regarding
"msgSecurityParameters', this has been discussed on the mailing list and this
is in agreement with the current consensus (?) -- refer issue #2 on the
mailing list
Done.
-- [C#10] 8 & 9 (pg
29+):
[Josh] How does the
tmStateReference get into and out of the MPSP? Are the Dispatcher to MP ASIs
augmented to pass this reference?
Yes.
-- [C#11] 9 (pg
30):
[Josh] Now this text makes
me think that the openSession() and closeSession() ASIs were between the MPSP
and the TMSP. Or, does the MPSP
accomplish the actions described here against the TMSP by internal
interfaces?
Fixed so that
openSession() and closeSession() occur only via the
TMSP.
-- [C#12] 11 (Page 33,
34)
[sumanth]
"tmsmSessionSpinLock" -
usage is not very clear
"tmsmSessionMaxSupported"
- given the interpretation of zero is 'dynamic', what about the case when the
max is zero (resource constraints). Recommend changing to it a MAX value for
dynamic or something else
"tmsmSessionEngineID" --
implies that there is one Engine ID per session. Do we need to make this clear
elsewhere?
We need to decide what
needs to be in the MIB module yet. That will depend on whether we reach
consensus on the elements of procedure.
