Subject: RE: [Isms] Comments: draft-ietf-isms-tmsm-02

From: "David Harrington" <[email-masked]>
Date: Mon, 19 Jun 2006 20:39:04 -0400

Hi 
 
comments inline.
(sorry for the html format; trying to respond in text-only would have
made things harder.

  _____  

From: Sumanth Channabasappa [mailto:[email-masked]] 
Sent: Thursday, May 25, 2006 5:52 PM
To: [email-masked]
Subject: [Isms] Comments: draft-ietf-isms-tmsm-02

Folks,
 
As a follow-up to volunteering for the review of
draft-ietf-isms-tmsm-xx, here are a set of preliminary comments, some
questions and requested clarifications. 
 
They are mostly a collective effort (most of them are from Josh
Littlefield and some from myself, as indicated in []).
 
regards
Sumanth

- [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.

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

---

From: "Sumanth Channabasappa" <[email-masked]>
Date: Fri, 23 Jun 2006 09:31:36 -0600

David et al, 
 
Some responses and comments inline

	- [C#1] 2.2.1 

	[Sumanth] Are TMSM TMSP and TMSM MPSP really independent as
defined in the figure?

	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. 

	[s] Understood. I would suggest adding a note at the end of the
diagram, if possible.

	- [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?

	[s] I was leaning towards the latter, keeping in mind that there
may be security requirements that need to be 'addressed' by all security
models in a uniform manner.

	"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."

	[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). 

	[s] Agree

	 

	 Thanks

	Sumanth