Subject: RE: [Isms] RE: working group last call on draft-ietf-isms-tmsm-05

From: "David Harrington" <[email-masked]>
Date: Fri, 2 Feb 2007 20:14:48 -0500

Comments inline.

dbh

> -----Original Message-----
> From: Wijnen, Bert (Bert) [mailto:[email-masked]] 
> Sent: Friday, January 12, 2007 11:43 AM
> To: [email-masked]
> Subject: [Isms] RE: working group last call on
draft-ietf-isms-tmsm-05
> 
> I have read and reviewd this document. Here are my comments.
> 
> First Kudo's to the authors/editors. Pretty good work.
> Although have quite a set of comments/questions, I think
> the document is in pretty good shape. 
> 
> But probably based on my (and other) comments (I have seen)
> one more rev may make sense.
> 
> - I am completely confused by 3rd para of sect 3.2.1
> 
>    In SNMPv2, there were many problems of side effects between
>    subsystems caused by the manipulation of MIB objects, especially
>    those related to authentication and authorization, because many
of
>    the parameters were stored in shared MIB objects, and different
>    models and protocols could assign different values to the
objects.
>    Contributors assumed slightly different shades of meaning
depending
>    on the models and protocols being used.  As the shared MIB module
>    design was modified to accommodate a specific model, other models
>    which used the same MIB objects would be broken.
> 
>   I wonder:
>   - which SNMPv2 do you mean? SNMPv2c ?? Something else? 
>     maybe you can use a citation/reference
>   - I have no idea which MIB objects you are talking about, 
> so I cannot
>     judege if anything was broken andd if so why/how.
>   - What are you rtying to convey or justifty in this para?
>   - is it needed at all?

Removed.
> 
> - I am also somehwta confusd by the next para (4th para in 
> sect 3.2.1):
> 
>    Abstract Service Interfaces (ASIs) were developed to pass model-
>    independent parameters.  The models were required to translate
from
>    their model-dependent formats into a model-independent format,
>    defined using model-independent semantics, which would not impact
>    other models.
> 
>   It probably has to do with the English here that seems pretty
weird 
>   to me (but then, my native tongue is not English).

Removed.
> 
> - IN sect 3.2.1 on page 8:
> 
>    Parameters have been provided in the ASIs to pass
model-independent
>    information about the authentication that has been provided.
These
>    parameters include a model-independent identifier of the security
>    "principal", the security model used to perform the
authentication,
>    and which SNMP-specific security features were applied to 
> the message
>    (authentication and/or privacy).
> 
>   Do we leave it up to the reader to connect/link the various
phrases
>   into securityName, securityModel and securityLevel? Why are we not
>   very clear and name the things as we have named them in 3411?

Removed the paragraph.

> 
> - Further in section 3.2.1, page 8:
> 
>    Parameters have been provided in the ASIs to pass
model-independent
>    transport address information.  These parameters utilize the
>    transportDomain and transportAddress
> 
>   Is that last sentence not finished?
>   And is it causing confusion? I wonder if this has any relation to
>   the TransPortDomain/TransportAddress TCs in RFC3419. I think not.
>   I think you are just saying that the model-independent parameters
>   transportDomain and transportAddress (as used in RFc3411) are
used.

Removed the sentence.
> 
> - The figure on page 9, when I compare it with the figure on page 24
>   of RFc3411, makes me wonder: 
> 
>      Are we completely doing away with RFC3417 ??
> 
>   I guess we're not completely doing away with it are we?
>   Maybe I'll find it further down in the document, but I fnot, we
may
>   need some words about that.

I don't know what WG consensus is on this issue. It has not been
discussed.
I assume the transport mappings in RFC3417 can be treated as transport
models, but we might want to do an actual update at some point.

> 
> - 2nd para in sect 3.2.2.1 , my comments inline
> 
>     The securityName MUST be bound to the mechanism-specific
> 
>   s/bound to/mapped from/ ?? is it really binding it or is it
mapping?

Done.
> 
>     authenticated identity, and this mapping MUST be done for
incoming
>     messages before the security model passes securityName to the
> message
>     processing model via the processIncoming() ASI.  This
translation
>     from a mechanism-specific authenticated identity to a
securityName
>     MAY be done by the transport model, and the securityname is then
> 
>   s/securityname/securityName/
Fixed.
> 
>     provided to the security model to be passed to the message
> processing
>     model.
> 
>   So I think it is passed via the tmStateReference, no? 
>   If so would it be usefull to say so? Or do we prefer to leave it
> vague?

Done.
> 
> - last para of sect 3.2.2.1
> 
>     If the type of authentication provided by the transport 
> layer (e.g.
>     TLS) is considered adequate to secure and/or encrypt the
message,
> but
>     inadequate to provide the desired granularity of access control
> (e.g.
>     user-based), then a second authentication (e.g., one 
> provided via a
>     RADIUS server) MAY be used to provide the authentication
identity
>     which is bound to the securityName.  This approach would require
a
>     good analysis of the potential for man-in-the-middle attacks or
>     masquerade possibilities.
> 
>   It does not say anything about at what point in the process 
> steps this
>   mapping from RADIUS authenticated identity to a securityName needs
>   to take place. Maybe we want to leave that open. But it seems to
me
>   that the least we can say is that: it MUST bde done for incoming
>   messages before the security model passes securityName to 
> the message
>   processing model via the processIncoming() ASI. 

I'm not sure that's true. If the goal is to get the identity for
access control, it really only needs to get the securityname before it
provides access control. If, for example, it uses RADIUS and does an
authentication of the user and gets the authorization data, it could
do this as part of the access control model. it doesn't need to be
bound to the securityModel of the message, does it? I haven't spent
time to consider the security implications of this, but I don't think
we need to force this to be done a particular way. Of course, we do
want to make sure the sender of the message is authorized to use the
credentials that will authenticate the RADIUS request.
 
> 
> - sect 3.2.2.2. starts with:
> 
>     A transport model that provides security services should take
care
> to
>     not violate the separation of authentication and authorization
in
> the
>     RFC3411 architecture.  The isAccessAllowed() primitive is used
for
>     passing security-model independent parameters between the 
> subsystems
>     of the architecture.
> 
>   That last sentence seems to put a big claim there. It is only ONE
of
>   the primitives (ASIs) for passing (xxx-model) independent 
> parameters.
>   I might word it as:
> 
>     RFC3411 architecture.  The isAccessAllowed() primitive is used
for
>     passing security-model independent parameters to an Access
Control
>     Model (like VACM) and passes Security Model independent
parameters
>     for the Access Control Model to use.

done
> 
> - Next para in sect 3.2.2.2 states:
> 
>     Mapping of (securityModel, securityName) to an access 
> control policy
> 
>   I think I would add securityLevel in there as well. It is clearly
> included
>   in the decision process (as per figure in sect 3.1 of RFC3415) and
>   is also security model related (some may not be able to do 
> a specific
>   level, like SNMPv1 over UDP cannot do authNoPriv or authPriv).
>   I see that you later state that some Access Control Models 
> (well your 
>   wording uses inconsistent terms from RFC3411, but anyway) MAY need
>   a securityLevel. So maybe that is why you left it out here, but
>   certainly, it is a required parameter on the isAccessAllowed().
Added securitylevel.

> 
> - To come back to terminology in sect 3.2.2.2. It states:
> 
>    An authorization model (in the access control subsystem) 
> MAY require
>    authentication by certain securityModels and a minimum 
> securityLevel
>    to allow access to the data.
> 
>   Mmm.. so now we also have an "authorization model" ??
>   I guess you do mean the Access Control Model (in the Access
Control
>   Subsystem) ??

Fixed. 

> 
> - sect 3.2.2.2
> 
>     Transport models that provide secure transport are an
enhancement
> for
>     the SNMPv3 privacy and authentication, but they are not a
> significant
>     improvement for the authorization (access control) needs 
> of SNMPv3.
> 
>   Are they an "enhancement"? Or are they an "addition" ??
>   I would say the latter.

>From Mirriam-Webster: "to increase or improve in value, quality,
desirability, or attractiveness"

Operators have complained that USM requires them to use yet another
user and key infrastructure and they want a solution that leverages
existing user and key infrastructures. The goal of ISMS is to provide
a solution that is more attractive to operators. So I think this is an
enhancement.

I wouldn't like to think I have spent all this time editing these
documents to provide just an additional solution that was not an
enhancement over what is already available. ;-)

>  
>   Also, the are an addition for "SNMP message privacy...". 
> You can also 
>   enhance SNMPv1 and SNMPv2c privacy with it.
>   Further, I believe that USM can also be used for as possible
SNMPv4,
>   and so again I do not see why you think it is SNMPv3 
> privacy specific.
>   or SNMPv3 specific w.r.t. aithorization.

You are making the assumption SNMPv3 refers to a message format here.
I was making the assumption SNMPv3 referred to the standard. 

This is one of the disadvantages of using "SNMPv3" in multiple ways. 
I'll try to make this less ambiguous by making it explicitly refer to
messaging. 

> 
> - sect 3.2.2.2
> 
>     A transport model must not specify how the securityModel and
>     securityName could be dynamically mapped to an access control
>     mechanism, such as a VACM-style groupName.  The mapping of
>     (securityModel, securityName) to a groupName is a VACM-specific
>     mechanism for naming an access control policy, and for tying the
>     named policy to the addressing capabilities of the data modeling
>     language (e.g.  SMIv2 [RFC2578]), the operations supported, and
> other
>     factors.  Providing a binding outside the Access Control
subsystem
> 
>   I learn new things everyday. Hopefully I can leanr something new
> again.
>   What is/are:
> 
>      the addressing capabilities of the data modeling language (e.g.
> SMIv2
> 
>   Am I the only one who is confused by that?

I changed it since you found it confusing. 
> 
>   And a few lines further:
> 
>     or Windows domains.  The preferred approach is to pass the
model-
>     independent security parameters via the isAccessAllowed() ASI,
and
>     perform the mapping from the model-independent security
parameters
> to
>     an authorization-model-dependent access policy within the access
>     control model.
> 
>   Why is this not the RECOMMENDED approach?
>   We did the architectural modularization with a purpose did we not.
>   SO I would be strong and say RECOMMENDED instead of "preferred"

Fixed. 
> 
>   Pls also change "authorization-model-dependent" into "Access
Control
>   Model dependent"

Done.
> 
> - sect 3.2.3, 5th para on page 13 states:
> 
>     When using a secure transport model, security parameters MAY be
>     provided through means other than carrying them in the 
> SNMP message.
>     The parameters MAY be provided by SNMP applications for outgoing
>     messages, and the parameters for incoming messages MAY be 
> extracted
>     from the transport layer by the transport model before the
message
> is
>     passed to the message processing subsystem.
> 
>   I am somehwat confused by the 2nd sentence. 
>   I thought that for an outgoing message the SNMP appas MUST provide
>   the required security parameters. Possibly you mean that in 
> cases like
>   a response they get picked up from the cached parameters of the
>   incoming request (to which is being responded), but I find the
> capitalzied
>   MAY confusing. It seems to say that for example a Comamnd
Generator
>   can choose to NOT pass any security parameters and would still be 
>   compliant? I am confused.

I removed the first part of the second sentence.

> 
> - section 3.3 and onwards talks about a "transport type" and 
> "transport
>   address". Is that intentionally deviating from transportDomain and
>   transportAddress as used earlier in the document? I.e. the 
> paramaters
>   being passed in the ASIs?

Changed to match the parameters
> 
> - last para of sect 3.3.1 (page 15/16) states:
> 
>     If a session can be reused for a different type of message, but
a
>     receiver is not prepared to accept different message 
> types over the
>     same session, then the message MAY be dropped by the 
> receiver.  This
>     may strongly affect the usefulness of session reuse, and
transport
>     models should define a standard behavior for this circumstance.
> 
>   Mmm... "type of message" ? I only see this term occur once 
> in RFC3411.
>   It basically is the PDU type. But OK, I can live with it.
>   I am worried about the fact that "a transport model needs to
define
>   standard behaviour for this". How/where does a transport model
>   know about the message type (or PDU type) ?? The pduType is passed
>   between Dispatcher and MP model (in the ASIs), but I do not see it
>   passed from the dispatcher to transport subsystem. Is the TM 
>   suppsoed to go dig into the PDU itself? I hope not.

Hmmm. I'm not sure how a transport model knows this. 
I am not a fan of session reuse, so my heart won't be broken if we
simply drop this whole thing, and the transport model finds the right
session by its transport address (e.g., port 161 or 162).
I'll add this to the open issues section.

> 
> - In your sect 4.2, I would add that the diagram is from RFC3411.
>   Oteghrwise people might think there was/is a change.

Done.
> 
> - In sect 4. You state that some info is missing in 4.6.1. 
> and 4.6.2 in
> 3411.
>   You then show (repeat) the diagrams from 4.6.1. and 4.6.2 in your
>   sections 4.1. and 4.2.
>   But no further diagram extension to "complete" them?
>   I am missing the purpose of this? Is that just me?
>   I had expected the completed diagram, no?
>   For example I had expected to see the sendMessage and recvMessage
>   in a renewed diagram.
> 
>   (By the way, why no use "receiveMessage" instead of "recvMessage"?
>    we have many long ASI names already, and I hate all these
>    abbreviation for no reason).

I am OK with that change. Done.

> 
> 
> - I am not 100% sure, but is it correct that section 5.1. about the
>   securityStateReference is not adding any new (or changing any
>   existing) information compared to RFC3411?
>   If so, I would prefer we state that explicitly.
>   If it does add something, pls make it clear what is being
> added/changed.

This is not defined, but it may include additional security parameters
related to the transport model.
> 
> - Section 5.2
>   I think (but it is not clear) that the transport model should save
>   a mapping from transport security/authentication ID to
seucirtyName
>   so the the Security Model can pick it up and pass it back as an
>   OUT parameter on the processIncomingMessage ASI,. no?

Yes, this information should be saved in one of the caches. The format
and contents of the caches are implementation-specific however, so I
don't know what information we can discuss. The transport model might
also need to know the authentication algorithm, the integity-checking
and encryption parameters, and so on. These are very much
transport-model specific. The way we deal with it is to provide two
caches - one for the request/response pair, and another for the
session-like mechanism. It is up to the implementer to decide what
goes where. Added to Open Issues for discussion.

> 
> - 6.2.  Processing for an Outgoing Message
> 
>    The sendMessage ASI is used to pass a message from the 
> Dispatcher to
>    the appropriate transport model for sending.
> 
>    statusInformation =
>    sendMessage(
>    IN   destTransportDomain           -- transport domain to be used
>    IN   destTransportAddress          -- transport address to be
used
>    IN   outgoingMessage               -- the message to send
>    IN   outgoingMessageLength         -- its length
>    IN   tmStateReference              -- reference to transport
state
>     )
> 
>   Would it be usefull to add a not that the tmStateReference is not
>   always filled out? Let us say that I have just started my SNMP
> manager,
>   now I am going to send my first SNMP GET Request. I would use
above
>   ASI (I think). But what is the content of tmStateRefrence here?
>   Will it be filled upon return?

I added some text about this. Good catch.
> 
>   I can see that when I want to call sendMEssage to send a 
> response that
>   the tmStateRefrence contains the info that came in on the request.

Yup.
> 
> - 6.3.1.  Processing an Incoming Message
> 
>   Is there any difference for an incoming response compared to a
>   incoming request? Not clear to me.

Not until you hit the message processing model, I think. The MPM keeps
track of outstanding requests to match up to the response.

> 
> - 7.  Security Considerations
> 
>    This document describes an architectural approach that would
permit
> 
>   I would: s/would permit/permits/
> 
> - I am not sure I understand why RFC2578 needs to be a normative
> reference

There used to be a mib here. Now we don't cite 2578 at all. Removed.

> 
> - I have not checked appendix A
> 
> - Appendix B says:
>     This appendix considers why a cache-based approach was 
> selected for
>     passing parameters.  This section may be removed from subsequent
>     revisions of the document.
> 
>   I recommend to keep this appendix. It will/may help us 
> remember (in 5
>   or 10 years from now) why we did this. So remove the 2nd sentence.

Done.
> 
> - I guess Appendix C will get removed ;-)

Once we resolve all open issues.
> 
> 
> NITS:
> 
> - page 4:
> 
>    the approach being proposed for NETCONF [I-D.ietf-netconf-ssh].
> 
>   change citation to [RFC4741]
>   I know you could not know the RFCnumber when rev 5 was done.
>   But if you do an update, then pls include this.

Done.
> 
> - Sect 3.1
>   Is there a good reason to list the threaths in a different order 
>   as is done in RFC3414 page 5?
>   Mmm... I see they are in the same order as in RFC3411 pages 6/7.
>   So ignore my rambling.
> 
> - Section 3.2.1
>   Mmm.. the terminology used looks similar, but not the same as
>   in RFC3411. And I wonder if it would not be better to use the
>   same terms. I would also use same capitlized words. In fact
>   you do use the RFC3411 terms in the figure on page 5.
> 
>   TMSM                               RFC3411
>   messaging subsystem                Message Processing Subsystem
>   application subsystem              Application(s)
>   access control subsystem           Access Control Subsystem
> 
>   I would also change "transport subsystem" to Transport Subsystem" 
>   just for consistency in capitalization. In fact in the 
> figure, and in
>   some other places you already do so.
> 
> - In section 3.2.1.1 I see a few cases of tautologie 
>   - USM model  (USM = User-based Security Model)
>   - USM security model

Fixed.

> 
> - Further in sect 3.1.1, my comments inlined in a copy of the text:
> 
>      3.2.1.1.  USM and the RFC3411 Architecture
> 
>      The following diagrams illustrate the difference in the
security
> 
>   mmm.. where are thos diagrams? Is a diagram not a drawing/figure
or
> some such?
>   or ist it just text?

Fixed.

> 
>      processing done by the USM model and the security processing
>      potentially done by a transport model.
> 
>      The USM security model is encapsulated by the messaging model,
>      because the messaging model needs to perform the following
steps
> (for
> 
>   I wonder if the "because" is correct. In any event, the 
> list below has
>   many things in it that have nothing to do with the fact that the
>   USM is encapsulated in the Message Processing Model (not that I
use
>   the RFC3411 term)
Modified the text.

Let me point out that the encapsulation has a significant impact. With
USM, you cannot provide the security functionality until after the MPM
has decoded some of the ASN.1 to determine the values in the message
header; the transport model approach doesn't require ASN.1 decoding
before it can provide most of the security functionality. The purpose
is to show that the order of the processing is different, and
different subsystems have responsibilities for certain functions of
the flow through an SNMP engine when using USM vs using a transport
security model.

>      incoming messages)
>      1) decode the ASN.1 (messaging model)
> 
>   I would change that in "determine the Message Processing Model"
>   now it sounds as if it is completely doing the ASN.1 decoding
before
>   it calls USM. It only partially does that.

Agreed. I was going for a simple bullet rather than complete accuracy
here.
This is meant to be a simple bullet list that shows the abstract
processing steps, and with a 69-column limit, it is hard to keep
things readable if I have to spell out every little detail and every
little conditional related to every abstract bullet. The detailed
specification of processing steps, with all the details and
conditionals, is documented elsewhere.

> 
>      2) determine the SNMP security model and parameters (messaging
> model)
>      3) decrypt the encrypted portions of the message (security
model)
>      4) translate parameters to model-independent parameters
(security
>         model)
> 
>   this step is completely inside Security Model, no?
>   in fact step 3,4,5 are all just one call from the Message
Processing
>   Model to the Security Model, namely the processIncomingMsg ASI
(Sect
>   4.4.2 in 3411)

They are not all completely inside the security model when using a
secure transport. Some of these specific steps happen in a different
order and in different subsystems, depending on whether you are using
USM or a secure transport.

> 
>      5) determine which application should get the decrypted
portions
>         (messaging model), and
> 
>   This is done outside of the Message Processing Model (even in the
>   figure on page 9 of tmsm document) namely it is "PDU Dispatch"
>   in the "Dispatcher"

The registration uses message-model-specific pduTypes. For incoming
messages, the MPM determines what pduType is contained in the message,
then the dispatcher matches it up to the registrations.
Modified this step to read "determine the pduType in the decrypted
portions (message processing model)".

> 
>      6) pass on the decrypted portions with model-independent
> parameters.
> 
>      The USM approach uses SNMP-specific message security and
> parameters.
> 
>   Not 100% sure what that last sentence means. Probably you mean to 
>   tell us that an SNMPv3 message does have a USM specific set of
>   security parameters. 

Yes; I am trying to describe the differences between USM and secure
transport. I rewrote the section to try to clarify this.

> The SNMPv3 message format is
>   specified in RFC3412 and indeed for has reserved/allocated a space
>   for ALL Security Model to pass Security Model specific parameters.
>   From RFC3412:
> 
>            -- security model-specific parameters
>            -- format defined by Security Model
>            msgSecurityParameters OCTET STRING,
>  
>   If some Security Model does not need it, then it can be the
>   zero-length OCTET STRING.

This is immaterial to the point.

> 
> - In sect 3.2.1.2, snippets of the text with my comments inline:
> 
>     2*)  translate parameters to model-independent parameters 
> (transport
>        model)
> 
>   Does that asterisk have special meaning? Or is it just a typo.
>   I guess the latter.

Carryover from RFC3411; removed.

> 
> 
>     3) determine the SNMP security model and parameters (transport
> model)
> 
>   Mmm... is that determined by the TM at the receiving end?
>   Is it then filled in in the SNMPv3 message? Or is it 
> checked against 
>   what is in there already?

Originally, the TM was going to determine the SM, but we changed our
minds on that point. Now it is taken from the message. I modified the
text.

> 
>     If a message is secured using non-SNMP-specific message 
> security and
>     parameters, then the transport model should provide the 
> translation
>     from the authenticated identity (e.g., an SSH user name) to the
>     securityName in step 3.
> 
>   Mmm... I think I would reword into:
> 
>     If a message is secured using secure transport layer, then the
> related
>     transport model should provide the translation from the
> authenticated
>     identity (e.g., an SSH user name) to the securityName in step 3.

> 
>   after all, "non-SNMP-specific message security" could also be
> something
>   that has nothing to do with the transport layer (I have no idea
what
> yet)
>   and so it would be strange to mandate that e TM would have 
> to fill our
>   parameters, no?

Fixed.

> 
>   But aside from that, I wonder if/how this works.
>   once we move from the Transport Model to the Dispatcher, then the
>   Dispatcher calls the Message Processinge Model via 
> prepareDataElements
>   ASI. That ASI has an OUT parameter for securityName. So what will 
>   happen if we have filled out the securityName in step 3?

The TM determines the securityName and securityLevel, and puts them
into the cache. The dispatcher calls the MPM, which calls the
appropriate security model. The security model extracts securityName
and securityLevel from the message securityParameter block (USM), or
the message header/MIB module (Community), or from the
tmStateReference cache (TSM), and passes them to the MPM to report in
the OUT parameter.  

>   
>   I guess, we want the Transport Model to map these
> transport-layer-security
>   parameters into model-independent security parameters, save them
in
> the
>   tmStateReference and then later, when the Message Processing Model
> calls
>   the Transport Security Model, they get filled in into the 
> securityName
>   (and other parameters). Assuming that I correctly 
> understand how these
>   transport layer security parameters get mapped, saved and 
> then passed
>   around, I think the steps in sect 3.2.1.2 may rather confuse
people.
>   If I completely mis-understand it, then I there are 
> inconsistencies in
>   your document, because in sect 6.1 on page 23, you state
> 
>     The OUT parameters of the prepareOutgoingMessage() ASI are used
to
>     pass information from the message processing model to the 
> dispatcher
>     and on to the transport model:
> 
>   And in the ASI on page 22, the securityName is still listed (as I
>   expected by the way) as an OUT parameter.

Hopefully the new text will be clearer.

>   
> - In sections 3.2.1, 3.2.1.1 and 3.2.1.2 you explain the 
> agent-side and
>   the process steps (and the order of those steps) for an incoming
>   message. I can easily see how to map the manager side for 
> the picture.
>   I wonder if it makes sense to check if we need to say anything
about
>   sending a (i.e. an outgoing) message? The sequence of steps there
>   is also different. Can people easily determine that based on these
>   3 sections?

This is just an overview of which subsystems have which
responsibilities, and the general flow of processing; it is not the
detailed elements of procedure.
An outgoing message would probably just reverse the order, unless you
get into all the detailed elements of procedure, where there are lots
of conditional flows depending on the PDUtype (trap vs inform vs
request vs response). If we try to document all the various
possibilities here, you won't be able to see the forest because the
trees will be in the way.

> 
> - Maybe it is my skill in English, but in sect 3.2.1.3, 
>   I would change
> 
>     After a transport layer tunnel is established, then SNMP
messages
> can
>     conceptually be sent through the tunnel from one SNMP engine to
>     another SNMP engine.  Once the tunnel is established, 
> multiple SNMP
> 
>   into:
> 
>     After a transport layer tunnel is established, then SNMP
messages
> can
>     be sent through the tunnel from one SNMP engine to the other
SNMP
>     engine.  Once the tunnel is established, multiple SNMP
> 
>   I am not sure if the word "conceptually" is needed/useful. 
> What do you
>   try to convey? For me, they can just be sent, no?

This would have been better as "After a conceptual transport layer
tunnel is established," since not all transport supports "tunnels" as
such. But I can live without the "conceptual" being there at all.

>   Also, toy cannot send the messages to just "another", but just to
>   one, namely the one you are conne3cted to, other engine. 
> 
>   Further, I would change:
> 
>     another SNMP engine.  Once the tunnel is established, 
> multiple SNMP
>     messages may be able to be passed through the same tunnel.
> 
>   into
> 
>     another SNMP engine.  Once the tunnel is established, 
> multiple SNMP
>     messages can be passed through the same tunnel.
> 
>   it is shorter, but also, the meaning is somewhat different 
> and clearer
>   I think (at least in my ear).

This might be transport-specific (think UDP as a transport model).

"Transport models MAY support sending multiple SNMP messages through
the same tunnel."

> 
> - sect 3.2.2.2
> 
>    RFC3411 architecture.  The isAccessAllowed() primitive is used
for
> 
>   Why is this now a "primitive" and while it is an ASI in the 4th
para
>   on page 12:
> 
>     independent security parameters via the isAccessAllowed() ASI,
and
> 
>   Pls try to be consistent. I see however that we did this also
>   on RFC341x document. SO feel free to ignore this one if you like.
> 
I changed them to ASI for consistency.

> - I think the first MAY on page 14 could be lower case, or maybe
>   even better could be replcaed by "can".
>   The capitalized MAY/MUST/SHOULD and such are for compliance 
>   information. I don't think that is the situation here, is it?

Fixed.

> 
> - I also see no reason for a capitalized MAY in the last para on
page
> 15.

This one does affect on-the-wire interoperability, so I think a MAY is
justified. An implementation would not be non-compliant because it
does this (i.e., it is "legal" for an implementation to do this.) 

> 
> - Last para in sect 3.3.3
> 
>   I think the first capitalized MAY would better be a lower case
may.

Changed to "might"

>  
> TYPOs:
> 
> - page 6, sect 3.1
>    Using a protocol in a manner for which it was not designed has
>    numerous problems.  The advertised security characteristics of a
>    protocol may depend on its being used as designed; when 
> used in other
> 
>   in last line: s/its/it/ ??

Fixed.

> 
> - 3rd para page 8:
>    The design of a transport subsystem must abide the goals of the
>    RFC3411 architecture defined in [RFC3411].  To that end, this
>    transport subsystem proposal uses a modular design that will
permit
>   s/abide/abide by/ ??

Either is valid. According to Merriam-Webster:
3 : to accept without objection <will abide your decision>
- abide by
1 : to conform to <abide by the rules>
2 : to acquiesce in <will abide by your decision> 
Changed to "accepts the goals".

> 
>   s/RFC3411 architecture/SNMP architecture/   ?? 
>      I can live with RFC3411 architecture though. I see it comes
back
> several
>      times. I find it strange though to name an architecure 
> after an RFC
> number.

Remember that RFC3411 is "An Architecture", not "The Architecture". I
try to not to refer to this as the "SNMP architecture", unless I
qualify it as the "SNMP Architecture described in RFC3411", even
though it is unwieldy. I usually just say the RFC3411 architecture.

>   
>   s/proposal//  --  by the time this is an RFC it is no longer a
> proposal is it?

Fixed.
> 
> - 4 para on page 8
>   the motivstion of developing transport models is to develop
support
>   s/motivstion/motivation/

Fixed.
> 
> - last para page 8
>   The RFC3411 architecture,and the USM assume that a security model
is
>    called by a message-processing model and will perform multiple
> 
>   s/,and/, and/
>   s/message-processing model/Message Processing Model/
>        I hope you get the gist here on consistency of 
> terms/terminology.

I get the gist; I hate all the capitals in the middle of the
sentences. I changed them to meet your request, but I think the
document looks awful as a result.

"This document describes a cache, into which the Transport Model
        puts information about the security applied to an incoming
message,
        and a Security Model can extract that information from the
cache.
        Given that there might be multiple TM-security caches, a
        tmStateReference is passed as an extra parameter in the ASIs
between
        the Transport Subsystem and the Security Subsystem, so the
Security
        Model knows which cache of information to consult."
Is the following any less clear? I think it is better English.
This document describes a cache, into which the transport model
        puts information about the security applied to an incoming
message,
        and a security model can extract that information from the
cache.
        Given that there might be multiple TM-security caches, a
        tmStateReference is passed as an extra parameter in the ASIs
between
        the transport subsystem and the security subsystem, so the
security
        model knows which cache of information to consult."

I think "messaging model" is just as clear as "Message Processing
Model". One way just makes it more verbose, and harder to fit things
into 69-column lines. But I did it your way.

> 
>   I think I would also do s/USM/Security Subsystem/

Fixed.
> 
> - section 4.4.
>     Some secure transports may have a notion of sessions, while
other
>     secure transports might provide channels or other session-like
> thing.
> 
>   s/thing/things/ ??

Changed to mechanisms.

>  
> - last para page 20
>     The information saved should include the model-independent
> parameters
>     (transportDomain, transportAddress, securityName, 
> securityModel, and
>     securityLevel), related security parameters, and other
information
>     needed to imatch the response with the request.  The Message
> 
>   s/imatch/match/

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

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

---

From: "Wijnen, Bert \(Bert\)" <[email-masked]>
Date: Mon, 5 Feb 2007 12:14:51 +0100

Thanks for the follow up. My comments/reactions inline 

> From: David Harrington [mailto:[email-masked]] 
> Sent: zaterdag 3 februari 2007 2:15
> To: Wijnen, Bert (Bert); [email-masked]
> Subject: RE: [Isms] RE: working group last call on 
> draft-ietf-isms-tmsm-05
> 
> Comments inline.
> 
> dbh
> 
of
objects.
depending
> >   - I have no idea which MIB objects you are talking about, so I 
> >     cannot judege if anything was broken andd if so why/how.
> > - I am also somehwta confusd by the next para (4th para in sect 
> > 3.2.1):
> > 
from
> >   It probably has to do with the English here that seems prettyweird

model-independent
These
authentication,
> >    and which SNMP-specific security features were appied to the
message
phrases
model-independent
used.
may
discussed.
> I assume the transport mappings in RFC3417 can be treated as 
> transport models, but we might want to do an actual update at 
> some point.
> 

Whatever we do, we need to say something about it. Because right now
it is unclear how we want to see the earlier TM from 3417. I do not
yet have a suggestion for text.

mapping?
incoming
message
translation
securityName
processing
vague?
> >     If the type of authentication provided by the transport layer
(e.g.
message,
> >     but inadequate to provide the desired granularity of access
control 
> >     (e.g. user-based), then a second authentication (e.g., one
provided via 
> >     a RADIUS server) MAY be used to provide the authentication
identity
a
> >   It does not say anything about at what point in the process steps
this
me
message
> I'm not sure that's true. If the goal is to get the identity 
> for access control, it really only needs to get the 
> securityname before it provides access control. If, for 
> example, it uses RADIUS and does an authentication of the 
> user and gets the authorization data, it could do this as 
> part of the access control model. it doesn't need to be bound 
> to the securityModel of the message, does it? I haven't spent 
> time to consider the security implications of this, but I 
> don't think we need to force this to be done a particular 
> way. Of course, we do want to make sure the sender of the 
> message is authorized to use the credentials that will 
> authenticate the RADIUS request.
>  

First, none of the ASIs doe prescribe a particular way of 
implementation. The ASIs are to pass stuff between 
modularized documents.

Second, although in theory it maybe OK to do it rigth before
access control, I personally think it is cleaner (from a
documentation modularity point of view) that it is done
as I suggested. All the other ASIs have the securityName as a 
paramter, and so I think it is more consistent if that paramter
is filled out before such a field is being passed around.

> >     care to
> >     in the
of
parameters.
for
Control
parameters
> >     Mapping of (securityModel, securityName) to an access control
policy
included
> >   is also security model related (some may not be able to do a
specific
> >   I see that you later state that some Access Control Models (well
your
> >    An authorization model (in the access control subsystem) MAY
require
securityLevel
Control
> >     Transport models that provide secure transport are an
enhancement for
significant
> >     improvement for the authorization (access control) needs of
SNMPv3.
> From Mirriam-Webster: "to increase or improve in value, 
> quality, desirability, or attractiveness"
> 
> Operators have complained that USM requires them to use yet 
> another user and key infrastructure and they want a solution 
> that leverages existing user and key infrastructures. The 
> goal of ISMS is to provide a solution that is more attractive 
> to operators. So I think this is an enhancement.
> 
> I wouldn't like to think I have spent all this time editing 
> these documents to provide just an additional solution that 
> was not an enhancement over what is already available. ;-)
> 

Peace... I still have my view, but it is not a real concern.

> >   and so again I do not see why you think it is SNMPv3 privacy 
> >   specific.
> I'll try to make this less ambiguous by making it explicitly 
> refer to messaging. 
> 
So why not just use "SNMP" instead of "SNMPv3" ?

subsystem
again.
model-
and
parameters
Control
> >     provided through means other than carrying them in the SNMP
message.
extracted
> >     from the transport layer by the transport model before the
message is
> >   the required security parameters. Possibly you mean that in cases
like
capitalzied
Generator
> I removed the first part of the second sentence.
But you have kept MAY 2 times?
I still find that confusing. lowercase would be fine, but now it
seems to tell me something about compliance.

a
> >     receiver is not prepared to accept different message types over
the
> >     same session, then the message MAY be dropped by the receiver.
This
transport
> >   Mmm... "type of message" ? I only see this term occur once in
RFC3411.
define
> I am not a fan of session reuse, so my heart won't be broken 
> if we simply drop this whole thing, and the transport model 
> finds the right session by its transport address (e.g., port 
> 161 or 162).

So how did it get included in the first place?
I guess there were some people who see a need for it?
If so, then we need to figure out how the transport would know
about it, or how this is/can be done otehrwise.

> This is not defined, but it may include additional security 
> parameters related to the transport model.

Then I would say something about that. Aka:
   the securityStateReference may include security paramters
   related to the transport model.
or some such. And I guess that a transport model would then have to
(MUST langauge) define any such parameters, no?

seucirtyName
> Yes, this information should be saved in one of the caches. 
> The format and contents of the caches are 
> implementation-specific however, so I don't know what 
> information we can discuss. The transport model might also 
> need to know the authentication algorithm, the 
> integity-checking and encryption parameters, and so on. These 
> are very much transport-model specific. The way we deal with 
> it is to provide two caches - one for the request/response 
> pair, and another for the session-like mechanism. It is up to 
> the implementer to decide what goes where. Added to Open 
> Issues for discussion.
> 

I'd say we need to just state that thuis is what we expect, and that
each specific transport model needs to be specific as to what kind
of data needs to be saved in order tolet aSecurity Model be able to
pick up the proper data that it needs.

> >    The sendMessage ASI is used to pass a message from the Dispatcher

> >    to the appropriate transport model for sending.
> > 
> >    statusInformation =
> >    sendMessage(
used
state
manager,
above
> >   I can see that when I want to call sendMEssage to send a response
that
> Not until you hit the message processing model, I think. The 
> MPM keeps track of outstanding requests to match up to the response.
> 

So maybe say something about that?
Or was it just me who wondered?
If it is/was clear to everyone else, then no need to add anything.
But if several other people wonder(ed) as well, then it would
be good to be 100% clear about it.

permit
> >     This appendix considers why a cache-based approach was selected
for
> >   I recommend to keep this appendix. It will/may help us remember
(in 5
> Once we resolve all open issues.

sure.
> >   just for consistency in capitalization. In fact in the figure, and

> >   in some other places you already do so.
> > 
security
or
> >   some such? or ist it just text?
> 
> Fixed.
> 
> > 
steps
> >     (for
> > 
> >   I wonder if the "because" is correct. In any event, the list below

> >   has
use
> >   the RFC3411 term)
> > 
> Modified the text.
> 
> Let me point out that the encapsulation has a significant 
> impact. With USM, you cannot provide the security 
> functionality until after the MPM has decoded some of the 
> ASN.1 to determine the values in the message header; the 
> transport model approach doesn't require ASN.1 decoding 
> before it can provide most of the security functionality. The 
> purpose is to show that the order of the processing is 
> different, and different subsystems have responsibilities for 
> certain functions of the flow through an SNMP engine when 
> using USM vs using a transport security model.
> 
> >      incoming messages)
before
> Agreed. I was going for a simple bullet rather than complete 
> accuracy here.
> This is meant to be a simple bullet list that shows the 
> abstract processing steps, and with a 69-column limit, it is 
> hard to keep things readable if I have to spell out every 
> little detail and every little conditional related to every 
> abstract bullet. The detailed specification of processing 
> steps, with all the details and conditionals, is documented elsewhere.
> 

Well, then at least add a note that states that this is not a detailed
list
but is only intended to .....your text ...

model)
model)
(security
Processing
(Sect
> >   4.4.2 in 3411)
> 
> They are not all completely inside the security model when 
> using a secure transport. Some of these specific steps happen 
> in a different order and in different subsystems, depending 
> on whether you are using USM or a secure transport.
> 

I understand that. But I think we're keeping our ASI, and so, 
in my view, the SecurityModel still determines it, albeit based 
on some cache in the case of a secure ransport, while it picks 
it up from the SNMP message in the case of USM.

portions
> The registration uses message-model-specific pduTypes. For 
> incoming messages, the MPM determines what pduType is 
> contained in the message, then the dispatcher matches it up 
> to the registrations.
> Modified this step to read "determine the pduType in the 
> decrypted portions (message processing model)".
> 
We both know/agree how it works (or so it seems from your response)
Sounds that your fix addresses my concern.

parameters.
parameters.
> Yes; I am trying to describe the differences between USM and 
> secure transport. I rewrote the section to try to clarify this.
> 

Need to see it before I can determine if it is better.

> This is immaterial to the point.
maybe so. I was not asking to add that text, I was trying to give
background
as to why I got confused by the last sentence, right under bullet 6).

(transport
model)
> >   Is it then filled in in the SNMPv3 message? Or is it checked
against
> Originally, the TM was going to determine the SM, but we 
> changed our minds on that point. Now it is taken from the 
> message. I modified the text.
> 
> > 
> >     If a message is secured using non-SNMP-specific message security
and
translation
related
authenticated
something
> >   that has nothing to do with the transport layer (I have no idea
what yet)
> >   and so it would be strange to mandate that e TM would have to fill
our
prepareDataElements
> The TM determines the securityName and securityLevel, and 
> puts them into the cache. The dispatcher calls the MPM, which 
> calls the appropriate security model. The security model 
> extracts securityName and securityLevel from the message 
> securityParameter block (USM), or the message header/MIB 
> module (Community), or from the tmStateReference cache (TSM), 
> and passes them to the MPM to report in the OUT parameter.  
> 

That is what I would expect. But that was not clear from the text.

transport-layer-security
in
> >   the tmStateReference and then later, when the Message Processing
Model 
securityName
> >   (and other parameters). Assuming that I correctly understand how
these
> >   transport layer security parameters get mapped, saved and then
passed
people.
inconsistencies in
to
dispatcher
> Hopefully the new text will be clearer.
Will check when I see it.

> >   
> > - In sections 3.2.1, 3.2.1.1 and 3.2.1.2 you explain the agent-side
and
> >   message. I can easily see how to map the manager side for the
picture.
about
> responsibilities, and the general flow of processing; it is 
> not the detailed elements of procedure.
> An outgoing message would probably just reverse the order, 
> unless you get into all the detailed elements of procedure, 
> where there are lots of conditional flows depending on the 
> PDUtype (trap vs inform vs request vs response). If we try to 
> document all the various possibilities here, you won't be 
> able to see the forest because the trees will be in the way.
> 
Let us add a statement/note then that explains the purpose of what
we are doing here and states that it is just rough and not a detailed
eop. Maybe even add that a specific transport model MUST provide the
detailed steps or elements of procedure (eop).

> >     After a transport layer tunnel is established, then SNMP
messages can
> >     another SNMP engine.  Once the tunnel is established, multiple
SNMP
> >     After a transport layer tunnel is established, then SNMP
messages can
SNMP
> >   I am not sure if the word "conceptually" is needed/useful.  What
do you
> This would have been better as "After a conceptual transport 
> layer tunnel is established," since not all transport 
> supports "tunnels" as such. But I can live without the 
> "conceptual" being there at all.
> 
> >     another SNMP engine.  Once the tunnel is established, multiple
SNMP
> >     another SNMP engine.  Once the tunnel is established, multiple
SNMP
> >   it is shorter, but also, the meaning is somewhat different and
clearer
> "Transport models MAY support sending multiple SNMP messages 
> through the same tunnel."
> 
lowercase "may" if you ask me.

for
para
and
page
> > 15.
> 
> This one does affect on-the-wire interoperability, so I think 
> a MAY is justified. An implementation would not be 
> non-compliant because it does this (i.e., it is "legal" for 
> an implementation to do this.) 
> 

???

may.
> >    protocol may depend on its being used as designed; when used in
other
permit
> 2 : to acquiesce in <will abide by your decision> Changed to 
> "accepts the goals".
> 
> > 
back
> >      several times. I find it strange though to name an architecure 
> >      after an RFC number.
> 
> Remember that RFC3411 is "An Architecture", not "The 
> Architecture". I try to not to refer to this as the "SNMP 
> architecture", unless I qualify it as the "SNMP Architecture 
> described in RFC3411", even though it is unwieldy. I usually 
> just say the RFC3411 architecture.
> 
Aha... so I see why you do it.
It still sounds/feels weird to me.

support
is
> sentences. I changed them to meet your request, but I think 
> the document looks awful as a result.
> 
>         puts information about the security applied to an 
> incoming message,
>         and a Security Model can extract that information 
> from the cache.
>         tmStateReference is passed as an extra parameter in 
> the ASIs between
>         the Transport Subsystem and the Security Subsystem, 
> so the Security
>         puts information about the security applied to an 
> incoming message,
>         and a security model can extract that information 
> from the cache.
>         tmStateReference is passed as an extra parameter in 
> the ASIs between
>         the transport subsystem and the security subsystem, 
> so the security
> I think "messaging model" is just as clear as "Message 
> Processing Model". One way just makes it more verbose, and 
> harder to fit things into 69-column lines. But I did it your way.
> 

Dave, for me it is just to get consistency between 3411 and this
document. Otehrwise I couldn't care less if it is capitalized or
not.

other
thing.
parameters
> >     (transportDomain, transportAddress, securityName, securityModel,
and
information

Bert

---

From: "David Harrington" <[email-masked]>
Date: Tue, 6 Feb 2007 01:13:28 -0500

Rev -06- is getting closer.

Comments inline. 

> yet have a suggestion for text.

Added text saying this was a supplement that updated 3411 and 3417.

> > >     If the type of authentication provided by the transport
layer

> So why not just use "SNMP" instead of "SNMPv3" ?

See the new text and see if that is satsifactory.

a
the
This
transport
RFC3411.
define
> about it, or how this is/can be done otehrwise.

Sessions are a transport-specific issue, and are controlled by a
transport model. A transport model has no idea which application has
requested that a message be sent; it typically only knows
transportDomain/Address and securityName/Model/Level. If a session
already exists that matches those parameters, it reuses it. The
transport model does not necessarily know whether the session was
first established to send a request or a notification.

I'm not sure if the transport model actually needs to deal with this.
The message MAY be dropped on the floor when a notification is sent to
a port that is enabled only for request/response traffic, or a request
was  sent to a port configured only for notification traffic, or an
agent sends a GET-request to an NMS. It seems unlikely a response
would be sent to a port unwilling to accept responses, since we
usually send the response back to the port the request came from. 

The message-processing model keeps track of outstanding
expectResponses, so it should probably be aware that no response
message was returned, when the remote node dropped a request message
(including inform) on the floor. If it was a trap, it would not be
expecting a response anyway. If it is an unexpected GET, there will be
no registered application for that pduType, so it would be dropped
anyway.

So it should probably be the message processing model or the
application that needs to know how to deal with dropped messages.

I removed the text that says a transport model needs to define a
stndard behavior.
> (MUST langauge) define any such parameters, no?

"The related security parameters may include transport-specific
security information."
I am not sure that the security experts would like to see MUST
language about what needs to be included. This would potentially limit
algorithm agility. It also might depend on the libraries they are
using to implement; different libraries may require different
parameters. So the cached information is transport-model and
implementation dependent:

"A Transport Model may store transport-specific parameters in the
cache for subsequent usage. Since the contents of a cache are
meaningful only within an implementation, and not on-the-wire, the
format of the cache is implementation-specific."

> pick up the proper data that it needs.

"For each message or transport session, information about the message
security is stored in a cache, which may include model- and
mechanism-specific parameters. The tmStateReference is passed between
subsystems to provide a handle for the cache. A Transport Model may
store transport-specific parameters in the cache for subsequent usage.
Since the contents of a cache are meaningful only within an
implementation, and not on-the-wire, the format of the cache is
implementation-specific."

Done.
> it up from the SNMP message in the case of USM.

I'm not sure what "determines it" refers to. The securityModel is
determined by the message processing model. Certainly the decryption
is handled by the transport, not the security model. So I assume you
mean the securityName and securityLevel. 

To keep things modular, a secure transport model translates from
transport-specific security principal to securityName, and passes the
securityName in the cache.  The transport model determines what
security services were provided by the transport, and puts
securityLevel into the cache. A security model does not need to know
anything about the transport specific principal or services. The
security model just takes securityName and securityLevel from the
cache, already translated. Otherwise we would have a problem of
requiring a specific security model for each specific transport model,
something we definitely want to avoid.

What happens with the cache depends on the security model called by
the message processing model. Some might take the values from the
cache to return to the MPM; some might just use parameters provided in
a message security block and totally ignore the cache; some might use
a mapping from a MIB module and totally ignore the cache.

> > >     another SNMP engine.  Once the tunnel is established,
multiple
> > >     another SNMP engine.  Once the tunnel is established,
multiple
> lowercase "may" if you ask me.

This would have an on-the-wire interoperability impact, so I think MAY
is appropriate. A reciever should be prepared to deal with a sender
that puts multiple messages in the same tunnel, without core dumping,
for instance. The MAY says it is permissible for a compliant
implementation to send multiple messages in a tunnel.

> > an implementation to do this.) 

Let's wait for -06- to hit before discussing these points further.

dbh