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

From: "Wijnen, Bert \(Bert\)" <[email-masked]>
Date: Fri, 12 Jan 2007 17:42:34 +0100

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?

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

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

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

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

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

    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/

    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?

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

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

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

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

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

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

  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"

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

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

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

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

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

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

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

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

- 6.3.1.  Processing an Incoming Message

  Is there any difference for an incoming response compared to a
  incoming request? Not clear to me.

- 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

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

- I guess Appendix C will get removed ;-)

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.

- 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

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

     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)

     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.

     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)

     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"

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

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

    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?

    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?

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

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

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

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

- Last para in sect 3.3.3

  I think the first capitalized MAY would better be a lower case may.
 
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/ ??

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

  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.
  
  s/proposal//  --  by the time this is an RFC it is no longer a
proposal is it?

- 4 para on page 8
  the motivstion of developing transport models is to develop support

  s/motivstion/motivation/

- 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 think I would also do s/USM/Security Subsystem/

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

Bert

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 12 Jan 2007 22:34:11 +0100

> one more rev may make sense.

Thanks for your rather detailed review. This is much appreciated (as
are all the other reviews of course).

/js

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