 |
 |
 |
 |
|
 |
|
 |
|
 |
|
 |
|
|
|
|
|
|
|
|
|
|
|
|
- [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)
- [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.
- [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).
- [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.
- [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.
- [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.
- [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?
- [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).
- [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
-- [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?
-- [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?
-- [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?
_______________________________________________ Isms mailing list Isms at lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms