Subject: [Isms] Comments on ISMS drafts

From: "Dave Shield" <[email-masked]>
Date: Mon, 11 Aug 2008 23:25:19 +0100

As part of preparing for the ISMS session at IETF 72, I read through
most of the relevant drafts shortly before the meeting.  As someone
coming to this from an SNMP perspective, with no particular security
expertise, I found the proposed mechanisms to be reasonably clear
and understandable.  However, in a number of places throughout the
various drafts, I sometime had to read a section two or three times
to be sure that I had grasped what was being proposed.

In particular, there are several concepts common to the Transport
Subsystem and Transport Security Model, and hence covered in both
(or all three) documents.  However the individual descriptions are
sometimes incomplete or inconsistent.  It proved necessary to read
all three documents in detail, to fully understand what is required.
Similarly, the terminology used is not entirely consistent between
the three documents.

 I therefore offer the attached comments as a (somewhat verbose!)
attempt to clarify text that I found to be less than straightforward to
follow.  In most cases, I don't believe that these suggestions should
affect the content of the proposals themselves - they are mostly
simply wordsmithing of the descriptive text.

 There are also a number of places where I found the current drafts
ambiguous or inconsistent.  I have attempted to identify these issues
and sometime propose possible solutions.  These may involve some
minor amendments to the proposed behaviour - particularly as relating
to the mapping of security names.

 Naturally, you are free to adopt or reject any/all of these
suggestions as you see fit.

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

---

From: Dave Shield <[email-masked]>
Date: Wed, 13 Aug 2008 15:11:21 +0100

I've just realised that the comments on the ISMS drafts
which I sent a couple of days ago, were attached as
un-typed binary files, which probably wasn't very helpful!

I'm therefore trying again, with the comment files explicitly
marked as text.   This message includes my general comments
on the tmStateReference cache, and those on the Transport
subsystem draft.   I'll send my comments on the Security
Model and SSH Transport drafts separately.

Dave
ISMS General Comments
=====================

tmStateReference cache
----------------------

The main concept of the ISMS proposal seems to be for the transport
subsystem to cooperate with the Security subsystem, in order to use
transport-level security parameters for authentication and authorization.
The mechanism used for this purpose is a 'tmStateReference cache'.
As such, there needs to be a common understanding of the contents of
this cache - both in terms of what information it will contain, and
how that information should be used.   However the three main ISMS
documents contain significantly different descriptions of this cache,
with the Transport Subsystem document (in particular) being very vague
about what information should be included.

  It would seem sensible to have a consistent description shared by
all three documents - probably by repeating essentially the same text
each time.  (Possibly augmented by any local considerations).

  <proposal>
     X.  Cached Information and References

     When performing SNMP processing, there are two levels of state
   information that may need to be retained:  the immediate state
   linking a request-response pair, and potentially longer-term state
   relating to the processing of a stream of related requests.

   The RFC3411 architecture uses caches to maintain the short-term
   message state, and uses references in the ASIs to pass this
   information between subsystems.

   This document defines the requirements for a cache to handle the
   longer-term transport state information, using a tmStateReference
   parameter to pass this information between subsystems.

   To simplify the elements of procedure, the release of state
   information is not always explicitly specified.  As a general rule,
   if state information is available when a message being processed
   gets discarded, the state related to that message should also be
   discarded.  If state information is available when a relationship
   between engines is severed, such as the closing of a transport
   session, the state information for that relationship might also
   be discarded.

     X.1.  securityStateReference cache

   The securityStateReference parameter is defined in RFC3411.  Its
   primary purpose is to provide a mapping between a request and the
   corresponding response.   This cache is not accessible to Transport
   Models, and an entry is typically only retained for the lifetime of
   a request-response pair of messages.

     X.2.  tmStateReference cache

   For each transport session, information about the transport security
   is stored in a cache.  The tmStateReference parameter is used to
   pass model- and mechanism-specific parameters between the Transport
   subsystem and transport-aware Security Models.

   The tmStateReference cache will typically remain valid for the duration
   of the transport session, and hence may be used for several messages.

   Since this cache is only used within an implementation, and not
   on-the-wire, the precise contents and format are implementation-
   dependent.  However, for interoperability between Transport Models
   and transport-aware Security Models, entries in this cache must
   include at least the following fields:

     - transportDomain
     - transportAddress
     - tmSecurityName
     - tmSecurityLevel   (but see below)
     - tmSameSecurity
     - tmSessionID

     X.2.1.  Transport information

     Information about the source of an incoming SNMP message is passed up
   from the Transport subsystem as far as the Message Processing subsystem.
   However these parameters are not included in the processIncomingMsg ASI
   defined in RFC3411, and hence this information is not directly available
   to the Security Model.

   A transport-aware Security Model might wish to take account of the
   transport protocol and originating address when authenticating the
   request, and setting up the authorization parameters.  It is therefore
   necessary for the Transport Model to include this information in the
   tmStateReference cache, so that it is accessible to the Security Model.
   
     - transportDomain
         the transport protocol (and hence the Transport Model) used to 
         receive the incoming message

     - transportAddress
         the source of the incoming message.

   Note that the ASIs used for processing an outgoing message all
   include explicit transportDomain and transportAddress parameters.
   These fields within the tmStateReference cache will typically
   not be used for outgoing messages.

     X.2.2.  securityName

     There are actually three distinct "identities" that can be
   identified during the processing of an SNMP request over a secure
   transport:

     - transport principal:
         the transport-authenticated identity, on whose behalf the
         secure transport connection was (or should be) established.
         This value is transport-, mechanism- and implementation-
         specific, and is only used within a given Transport Model.

     - tmSecurityName:
         a human-readable name (in snmpAdminString format)
         representing this transport identity.  This value is
         transport- and implementation-specific, and is only
         used (directly) by the Transport and Security Models.

     - securityName:
         a human-readable name (in snmpAdminString format) representing
         the SNMP principal in a model-independent manner.

   Note that the transport principal may or may not be the same as
   the tmSecurityName.  Similarly, the tmSecurityName may or may not
   be the same as the securityName as seen by the Application and
   Access Control subsystems.   In particular, a non-transport-aware
   Security Model will ignore tmSecurityName completely when determining
   the SNMP securityName.

   However it is important that the mapping between the transport
   principal and the SNMP securityName (for transport-aware Security
   Models) is consistent and predictable, to allow configuration of
   suitable access control and the establishment of transport connections.

     X.2.3.  securityLevel

     There are two distinct issues relating to security level as
   applied to secure transports.  For clarity, these are handled
   by separate fields in the tmStateReference cache:

     - tmTransportSecurityLevel:
         an indication from the Transport Model of the level of
         security offered by this session.  The Security Model
         can use this to ensure that incoming messages were
         suitably protected before acting on them.

     - tmRequestedSecurityLevel:
         an indication from the Security Model of the level
         of security required to be provided by the transport
         protocol.   The Transport Model can use this to
         ensure that outgoing messages will not be sent over
         an insufficiently secure session.

     X.2.4.  Session information

     For security reasons, if a secure transport session is closed
   between the time a request message is received and the corresponding
   response message is sent, then the response message SHOULD be
   discarded, even if a new session has been established.  The SNMPv3
   WG decided that this should be a SHOULD architecturally, and it is
   a security-model-specific decision whether to REQUIRE this.

    - tmSameSecurity:
        this flag is used by a transport-aware Security Model
        to indicate whether the Transport Model should enforce
        this restriction.

    - tmSessionID:
        in order to verify whether the session has changed, the
        Transport Model must be able to compare the session used
        to receive the original request with the one to be used
        to send the response.  This typically requires some form
        of session identifier.  This value is only ever used by
        the Transport Model, so the format and interpretation of
        this field are model- and implementation-dependent.
  </proposal>

Qn:
  The above text describes the tmStateReference cache as a per-session
structure (following the lead of the Transport subsystem document).
However the tmSameSecurity and tmRequestedSecurityLevel fields work on
a per-message.  Is this a problem?   If so, how should it be handled?

Transport Subsystem
===================

Sections 1.2 & 1.3
  The other two documents start with Internet-Standard Management
Framework and Conventions followed by a section on Modularity.
The Transport subsystem document has the modularity diagram
coming *before* the section on Conventions.

  <proposal>
     Switch these two sections around.

     1.2.  Conventions
     1.3.  Modularity    [Note: new title]
  </proposal>

(This would also probably avoid the large blank space on p3!)

(new) Section 1.4
  The other two documents also include a section on Constraints, which
is missing from the subsystem document.  It would be sensible to include
the same section here, as a guide to developers of new Transport Models,
who might use this document as a template.

Section 2, paragraph 2
  The description of the "third approach" is very long and detailed.
This tends to obscure the basic point.

  <proposal>
     ... In the third approach, he could hire a security company,
   tell them what he wants protected, and leave the details to them.
   Considerations of hiring and training employees, positioning
   and scheduling guards, arranging for cover, etc. are then the
   responsibility of the security company.  The individual therefore
   achieves the desired security, wth no significant effort...
  </proposal>

Section 2, paragraph 4
  This text half-reads as a justification of whether it is possible to
use USM at all.   The intended key point is presumably that operators
would prefer an integrated approach.

  <proposal>
   ... USM therefore requires a separate principal and key management
   infrastructure, either configured using SNMP itself, or via some
   external mechanism.  However operators have reported that requiring
   such a separate infrastructure is a deterrent to deploying SNMPv3.
   It would be preferable to leverage a single user base that wasn't
   specific to SNMP.
  </proposal>

Section 2, paragraphs 5&6
  Both of these paragraphs lead with the domestic security analogy,
and this tends to obscure the SNMP aspects somewhat.  The emphasis
should probably be on the options for SNMP authentication, etc.

  <proposal>
     A USM-compliant architecture might combine the authentication
   mechanism with an external mechanism, such as RADIUS [RFC2865],
   to provide the authentication service.  Similarly it might be
   possible to utilize an external protocol to encrypt a message,
   to check timeliness, to check data integrity, etc.  However this
   corresponds to the second approach - requiring the coordination
   of a number of differenty subcontracted services.  Building solid
   security between the various services is difficult, and there is
   a significant potential for gaps in security.

   An alternative approach might be to utilize one or more lower-layer
   security mechanisms to provide the message-oriented security
   services required.  These would include authentication of the
   sender, encryption, timeliness checking, and data integrity checking.
   This corresponds to the third approach described above.
   There are a number of IETF standards ....
  </proposal>

Section 3.1
  Is it necessary to reference RFC 3411 both before *and* after the
list of threats?

  <proposal>
   Delete " [RFC3411]" from before the list of threats
  </proposal>

Section 3.1.1, paragraph 1

  <proposal>
     s/SHOULD/should/
  </proposal>

Section 3.1.1, paragraph 2
  I'm still not entirely sure what the last sentence is trying to say.
The following encapsulates what I *think* it's referring to:

  <proposal confidence=0>
   It is recommended that any proposed Transport Model include
   a description of the applicability of the relevant security
   protocol(s) for use in that Transport Model.
  </proposal>

If I have misunderstood the purpose of this sentence, then some fuller
explanation would probably be useful.

Section 3.1.1, paragraph 3, sentence 2

  <proposal>
    s/would/could/    i.e.
    ... in ways that could impact other existing usages. ...
  </proposal>

Section 3.2.1
  The description of the existing architecture (in paragraph 2) lists
the components in a seemingly random order.  It would be more natural
to list these in the order that they are used (as in the diagram on p4).

The third sentence of the same paragraph is perhaps a little too strong.

The rest of this section doesn't really seem to hang together very well.
A re-ordering of the same basic material would probably provide a more
coherent explanation of how the Transport subsystem fits into the basic
RFC3411 architectural requirements.

In particular, paragraphs 3&6 feel to be directly related, and could
usefully be merged.  It would also be worth emphasising the functional
benefits of a Transport subsystem, rather than the implications for
IETF progression.

The motivation behind the Transport Subsystem (in paragraph 5), and
listing particular examples, isn't really directly relevant to the idea
of mandatory elements.  Mentioning them here serves to obscure the
main point of the paragraph.

  <proposal>
     3.2.1.  Architectural Modularity Requirements

   SNMP version 3 (SNMPv3) is based on a modular architecture (defined
   in [RFC3411] section 3) to allow the evolution of the SNMP protocol
   standards over time, and to minimize side effects between subsystems
   when changes are made.

   The RFC3411 architecture includes a Message Processing Subsystem
   permitting different message versions to be handled by a single
   engine, a Security Subsystem for enabling different methods of
   providing security services, an Access Control Subsystem for
   allowing multiple approaches to access control, and Application(s)
   to support different type of application processors.  The RFC3411
   architecture does not include a subsystem for Transport Models,
   despite the fact that there are multiple transport mappings already
   defined for SNMP.  This document proposes a Transport Subsystem that
   is compatible with the RFC3411 architecture.  As work is being done
   to use secure transports such as SSH and TLS, using a sbsystem will
   enable consistent design and modularity of such Transport Models.

   The design of this Transport Subsystem accepts the goals of the
   RFC3411 architecture defined in section 1.5 of [RFC3411].  This
   Transport Subsystem uses a modular design that permits multiple
   transport protocols to be "plugged into" the RFC3411 architecture,
   supported by corresponding Transport Models (which may or may not
   be security-aware).  Such Transport Models would be independent of
   other modular SNMP components as much as possible.  This design
   also permits Transport Models to be advanced through the standards
   process independently of other Transport Models.

   To encourage a basic level of interoperability, IETF standards
   typically require one mandatory-to-implement solution, with the
   capability of adding new mechanisms in the future.  Any Transport
   Model SHOULD define one minimum-compliance security mechanism, but
   should also be able to support additional existing and new mechanisms.

   The following diagram depicts the SNMPv3 architecture including the
   new Transport Subsystem defined in this document, and a new Transport
   Security Model defined in [I-D.ietf-isms-transport-security-model].
  </proposal>

Qn: Is it intended to specify SSH-TM as the basic interoperability
    secure Transport Model?  If so, it would probably be sensible
    to state this explicitly somewhere.  The end of the penultimate
    paragraph above would seem an obvious place to do this.

Section 3.2.1, paragraphs 4,7&8
  These three paragraphs discuss *changes* to the basic RFC3411 model
(over and above the simple introduction of the Transport Subsystem).
It would probably be worth pulling these out into a separate subsection,
to emphasise this fact.   The following text also omits some unnecessary
detail, which tended to obscure the basic ideas being described.

  <proposal location=after_diagram_on_p10>
     3.2.1.1.  Changes to RFC3411 architecture

     The RFC3411 architecture and the Security Subsystem assume that
   a Security Model is called by a Message Processing Model and will
   perform multiple security functions within the Security Subsystem.
   A Transport Model that supports a secure transport protocol might
   perform similar security functions within the Transport Subsystem,
   including the translation of transport security parameters to/from
   security-model-independent parameters.

   To accommodate this, an implementation-specific cache of transport-
   specific information will be described (not shown), and the data
   flows between modules on this path will be extended to pass
   security-model-independent transport information.   Note that this
   document amends some of the ASIs defined in RFC 3411, and these
   changes are covered in sections 6.2 and 6.4.

   New Security Models may be defined that understand how to work
   with these modified ASIs and the transport-information cache.
   One such Security Model, the Transport Security Model, is defined
   in [I-D.ietf-isms-transport-security-model]
  <proposal>

(current) Section 3.2.1.1
  This isn't really specific to USM - it actually seems to be discussing
the processing differences as compared to the current RFC3411 architecture
when used with *any* (non-trivial) Security Model.
Again, there is an excess of detail which serves to obscure the main
point of the paragraph.

This subsection would also need to be renumbered, if the new subsection
proposed above is included.

  <proposal>
     3.2.1.2.  Changes to RFC3411 processing

     The introduction of secure transports also affects the (security?)
   responsibilities and order of processing within the RFC3411
   architecture.  While the steps are the same, they may occur in a
   different order, and may be done by different subsystems.  With
   the existing RFC3411 architecture, security processing starts when
   the Message Processing Model decodes portions of the encoded message
   to extract parameters that identify which Security Model should
   handle the security-related tasks.

   A secure transport performs those security functions on the message,
   *before* the message is decoded.  Note that some of these functions
   might then be repeated by the selected Security Model.
  </proposal>

I believe this last sentence is true - particularly if the message
specifies a non-TM-aware Security Model, such as USM.   This may or
may not be relevant, but it seems worth mentioning.

(current) Section 3.2.1.2

  <proposal>
     3.2.1.3.  Passing Information between SNMP Engines

     s/other SNMP engine/other/
  </proposal>

Section 3.2.2.1, paragraph 4
  The first three paragraphs of this section outline the current RFC3411
architecture.  This final paragraph seems to describe the implications of
adding a secure Transport Model, but this isn't immediately obvious.

  <proposal>
     The introduction of a secure transport protocol means that the
   translation from a mechanism-specific identity to a securityName
   might also be done by a Transport Model.  This proposed securityName
   might then be made available to the Security Model, together with an
   indication of the level of security provided by the transport layer.
   A Security Model might have multiple ...

   (in the final sentence) 
     s/made available/proposed/
  </proposal>

Section 3.2.3, paragraph 2-4
  This text should probably concentrate on the handling of security
parameters, rather than providing unnecessary details of the processing
within the Security Module.

  The intended meaning of paragraph 4 remains somewhat unclear to me,
particularly as it might relate to the passing of security parameters
between subsystems.  It seems to be discussing the purpose and actions
of a Security Model, when used with a security-aware Transport Model.
However this does not seem to be concerned with the handling of security
parameters.  No proposed alternative is suggested for this text, as I
would question whether this paragraph should appear here at all.

  <proposal>
     A Message Processing Model might unpack SNMP-specific security
   parameters from an incoming message before calling a specific
   Security Model to handle the security-related processing of the
   message.  When using a secure Transport Model, some security
   parameters might be extracted from the transport layer by this
   model before the message is passed to the Message Processing
   Subsystem.  This information should also be made available to 
   the Security Model.

   This document describes a cache mechanism (see section 5), into which
   the Transport Model puts information about the transport and security
   parameters applied to a transport connection or incoming message, and
   from which a Security Model may extract this information. 
   A tmStateReference is passed as an extra parameter in the ASIs
   between the Transport, Message Processing and Security Subsystems, to
   identify the relevant cache.  This approach of passing a model-
   independent reference is consistent with the securityStateReference
   cache passed between the Security, Access Control and Applicaion
   subsystems in the RFC3411 ASIs.
  </proposal>

Section 3.2.4, paragraphs 2&3
  The first sentence of paragraph 2 is inconsistent in its use of tense.
The rest of the paragraph seems to be talking about the modular nature
of the access control framework, but doesn't actually say so.  It's not
immediately clear how this relates to the concept of authentication vs
authorization (and the separation between them).

  <proposal>
   This separation was a deliberate decision of the SNMPv3 WG, to allow
   support for authentication protocols which do not provide data access
   authorization capabilities, and to support data access authorization
   schemes, such as VACM, that do not perform their own authentication.

   A Message Processing Model determines which Security Model is used,
   either based on the message version (e.g. SNMPv1 and SNMPv2c), or
   possibly by a value specified in the message (e.g. msgSecurityModel
   field in SNMPv3).
  </proposal>

Section 3.2.4, paragraphs 6&7
  More generally, the first five paragraphs of this section seem to
be summarising the overall security-related aspects of the RFC3411
architecture, with paragraphs six and seven disussing the implications
for the Transport Model subsystem.  However these latter concentrates
on the interactions with the Message Processing and Security subsystems
(which have already been covered), and does not really address interaction
with the Access Control subsystem.  Presumably because there isn't any,
given the separation between Authentication and Authorization!

  The obvious thing to cover here would be a summary of the recent
discussion regarding transport-independent vs transport-dependent
securityName mappings, as passed from the Security subsystem up to the
Access Control and Application subsystems.  The proposed prefix-based
mapping would more sensibly be covered in the TSM document, but this
section could at least prepare the ground for that mechanism.

  <proposal>
     A Transport Model does not know what Security Model will be used
   for an incoming message, so cannot know how the securityName and
   securityLevel parameters will be determined.  It can propose an
   authenticated identity (via the tmSecurityName field), but there
   is no guarantee that this value will be used by the Security Model.
   For example, non-transport-aware Security Models will typically
   determine the securityName (and securityLevel) based on the contents
   of the SNMP message itself.  Such Security Models will simply not
   know that the tmStateReference cache exists.

   Further, even if the Transport Model can influence the choice of
   securityName, it cannot directly determine the authorization allowed
   to this identity.  If two different Transport Model each authenticate
   a transport principal, that are then both mapped to the same
   securityName, then these two identities will typically be afforded
   exactly the same authorization by the Access Control Model.

   The only way for the Access Control Model to differentiate between
   identities based on the underlying Transport Model, would be for
   such transport-authenticated identities to be mapped to distinct
   securityNames.  How and if this is done is Security-Model-dependent.
  </proposal>

Section 3.3, paragraph 3
  This text, discussing the session selection, covers very similar
material to paragraph 1 & 5 of section 3.3.1, and paragraph 2 of
section 3.3.3.  It might be sensible to merge these descriptions,
perhaps as a separate new subsection:

  <proposal>
     3.3.1.  Session Selection

     The architecture defined in [RFC3411] does not include a session
   selector in the Abstract Service Interfaces, and nor do the ASIs
   defined in this document for the Transport Subsystem.  Neither
   does the Transport Subsystem have access to the pduType, so cannot
   select a given session for particular types of traffic.  However
   certain parameters of these ASIs can be used to guide the selection
   of the appropriate session to use for a given request.

   The transportDomain and transportAddress identify the transport
   connection to a remote network node.  Elements of the transport
   address (such as the port number) can be used to select different
   sessions for particular request types.  For example, UDP ports
   161 and 162 have typically been used to separate SNMP notifications
   from other request/response traffic.

   The securityName identifies which security principal to communicate
   with at the remote network node (e.g., different NMS applications
   running on the same system).  The securityLevel could be used to
   select sessions with different sets of security properties for
   different purposes (e.g., encrypted SETs vs.  non-encrypted GETs).
   Note that this remains true even if all the sessions actually provide
   the same level of security protection.

   In summary, a unique combination of transportDomain, transportAddress,
   securityName, and securityLevel would serve to identify a given session.
   Different values for any of these parameters would imply the use of
   a different session.  An immediate consequence of this is that
   implementations SHOULD be able to maintain some reasonable number of
   concurrent sessions.

   Implementers, of course, might provide non-standard mechanisms to
   select sessions.
  </proposal>
   
Note(1):  The paragraph starting "To reduce redundancy..." would remain
  as part of section 3.3.

Note(2):  The securityName and securityLevel are not explicitly included
  in the sendMessage and receiveMessage ASIs.  These two values would
  therefore need to be included within the tmStateReference cache, in
  order to support session selection.  The current text describing
  tmStateReference does not make this explicit.
    This is addressed by the proposed standard text for tmStateReference,
  common to all three documents.

(current) Section 3.3.1
  This would need to be renumbered (along with the following subsections),
and the selection aspects removed:

  <proposal>
     3.3.2.  Session Establishment Requirements

     As indicated above, SNMP subsystems (including SNMP applications)
   can specify a particular transport session by passing a unique
   combination of transportDomain, transportAddress, securityName,
   and securityLevel.  If this combination does not match an existing
   transport session, this will request the Transport Subsystem to
   establish a new session.

   If the Transport Model cannot provide at least the requested level
   of security, the Transport Model SHOULD discard the message and
   notify the dispatcher that establishing a session and sending the
   message failed.  Similarly, if the session cannot be established,
   then the message should be discarded and the dispatcher notified.

   Transport session establishment might require provisioning
   authentication credentials at an engine, either statically or
   dynamically.  How this is done is dependent on the transport model
   and the implementation.
  </proposal>

(current) Section 3.3.3
   The order in which material is covered in the second half of the
first paragraph is somewhat random.  It would be clearer if each concept
was handled individually.  The second paragraph of Section 5.2 also
discusses cross-session security considerations, and would probably
fit better as part of this description.

  The second and third paragraphs are effectively covered in the (new)
subsection 3.3.1, and don't need to be repeated here.

  The justification of why multiple levels of security are available 
(in paragraphs 4&5) is not really relevant to a discussion of message
vs session security, and serves to obscure the main point being made.

  <proposal>
     ... SHOULD ensure that fresh new session keys are generated for
   each session.  This would ensure that a cross-session replay attack
   would be unsuccessful; that is, an attacker could not take a message
   observed on one session, and sucessfully replay this on another
   session.

   A good security protocol would also protect against replay attacks
   _within_ a session; that is, an attacker could not take a message
   observed on a session, and successfully replay this later in the
   same session.   One approach would be to use sequence information
   within the protocol, allowing the participants to detect if messages
   were replayed or reordered within a session.

   Note that if a secure transport session is closed between the time
   a request message is received, and the corresponding response message
   is sent, then the response message SHOULD be discarded, even if a
   new session has been established.  The SNMPv3 WG decided that this
   should be a SHOULD architecturally, and it is a security-model-specific
   decision whether to REQUIRE this.

   SNMPv3 was designed to support multiple levels of security,
   selectable on a per-message basis by an SNMP application.  Some
   Transport Models might support ...

      s/requested security level/
        security level requested by a transport-aware Security Model/
               (final sentence)
  </proposal>

Section 4, paragraph 2

  <proposal>
     s/ regardless of pduType,//     (first time only)
  </proposal>

Section 5
  This whole description should probably be replaced by the standard
text proposed for the Cached Information and References section.

The text starting "This document does not specify an implementation
strategy..."  (paragraph 4 of the current text), could probably be
appended to the third paragraph of the standard description.

Section 6
   This section feels as if it would benefit from a brief description
of how it relates to the ASIs defined in RFC3411.

  <proposal location=new_para_2>
     This document introduces a couple of new ASIs to define the interface
   between the Transport and Dispatcher Subsystems,  and extends some of
   the ASIs defined in RFC3411 to include transport-related information.
  </proposal>

Section 6, paragraph 4
   The description of what is included in an errorIndication is not
entirely consistent with the usage in other SNMPv3 documents.

  <proposal>
     An error indication in statusInformation will typically include the
   OID and value for an incremented error counter.  This may be accompanied
   by values for contextEngineID and contextName for this counter, a value
   for securityLevel, and the appropriate state reference if the information
   is available at the point where the error is detected.
  </proposal>

Note that which state reference is returned will depend on the ASI concerned.
securityStateReference is only relevant to the Security subsystem ASIs.

Section 6.2
   It would be useful to tweak the title of this subsection, to emphasise that
this involves changes to the ASIs as defined in RFC3411.  It would probably
also be useful to reflect the section structure of the RFC3411 descriptions
(to indicate which subsystems are affected), and to cover all of the amended ASIs:

  <proposal>
     6.2.   Changes to RFC3411 Outgoing ASIs

     Additional parameters have been added to the ASIs defined in RFC3411,
   concerned with communication between the Dispatcher and Message Processing
   subsystems, and between the Message Processing and Security Subsystems.

     6.2.1.  Message Processing Subsystem Primatives

     A tmStateReference parameter has been added as an OUT parameter to
   the prepareOutgoingMessage and prepareResponseMessage ASIs. This is
   passed from Message Processing Subsystem to the dispatcher, and from
   there to the Transport Subsystem.

   statusInformation =
   prepareOutgoingMessage(
       :
     OUT  tmStateReference        -- (NEW) reference to transport state
   )

   statusInformation =
   prepareResponseMessage(
       :
     OUT  tmStateReference        -- (NEW) reference to transport state
   )

    How or if the Message Processing Subsystem modifies or utilitizes
  the contents of this cache is message-processing-model specific.

     6.2.2.  Security Subsystem Primatives

     transportDomain and transportAddress parameters have been added as IN
   parameters to the generateOutgoingMessage and generateResponseMessage
   ASIs, and a tmStateReference parameter has been added as an OUT parameter.
   The transportDomain and transportAddress parameters will have been passed
   into the Message Processing Subsystem from the dispatcher, and are passed
   on to the Security Subsystem.   The tmStateReference parameter will be
   passed from the Security Subsystem back to the Message Processing
   Subsystem, and on to the dispatcher and Transport subsystems.

   statusInformation =
   generateOutgoingMessage(
       :
     IN   transportDomain         -- (NEW) transport Domain of request destination
     IN   transportAddress        -- (NEW) transport Address of request destination
       :
     OUT  tmStateReference        -- (NEW) reference to transport state
   )

   statusInformation =
   generateResponseMessage(
       :
     IN   transportDomain         -- (NEW) transport Domain of request destination
     IN   transportAddress        -- (NEW) transport Address of request destination
       :
     OUT  tmStateReference        -- (NEW) reference to transport state
   )

   If a cache exists for a session identifiable from the transportDomain,
   transportAddress, tmSecurityName and requested securityLevel, then a
   transport-aware Security Model might create a tmStateReference parameter
   to this cache, and pass that as an OUT parameter.
  </proposal>

Note that securityModel has been omitted from this final paragraph, in line
with the (common) description of the tmStateReference cache, and the elements
of procedure in other ISMS documents.

Section 6.3, paragraph 1

  <proposal>
     When a message is received on a given transport session, if a cache
   does not already exist for that session, the Transport Model might
   create one, referenced by tmStateReference.  The contents of this
   cache are discussed in section 5.2.  How this information is determined
   is implementation- and transport-model-specific.
  </proposal>

Section 6.4
   As with section 6.4, it would be useful to tweak the title of this
subsection, and to reflect the structure of RFC3411:

  <proposal>
     6.4.   Changes to RFC3411 Incoming ASIs

     The tmStateReference parameter has also been added to some of the
   incoming ASIs defined in RFC3411.  How or if a Message Processing Model
   or Security Model uses tmStateReference is message-processing- and
   security-model-specific.

     6.4.1.  Message Processing Subsystem Primative

     A tmStateReference parameter has been added as an IN parameter to
   the prepareDataElements ASI.  This is received from the Transport
   Model by the dispatcher, and passed to the Message Processing Subsystem.

   statusInformation =
   prepareDataElements(
       :
     IN  tmStateReference        -- (NEW) reference to transport state
       :
     OUT stateReference          -- reference to state information
   )

    How or if the Message Processing Subsystem modifies or utilitizes
  the contents of this cache is message-processing-model specific.

     6.4.2.  Security Subsystem Primative

     A tmStateReference parameter has been added as an IN parameter to
   the processIncomingMsg ASI, and is passed from the Message Processing
   Subsystem to the Security Subsytem.
   Model by the dispatcher, and passed to the Message Processing Subsystem.

   statusInformation =
   processIncomingMsg(
       :
     IN  tmStateReference         -- (NEW) reference to transport state
       :
     OUT securityStateReference   -- reference to security state information
   )

   If tmStateReference is present and valid, an appropriate Security
   Model might utilize the information in the cache.  How or if the
   Security Subsystem utilizes the information in the cache is security-
   model-specific.

   This may sound underspecified, ....
  </proposal>

---

From: Dave Shield <[email-masked]>
Date: Wed, 13 Aug 2008 15:13:56 +0100

I'm therefore trying again, with the comment files explicitly
marked as text.   This message includes my comments on
the Security  Model and SSH Transport drafts.   I've
already sent my comments on the tmStateReference cache
and the Transport subsystem separately.

Dave
Transport Security Model
========================

Section 2
  The first half of paragraphs 2&3 refer to the handling of incoming
requests.  It would probably be useful to merge these two descriptions
into one.
  Similarly with paragraph 5 and the second half of paragraph 2.

  It's not immediately clear what the last couple of sentences of
paragraph 3 are trying to explain, and particularly how this might
relate to the topic of this section.

  Paragraph 4 assumes the creation of a new tmStateReference cache,
and should acknowledge the possibility of re-using an existing one.

  <proposal>
   For incoming requests, a secure Transport Model will create
   a tmStateReference cache (or use an existing one), including
   transportDomain, transportAddress, tmSecurityName and
   tmTransportSecurityLevel values, possibly together with other
   transport- specific information.  A non-secure Transport Model
   will typically not create or populate this cache.  The Transport
   Security Model will determine the security-model-independent
   securityName and securityLevel, and verify that the transport
   security provision is sufficient for the requested level of security.
   If the cache does not exist, is incompletely populated, or the
   tmTransportSecurityLevel provided is weaker than the requested
   securityLevel, the Transport Security Model will return an error
   (see section 5.2).

   For outgoing requests, the Transport Security Model will create
   a tmStateReference cache (or use an existing one), containing
   the transportDomain, transportAddress, tmSecurityName and
   tmRequestedSecurityLevel values, and passes the tmStateReference
   to the specified Transport Model.
  
   To maintain the RFC3411 modularity, the Transport Model does not
   know which Security Model will be used for an incoming message;
   this will be determined by the Message Processing Model.  Hence
   even if the Transport Model populates the tmStateReference cache,
   it is possible that the selected Security Model will ignore its
   contents.  For example, both the USM and community-based Security
   Models will derive the securityName from the SNMP message itself,
   rather than the tmSecurityName provided by a secure transport.
  </proposal>

Section 2.1.1.
   At first sight, there is an apparent inconsistency between the
first two paragraphs - first the TSM claims to provide protection,
and then it doesn't.  A closer reading explains the difference, but
a restructuring of the text might provide a clearer explanation:

  <proposal>
     The Transport Security Model is called a Security Model to be
   compatible with the RFC3411 architecture.  However it does not
   provide security mechanisms itself, so SHOULD always be used
   with a Transport Model that provides appropriate security.

   If used with a suitable Transport Model, then the Transport
   Security Model will provide protection against the threats
   identified by RFC3411.  However the responsibility for providing
   this protection is delegated to the secure Transport Model.  The
   Transport Security Model does not address any threats itself.

   If used with a non-secure Transport Model, then the Transport
   Security Model will *not* provide protection against such threats.
  </proposal>

Section 2.2

  <proposal>
     2.2.  Transport Sessions

   The Transport Security Model does not work with transport sessions
   directly.  Instead the transport-related state is associated with
   a unique combination of transportDomain, transportAddress, securityName
   and securityLevel, and referenced via the tmStateReference parameter.
   How and if this is mapped to a particular transport or channel is
   the responsibility of the Transport Subsystem.
  </proposal>

Section 2.3
  The contents of this section seem to describe not only the coexistence
of the Transport Security Model with other Security Models, but how the
Transport Security Model can coexist (and/or interface with) other
models within the RFC3411 architecture.  It might be useful to subdivide
this description into separate subsections for each of the RFC3411
Subsystems.

Section 2.3, paragraph 3
  Move this paragraph (and the two that follow) into a new subsection.

  <proposal>
     2.3.1.  Coexistence with Message Processing Models

   The SNMPv1 and SNMPv2c message processing described in [RFC3584]
   (BCP 74) always select the SNMPv1(1) and SNMPv2(2) Security Models
   respectively.  Since there is no mechanism defined in RFC3584 to
   select an alternative Security Model, SNMPv1 and SNMPv2c messages
   cannot use the Transport Security Model.  Such messages can still
   be conveyed over a secure transport protocol, but the transport
   security information will not be used as part of the SNMP-level
   authentication or authorization.

   The SNMPv2u/SNMPv2* Message Processing Model is a historical artifact
   for which there is no existing IETF specification.

   The SNMPv3 message processing defined in [RFC3412], extracts the
   securityModel from the msgSecurityModel field of an incoming
   SNMPv3Message.   When this value is transportSecurityModel(YY),
   security processing is directed to the Transport Security Model.
   For an outgoing message to be secured using the Transport
   Security Model, the application should specify a securityModel
   parameter value of transportSecurityModel in the sendPdu ASI.
  </proposal>

Section 2.3, paragraph 6
  Move this paragraph into a new subsection.

  <proposal>
     2.3.2.  Coexistence with other Security Models

     [[ text as currently ]]
  </proposal>

Section 2.3, paragraph 8
  Move this paragraph into a new subsection, and expand slightly

  <proposal>
     2.3.3.  Coexistence with Transport Models

     The whole purpose of the Transport Security Model is to work
   with appropriate secure Transport Models to use the transport-
   level security information for authenticating and authorizing
   an SNMP request.  An indication of which Transport Model was or
   should be used is included as part of the tmStateReference cache.

   The MIB module defined in this document allows an administrator
   to configure the Transport Security Model to disable support for
   specific transport models.
  </proposal>

Section 2.3, paragraph 7
  Move this paragraph into a new subsection, and expand to discuss
transport-visible securityNames.

  <proposal>
     2.3.4.  Coexistence with Access Control Models

     An SNMP engine will typically implement only one Access Control
   Model, and there is no mechanism defined in RFC3411 for selecting
   between alternative ACMs.  There are therefore no issues relating
   to the coexistence of the Transport Security Model with multiple
   Access Control Models.

   Conversely, the isAccessAllowed primitive includes a parameter to
   indicate the Security Model used to authenticate a request, so the
   Access Control Model should be able to handle multiple Security
   Models (including the Transport Security Model).

   However the isAccessAllowed does not provide any information about
   the Transport Model used or transport-level security parameters.
   As a result, it is not possible to have different access control
   rules for different Transport Models.  Or at least, not directly - the
   only way to influence access control based on transport considerations
   would be to use different securityName values for different transports.
  </proposal>

Section 2.4
  Referring to the MIB is unnecessary at this point.  It would be
clearer (and consistent with the Transport subsystem document) to
discuss processing is terms of the tmStateReference cache.
  Details of the precise processing required belong in the Elements
of Procedure.  It's probably not useful to go into quite so much
detail here.

  <proposal>
     For outgoing messages, the Transport Security Model uses parameters
   provided by the SNMP application to lookup or create an entry in the
   tmStateReference cache.  The wholeMsg and tmStateReference parameter
   are passed to the appropriate Transport Model as described in
   [ID.ietf-isms-tmsm].

   For incoming messages, a Transport Model accepts the message from
   the lower layer transport, and records the transport- and security-
   related information in the tmStateReference cache.  The wholeMsg
   and tmStateReference parameter are passed to the appropriate 
   Security Model as described in [ID.ietf-isms-tmsm].

   The contents of this cache are discussed in Section 3.2.
  </proposal>

Section 3
  This whole description should probably be replaced by the standard
text proposed for the Cached Information and References section.
Note that this effectively switches the order of subsections 3.1 and
3.2, to match the order used in the other ISMS documents.

Add the following to the end of section 3.1 (securityStateReference)

  <proposal>
     The tmStateReference parameter is used to ensure that the
   security parameters used for a response match those for the
   original request.  The Transport Security Model should add
   the tmStateReference received from the processIncomingMsg
   ASI to the securityStateReference.  This tmStateReference can
   then be retrieved during the generateResponseMsg ASI, so that
   it can be passed back to the Transport Model.
  </proposal>

This seems to be the intention of the second paragraph of the
(current) Section 3.2, although talking about the Transport Model
having access to the securityStateReference cache is confusing.

Section 4.2, step 1
   Whether the Security Model is processing a response message
(as opposed to a request) can be determined by which ASI is used,
rather than the presence or absence of a given parameters.

  <proposal>
     1) When generateResponseMsg is used to handle an SNMP response,
   the securityStateReference cache will contain information from
   the corresponding request, including securityName, securityLevel,
   and the tmStateReference.  The Transport Security Model should
   extract these values, and can then discard the cached security
   data and the securityStateReference.

   The tmRequestedSecurityLevel in the tmStateReference cache
   should be set to the value of the extracted securityLevel,
   and the tmSameSecurity parameter should be set to true.
  </proposal>

Qn:  How do the securityName and securityLevel IN parameters
     relate to the equivalent securityStateReference cache fields?
     Are these parameters used at all?
Qn:  Should the snmpTsmLCDTransformTable be referenced to check
     whether the specified transport is still enabled?
Qn:  Should the securityName (from the securityStateReference)
     be mapped back to a tmSecurityName, or will the existing
     tmSecurityName from the tmStateReference be used?

Section 4.2, steps 2&3
   These two steps both apply to the generateRequestMsg ASI.
It would probably be clearer to combine them into a single step.

  <proposal>
     2) When generateRequestMsg is called to handle an SNMP request,
   the parameters won't include a securityStateReference cache.
   Instead, the transport and security requirements will be supplied
   by the application via the IN parameters.

   Firstly, the requested transportDomain should be looked up in the
   snmpTsmLCDTransformTable.  If there is no entry for this domain,
   or the snmpTsmLCDPolicy value is set to disable(3), then ...
   ... processing stops for this message.

[[ If the value of snmpTsmLCDTransformPolicy is private(1), then ]]
   the values supplied for transportDomain, transportAddress,
   securityName and securityLevel are used to lookup or create an
   entry in the snmpTsmLCDTable, and the snmpTsmLCDTmSecurityName
   column value used for tmSecurityName.  [[ Otherwise, tmSecurityName
   should be set to be the same as the supplied securityName.  ]]

   Create a tmStateReference cache with tmSecurityName set to
   the value determined above, tmRequestedSecurityLevel to the
   supplied securityLevel value, and tmSameSecurity to false.
  </proposal>

Qn: How should the securityName -> tmSecurityName mapping be done
    if there is an inconsistency between snmpTsmLCDTransformPolicy
    and snmpTsmLCDTmSecurityName?   (i.e. a policy of 'default'
    and a value of tmSecurityName that doesn't match securityName)

    The full description above (including [[text]]) only references
    the snmpTsmLCDTable for non-default securityName mapping, and
    applies the identity mapping automatically (without requiring
    a snmpTsmLCDTable row at all).  The previous text would apply
    a configured non-identity mapping even with the default policy
    for that transport domain.

    If this is the intended behaviour, it would be sensible to
    state this explicitly.

Section 5.2
  It would seem more natural to perform all of the validation steps
first, before starting to populate the OUT parameter values.

  The specified procedure for determining the securityName (using
a non-identity mapping) is wrong, since it actually sets the MIB
table tmSecurityName column.  This value is already provided in the
tmStateReference cache.  The following text proposes an alternative
approach, that does map tmSecurityName to securityName.
  Note that as with the proposal for 4.2 above, this mapping only
references the snmpTsmLCDTable for the non-default transform policy.

  <proposal>
   1) If tmStateReference does not refer to a valid cache, containing
      values for transportDomain, transportAddress, tmSecurityName
      and tmTransportSecurityLevel, then the snmpTsmInvalidCache ...

   2) If there is no entry in snmpTsmLCDTransformTable corresponding
      to the specified transportDomain, or the corresponding value ...

      s/together with the OID and value of the incremented counter//
      s/Transport Security Model/Security Model/

   3) Compare the level of security provided by the transport
      (tmTransportSecurityLevel in the tmStateReference) with
      that required by the SNMP message (the securityLevel
      parameter passed in the processIncomingMsg ASI).  If the
      transort security is weaker than that required, then the
      snmpTsmInadequateSecurityLevels counter is incremented,
      an error indication is returned to the calling module,
      and Security Model processing stops for this message.

   4) Set securityEngineID to the local snmpEngineID.

   5) If the snmpTsmLCDTransformPolicy value for the specified
      transportDomain is default(1), then set securityName to the
      value of tmSecurityName from the tmStateReference cache.

      If the snmpTsmLCDTransformPolicy value is private, then
      search the snmpTsmLCDTable for an entry with the specified
      transportDomain, transportAddress and securityLevel
      [[ XXX - or tmTransportSecurityLevel ?? ]] indexes, and
      a snmpTsmLCDTmSecurityName value that matches the value
      of tmSecurityName from the tmStateReference cache.
      If such a row is present, then set securityName to the
      corresponding snmpTsmLCDSecurityName index value.

      If no such row exists, calculate securityName from the
      specified tmSecurityName using the appropriate private 
      algorithm.  Create a row in the snmpTsmLCDTable indexed
      by the specified transportDomain, transportAddress,
      securityLevel [[ XXX - or tmTransportSecurityLevel ]]
      values and this calculated securityName.  Set the
      snmpTsmLCDTmSecurityName column to the tmSecurityName
      from the tmStateReference cache.

   6) Extract the scopedPDU from the wholeMsg.

   7) Calculate the maxSizeResponseScopedPDU.  [[ HOW ?? ]]
      This is the maximum size allowed for a scopedPDU for
      a possible Response message.
 
   8) Create a cache containing the security data for this
      message, referenced by securityStateReference, so that
      a possible response can use the same security parameters.
      For the Transport Security Model, this security cache
      should include the tmStateReference.

   9) Return a success indication to the calling module,
      passing the OUT parameters determined above.
  </proposal>

Qn: Should the tmSecurityName -> securityName mapping lookup
    be done using the securityLevel from the SNMP request
    (analogous with the outgoing case), or with the level
    provided by the transport layer (potentially flattening
    multiple parallel sessions into one)?

Section 6
  The summary of the MIB contents is slightly inaccurate.

  <proposal>
     This MIB module provides management of the Transport Security Model.
   It contains three statistics objects, and two tables for managing
   the behaviour of the Transport Security Model.
  </proposal>

Section 6.3
  A little more detail about the contents of the snmpTcmLCD subtree
would probably be useful.

  <proposal>
     6.3.1 snmpTsmLCDTransformTable

   This table lists the [[ secure? ]] transports implemented by the
   SNMP entity, and indicates the securityName mapping policy used
   for traffic via each transport.  This table should be populated
   automatically by the SNMP engine, with one row for each supported
   transport.

     6.3.1 snmpTsmLCDTable

   This table provides details of the precise mapping between SNMP
   securityNames and transport-specific tmSecurityNames, for both
   existing and pre-configured user names.
  </proposal>

Qn:  Is it necessary for the snmpTsmLCDTable to contain entries for
     fixed (identity (?)and prefix) mappings?
Qn:  Should the transform table list non-secure transports
     (e.g. traditional SNMP-over-UDP, SNMP-over-TCP, etc)?

Section 6.4
  The other relevant MIB to mention here would be the that belonging
  to the appropriate Access Control Model (typically the VACM MIB).

  <proposal>
     a/ and the the appropriate Access Control Model MIB
        (for example, the SNMP-VIEW-BASED-ACM-MIB [RFC3415])/
  </proposal>

Section 6.4.1
  The Elements of Procedure don't actually make any mention of the
snmpInASNParseErrs.

  <proposal>
     s/'system' group/'snmp' group/g
     s/duplicate these objects/duplicate this object/
     Delete sentences 3&4 (or possibly this whole section?).
  </proposal>

Section 6.4.2

  <proposal>
     s/definitions for the concepts of snmpEngineID,//
     s/object definitions/an object definition/
  </proposal>

The securityLevel enumeration values will be used to implement
the SNMP-TSM MIB.

(new) Section 6.4.3

  <proposal>
     The Transport Security Model also maps between transport-
   provided identities and the SNMP securityName for use in
   the Access Control processing.  It is therefore expected
   that an entity implementing the Transport Security Model
   will also implement the appropriate ACM MIB (such as the
   SNMP-VIEW-BASED-ACM-MIB [RFC3415]).
  </proposal>

Section 7, snmpTsmInadequateSecurityLevels

  <proposal>
     s/by the application/by the application or SNMP PDU/
  </proposal>

Section 7, snmpTsmLCDDomainTable
  The name of the table doesn't match that used in the
definition of the snmpTsmLCDTransformEntry object.

  <proposal>
     s/snmpTsmLCDDomainTable/snmpTsmLCDTransferTable/
  </proposal>

Section 7, snmpTsmLCDTransformPolicy
Qn: Should this object include a separate enumeration
    for the prefix mapping?

Section 7, snmpTsmLCDTable
  The index objects are defined as "not-accessible",
so should not be included in the example SET command.

The distinction between internal operation and externally
configured rows could be slightly clearer.

  <proposal>
     s/may be instantiated/can be instantiated automatically/
     s/, and they can be/.  They may be explicitly/

     s/snmpTsmLCDTransportDomain=(desired value),//
     s/snmpTsmLCDTransportAddress=(desired value),//
     s/snmpTsmLCDSecurityName=(desired value),//
     s/snmpTsmLCDSecurityLevel=(desired value),//
  </proposal>

Qn: Should this table list all known (existing and/or
    pre-configured) users, or just the non-default mappings?

Section 7, snmpTsmLCDTransportDomain
  <proposal>
     s/transport type/transport domain/
     a/This indicates the Transport Model that will be used./
  </proposal>

Section 7, sshTsmLCDTmSecurityName

  </proposal>
      A human readable string representing the transport-
    authenticated identity to both the Transport and
    Security Models. It is passed between them in
    tmSecurityName.

    This may or may not be the same as sshTsmLCDSecurityName.
  <proposal>

Qn: Can this value be changed once a transport connection
    has been established?  If so, what are the security
    implications of doing this?
Qn: Can this value be set/changed to indicate a non-identity
    mapping, if the transform policy is set to default?

Section 8
  There is a certain amount of repetition in this description,
particularly between the first two paragraphs.

  <proposal>
     This document describes a Security Model, compatible with
   the RFC3411 architecture, that permits SNMP to utilise
   security services provided through an SNMP Transport Model.
   The Transport Security Model provides no security itself,
   but relies on a secure Transport Model to provide an
   authenticated principal for use in Access Control decisions,
   and an assertion of transport securityLevel to ensure
   confidentiality and integrity.

   It SHOULD always be used with a Transport Model that provides
   security, but this is a run-time decision of the operator or
   management application, or a configuration decision of the
   operator.

   The security threats and how these threats are mitigated
   should be covered in detail in the specifications of the
   Transport Model and the underlying secure transport.
  </proposal>

Section 9, DISCUSS
  The choice of default ports is surely an issue for the Transport
subsystem (i.e. individual Transport Model definition documents),
rather than the Transport Security System.
Secure Shell Transport
======================

Section 1.4
  Much of the motivation description (paragraphs 1,2,5 & 6) feels
too detailed for this particular document.  Most of the justification
is fairly generic, and would apply to the use of any secure transport.
As such, this detailed description really belongs in the Transport
subsystem document, rather than here.
  A much simpler description would be sufficient, with a reference to
the fuller description in the Transport subsystem document.

  <proposal>
     Widespread use of version 3 of the Simple Network Management
   Protocol (SNMPv3) with the User-based Security Model (USM) has
   been hampered by the need to deploy a separate user and key
   management infrastructure.  Operators have reported a desire to
   unity the administrative security used for SNMP, with that used
   for Command Line Interfaces (CLI) and other management interfaces.
   [I-D.ietf-isms-tmsm] defines a Transport subsystem, designed to
   allow SNMP to take account of transport-layer security information.

   CLIs commonly use the security services provided by the Secure
   Shell, and this is also the approach being adopted for use with
   NETCONF [RFC4742].  This memo describes a method for invoking
   and running the SNP protocol within a Secure Shell (SSH) session.
   This provides for mutual authentication between client and server,
   data validation and confidentiality, and allows SNMP to make use
   of the SSH-authenticated identity in authorization policies for
   MIB data access.

   There are a number of challenges to be addressed .. detail below.
  </proposal>

Section 2, paragraph 2
  The description of SSH post-connection processing (following the
list of SSH components) is somewhat vague.  A less general summary,
more closely aligned to typical usage, might be more helpful.

  <proposal>
     Once a secure transport layer connection has been established,
   [and the server identity verified?], the client sends a service
   request to initiate client-side user authentication.  This is
   then typically followed by a second service request to establish
   an SSH Session.
  </proposal>

Section 3

  <proposal>
     s/Fits into the Transport Subsystem/
       Fits into the SNMP Architecture/
  </proposal>

Section 3.1.1
  The threats are discussed in a different order to the list in
the Transport subsystem document (which matches that in RFC3411).
For consistency, it would probably be useful to always cover
these threats in the same order.

  The descriptions for the main four threats feel somewhat short and
unconvincing.  There is typically a statement that the SSH Transport
Model addresses this threat, with no justification or explanation of
how this is achieved.

  The other three numbered points (4, 5 & 7) seem to be particular
cases of the four main threats, and would be better presented as
such.  This would also address the lack of justification above.

  <proposal>
   1.  Modification of Information - SSH provides for verification
       that the contents of each message has not been modified
       during its transmission through the network, by digitally
       signing each SSH packet.

   2.  Masquerade - SSH provides for verification of the identity
       of the SSH server through the SSH Transport Protocol
       server authentication ([RFC4253]).   This allows an operator
       or management station to ensure the authenticity of the
       SNMP engine that provides MIB data.

       SSH also provides a number of mechanisms for verification
       of the identify of the SSH client-side principal, using
       the Secure Shell Authentication Protocol ([RFC4252]).
       These include public key, password and host-based mechanism.
       This allows the SNMP access control subsystem to ensure
       that only authorized principals have access to potentially
       sensitive data.

   3.  Message Stream Modification - SSH protects against malicious
       re-ordering or replaying of messages within a single SSH
       session by using sequence numbers and integrity checks.
       SSH protects against replay of messages across SSH sessions
       by ensuring that the cryptographic keys used for encryption
       and integrity checks are generated afresh for each session.
        
   4.  Disclosure - SSH protects against the disclosure of
       information to unauthorized recipients or eavesdroppers
       by encrypting all traffic between SNMP engines.
  </proposal>

Section 3.1.2, paragraphs 2/3
  The distinction between the topics of the second and third
paragraphs is not at all clear, even after multiple readings.

The absolute prohibition on anything other than authPriv in paragraph
3 conflicts with the (weaker) recommendations elsewhere in the
document (section 1.4, the first paragraph of this section, section 9).

  <proposal>
     paragraph 2
   s/type and address/address/
   s/the SSH Transport Model provides/provides/
    
     (new paragraph)
   The transport layer algorithms used to provide authentication, data
   integrity and encryption SHOULD NOT be exposed to the SSH Transport
   Model layer.  The Transport Model must simply trust that the
   underlying SSH connection has been properly configured to support
   authPriv security characteristics.  Outgoing messages specified
   with a securityLevel of noAuthNoPriv or authNoPriv, are actually
   sent by the SSH Transport Model with authPriv-level protection.
  </proposal>

Section 3.1.3, paragraph 2
  The description of integration with other authentication mechanisms
feels too detailed.  A simpler description would probably be better:

  <proposal>
   The password authentication mechanism allows for integration with
   deployed password-based infrastructure, such as RADIUS [RFC2865]
   or Diameter [RFC3588], either directly or using password validation
   protocols such as CHAP [RFC1994] or digest authentication [RFC5090].
  </proposal>

Section 3.1.5
  This material is effectively covered by the description of threats
in section 3.1.1.  It's probably not necessary to cover it again here.

  <proposal>
     Drop this section altogether (and renumber the following section).
  </proposal>

Section 3.1.6, paragraph 4

  <proposal>
     s/transportAddressType/transportDomain/
  </proposal>

Section 3.3, paragraph 2
  This section is entitled "Notifications and Proxy", but the text
concentrates on discussing notification handling.

  <proposal>
     s/notifications/notifications or proxy requests/
  </proposal>

Section 4
  The introduction to this section should probably be replaced by
the standard text proposed for the Cached Information and References
section (X, X.1 and X.2), with a couple of minor tweaks:

(common) Section X.2
  paragraph 3: 
  <proposal>
     s/Transport Models/the SSH Transport Model/
  </proposal>

  append after the summary of tmStateReference cache fields:
  <proposal>
     See the Elements of Procedures for detailed processing
   instructions on the use of these fields by the SSH Transport Model.
  </proposal>

The remainder of this standard text can be significantly simplified to
concentrate on the particular requirements of the SSH Transport Model.

  <proposal>
     4.2.1.  Transport information

   The tmStateReference cache for a given SSH connection should
   include information about the source of incoming SNMP messsages,
   so that this is accessible to transport-aware Security Models

     - transportDomain
         snmpSSHDomain (defined in the SSHTM-MIB, see section 7)

     - transportAddress
         the remote end of the SSH connection, represented as an
         snmpSSHAddress (defined in the SSHTM-MIB, see section 7)

     4.2.2.  securityName

     How the SSH transport principal is extracted from the SSH
     layer is implementation-dependent.  By default, this will
     typically be taken from the value of the user name field
     of the SSH_MSG_USERAUTH_REQUEST message for which a
     SSH_MSG_USERAUTH_SUCCESS has been received.   The SSH protocol
     is not always clear on whether this user name field must be
     filled in, so for some implementations, it may be neccessary
     to retrieve the transport principal in some other way.

     How the SSH transport principal is mapped to/from a tmSecurityName
     should be administratively configurable, including whether this is
     a straight identity mapping, or some alternative transformation.
     The SSHTM-MIB (see section 7) includes a sshtLCDTransformPolicy
     object and sshtmLCDTable, which are used during the Elements of
     Procedure to determine this mapping.

     Transport Model transforms SHOULD generate predictable
     tmSecurityNames to represent transport principals.
  
     4.2.3.  securityLevel

     SSH transport connections are both verified and encrypted,
     so inherently offer the strongest securityLevel protection.

     - tmTransportSecurityLevel
         authPriv

     - tmRequestedSecurityLevel
         this value will be ignored for outgoing messages
         (since all SSH connections automatically provide
          an adequate level of security)

     4.2.4.  Session information

     The tmStateReference cache for an SSH connection SHOULD include
     a tmSessionID to indicate which SSH session it refers to.

     If the Transport Model receives an outgoing message with the
     tmSameSecurity parameter set, but the session identified in
     the tmStateReference does not match the current established
     SSH session for the specified transportDomain, transportAddress,
     tmSecurityName and tmRequestedSecurityLevel, then the message
     MUST be discarded, and the dispatcher notified that the sending
     of the message failed.
  </proposal>

Section 5
  The ASIs relevant to the SSH Transport Model are the two defined in
the Transport susbsystem document (receiveMessage and sendMessage),
rather than those from RFC3411.

The release of state information is included as part of the common
description of Cached Information and References, and can therefore
safely be omitted here.

The description of error handling (which only applies to sendMessage)
could usefully be simplified to concentrate on the primary error
indication (the error counter OID and value)

  <proposal>
     Abstract service interfaces for the Transport subsystem have been
   defined by [ID.ietf-isms-tmsm].  The SSH Transport Model uses these
   conceptual data flows when communicating with the Dispatcher.

   An error indication in statusInformation will typically
   include the OID and value for an incremented error counter.
   This may be accompanied by the requested securityLevel, and
   the tmStateReference.  Per-message context information is not
   accessible to Transport Models, so contextEngine would be set
   to the local value of snmpEngineID, and contextName to the
   default context for error counters.
  </proposal>

It is unclear whether it's useful to discuss context here at all.

Section 5.1
  Most of this description is concerned with what should be done
when accepting a new incoming SSH connection.  Once such a connection
has been established, it's probably not necessary to repeat all this
processing for every subsequent message received on the same connection.
  It would be useful to separate the description of the processing
required for accepting an incoming connection, from that for handling
an incoming message.

  <proposal>
     5.1.   Procedure for accepting an incoming SSH session

   The SSH Transport Model provides the following abstract service
   interface (ASI) to describe the data passed between the SSH
   service and the SSH Transport Model.  It is an implementation
   decision how such data is passed.

     acceptSession(
       IN  sourceTransportAddress
       IN  sshPrincipal
       IN  sshSessionID
       OUT tmStateReference
     )

   The following describes the procedure to follow when establishing
   an incoming session to run SNMP over SSH.  This will be done
   automatically for an SNMP application that receives an unsolicited
   transaction, such as a Command Responder, or a Notification Receiver.

   1) Query the SSH engine, in an implementation-dependent manner,
      to determine the transportAddress that initiated the connection,
      the principal name authenticated by SSH and a session identifier.

      By default, the principal name will be the value of the
      user name field of the SSH_MSG_USERAUTH_REQUEST, for which
      a SSH_MSG_USERAUTH_SUCCESS was sent.  How this name is
      extracted from the SSH environment is implementation-dependent.

   2) Determine the tmSecurityName corresponding to the sshPrincipal
      parameter.  If the SSH Transport Model is using the identity
      mapping (as indicated by the sshtmLCDTransformPolicy object),
      this will be the same as the sshPrincipal parameter.  Otherwise,
      the tmSecurityName should be determined by an implementation-
      specific mapping algorithm.

         [[[ XXX - How - via a reverse-lookup in ssmtmLCDTable? ]]]

   3) Create a tmStateReference cache containing the following values:

         transportDomain   = snmpSSHDomain  (defined in SSH-TM, see section 7)
         transportAddress  = sourceTransportAddress parameter
         tmSecurityName    = the value determined in step 2) above
         tmTransportSecurityLevel = authPriv
         tmSessionID       = sshSessionID parameter

   4) Create an entry in the sshtmLCDTable containing the values:

         sshtmTransportAddress  = sourceTransportAddress parameter
         sshtmLCDTmSecurityName = tmSecurityName (from step 2) above)
         sshtmLCDPrincipal      = sshPrincipal parameter
         sshtmLCDSessionID      = sshSessionID parameter
         sshtmStorageType       = volatile(2)
         sshtmRowStatus         = createAndGo(4)

    Return the tmStateReference cache for this session.

     5.2.   Procedure for an incoming message

    Retrieve the tmStateReference for the SSH session used to receive
    the incoming message.    Pass the message to the Dispatcher using
    the following ASI:

      statusInformation =
      receiveMessage(
         IN    transportDomain     -- snmpSSHDomain
         IN    transportAddress    -- from tmStateReference cache
         IN    wholeMessage
         IN    wholeMessageLength
         IN    tmStateReference
      )
  </proposal>

Qn: Could a row exist in the sshtmLCDTable before the corresponding SSH
    session was established (e.g. to pre-configure a suitable mapping
    between SSH principal and tmSecurityName).
      Or would creating such a row automatically establish the connection?

    In either case, presumably establishing the session should set the
    value for tmSessionID (and perhaps make the row active)

Qn: Would it be sensible to have a separate sshtmSessionAccepts counter?
    Or should incoming sessions be included in sshtmSessionOpens?

Section 5.3
  The description is somewhat confusing in places, and would benefit
from a slight simplification and clarification.  Some of the processing
specified is actually related to sending an outgoing message, rather
than opening a new SSH session.
  The maxMessageSize IN parameter is never actually used.
  There is no mechanism for returning the SSH session
  
  <proposal>
     paragraph 1
   s/application service interface/abstract service interface/

     ASI definition
   d/IN  maxMessageSize/
   a/OUT sshSession/

     step 1)
   s/using the SSH transport protocol//
   s/used to authenticate/used to authenticate the server/
   s/and an OpenSession error indication/an error indication/

   2) If sshtmLCDTransformPolicy is default, the SSH principal is set
      to tmSecurityName.  Otherwise, the SSH principal is calculated
      from tmSecurityName using the implementation-specific mapping
      algorithm.

      This principal is passed to the SSH layer for authentication.
      The credentials and authentication service to use are determined
      in an implementation-dependent manner.

      If authentication is unsuccessful, then the transport connection
      is closed, the sshtmSesssionUserAuthFailures counter is
      incremented, an error indication is returned to the calling
      module, and OpenSession processing stops.

   3) Once the principal has been successfully authenticated, the
      client should invoke the "ssh-connection" service, request a
      channel of type "session", [and set up an "snmp" subsystem].
      If unsuccessful, then the transport connection is closed, the
      sshtmSesssionChannelOpenFailures counter is incremented, an
      error indication is returned to the calling module, and
      OpenSession processing stops.

   4) If successful, this will result in an SSH session.  Create an
      entry in the sshtmLCDTable, indexed by destTransportAddress
      and tmSecurityName, containing

         sshtmLCDPrincipal = the SSH principal determined in step 2)
         sshtmLCDSessionID = the ID of the session just established

      The sshtmSessionOpens counter should be incremented, and the
      SSH session returned to the calling module.
  </proposal>

Qn: The discussion of SSH subsystems is somewhat unclear, but feels 
    more like implementation/configuration recommendations rather
    than Elements of Procedure.  It might perhaps be better included
    elsewhere in the document.  Where?

Qn: Should a failure to set up an "snmp" subsystem trigger a
    SessionChannelOpenFailure error?

Qn: This text also refers to an IANA-assigned TCP port, but this is
    never discussed anywhere in this document.

Section 5.2
  It might be more sensible to discuss the processing of outgoing
messages *after* the procedures for opening a session (following
the model of accepting a session/receiving a message above).

There is no provision in the sshtmLCDTable for implementation-specific
parameters - using the MIB table for this seems inappropriate.

  <proposal>
     5.4.  Procedure for sending an Outgoing Message

   1) Use the transportAddress and tmSecurityName from the
      tmStateReference to determine if a corresponding row
      exists in the sshtmLCDTable.
       
   2) If there is such a row, extract tmSameSession and tmSessionID
      from the tmStateReference cache.  If tmSameSession is true,
      and tmSessionID does not match sshtmLCDSessionID, ....

   3) If there is no such row, then call OpenSession with
      transportAdddress and tmSecurityName as parameters.
      If OpenSession fails, then discard the message, release
      tmStateReference and pass the error indication returned
      by OpenSession back to the calling module.
      Processing stops for this message.

   4) Pass the outgoingMessage to SSH for encapsulation as
      data in an SSH message over the specified SSH session
      (returned from OpenSession or identified by tmSessionID).
      Any necessary additional SSH-specific parameters should
      be provided in an implementation-dependent manner.
  </proposal>

Qn: This description uses transportAddress from the tmStateReference
    cache, rather than the IN parameter (destTransportAddress).
    Is this IN parameter ever used, or simply ignored?

Qn: How should this ASI handle an incomplete/invalid tmStateReference
    cache?  Or is such an occurrance Simply Not Possible?

Section 5.4
Qn: Is 'closeSession' invoked (conceptually) for remote-initiated
    session termination as well?

Section 6

  <proposal>
     This MIB module provides management of the Secure Shell Transport
   Model.  It defines an OID to identify the SNMP-over-SSH transport
   domain, a textual convention for SSH Addresses, several statistics
   counters and a MIB table representing the SSH Transport Model Local
   Configuration Datastore (LCD).
  </proposal>

Section 6.3
  The Transport susbsystem document does not define a MIB module.

The second paragraph talks about what this MIB provides (rather than
its relationship with other MIB modules).  This has already been
covered at the start of this main section.

It might also be worth mentioning the Transport Security Model.

  <proposal>
     s/and the SNMP-TRANSPORT-MIB [I-D.ietf-isms-tmsm]//

     It is expected that an entity implementing this MIB will
   also support the Transport Security Model [I-D.ietf-isms-tsm],
   and therefore implement the SNMP-TSM-MIB.
  </proposal>

Section 7, SnmpSSHAddress definition

  <proposal>
    paragraph 3
      s/a dotted decimal/in dotted decimal/
    paragraph 4
      s/surrounded by brackets/surrounded by square brackets/
    paragraph 5
      s/may not be useable/may not necessarily be useable/
         (warning, rather than prohibition)
    Reference
      s/RFC3896/RFC3986/
  </proposal>

Qn:  The purpose of paragraph 7 is not particularly clear.
     If the TC should not be used, then what is the point
     of providing this definition?

Qn:  This type is described purely in terms of IP addresses
     (or hostnames).  Is it intended to support SSH-over-nonIP
     transports as well?
     If not, should the snmpSSHDomain description (?and name)
     be  tweaked to make this restriction explicit?

Section 7, sshtmLCDSpinLock
  The comment immediately before the ssmtmLCDSpinLock definition
feels like a cut-and-paste error from the SNMP-TSM-MIB.

  </proposal>
      Delete these two lines
  <proposal>

Section 7, sshtmLCDTable definition
  The index values (TransportAddress and TmSecurityName) are defined
as "not-accessible", so should not be included in the example SET.

Qn:  What is the intended behaviour of creating an entry in this table?
     Should that attempt to open a corresponding SSH session
     automatically, or would SNMP-created rows be used to pre-configure
     a non-identity mapping between SSH principal and tmSecurityName?

It's not clear how an external SNMP command could possibly know the
appropriate SSH session ID to specify for a future SSH session (and
the spinLock value is almost guaranteed to be wrong!).
  It would be more appropriate to omit this varbind, and leave the
SSH transport model to supply the appropriate value.

  <proposal>
     s/sshtmLCDTransportAddress=(desired value),//
     s/sshtmLCDTmSecurityName=(desired value),//
     s/sshtmLCDSessionID=sValue,//
  </proposal>

Section 7, sshtmLCDTmSecurityName

  </proposal>
    A human readable string representing the transport-authenticated
    identity to both the Transport and Security Models. It is passed
    between them as tmSecurityName.

    This may or may not be the same as sshtmLCDPrincipal.
  <proposal>

Qn: How would the definition of this object be affected by the proposed
    use of transport-prefixes in the Transport Security Model
    tmSecurityName <-> securityName mapping?

    Should the size of this object be reduced, or should the prefix be
    added by the Transport Model itself?

Section 7, sshtmLCDPrincipal

  </proposal>
    A human readable string representing the transport-authenticated
    identity in an implementation-specific manner.  It is only used
    within the SSH Transport Model itself, and is typically the SSH
    user name.

    This may or may not be the same as sshtmLCDTmSecurityName.
  <proposal>

Section 7, sshtmLCDSessionID
  The definition for this object is missing altogether!  I suspect
that this column should probably be defined as 'read-only' (and
documented as being provided by the SSH engine).

Section 7, sshtmLCDRowStatus
Qn: Does the value of this object ('active' vs 'notInService')
    indicate whether there is a corresponding established SSH session?
    If so, then it would be sensible to document this.

Qn: The description states that the principal value can only be changed
    when the row is 'active'.  Is it realistic to try and change the
    transport-authenticated identity once the session has been established?

It would seem more natural either to only allow changing the principal for
inactive rows (i.e. when preparing the configuration settings for future
connections), or to forbid amending existing rows (apart from deleting
the row altogether).

Qn: Should deleting a row from this table, automatically close the
    corresponding SSH session?
    If so, then it would be sensible to document this.

Section 7, sshtmGroup
  It would probably be more flexible to define this as two separate groups.
One containing the statistics objects, and one containing the LCD table
and related scalars.  Even if both groups are defined as mandatory, this
separation would allow more focused descriptions.

Section 8, paragraph 2
  This document does not seem to define any well-known ports
for use by SNMP-over-SSH.

  <proposal>
   paragraph 1
     s/instead of/to supplement/
   Delete paragraph 2
  </proposal>

Section 8, paragraph 2
  This description includes an unnecessary level of detail, which
serves to obscure the main point.

  <proposal>
   The SSH protocol has its own window mechanism, defined in RFC
   4254. The SSH specifications leave it open when window adjustments
   messages should be created, and some implementations send these
   whenever received data has been passed to the application.  There
   are noticeable bandwidth and processing overheads to handling such
   window adjustment messages, which can be avoided by sending them
   less frequently.
  </proposal>

Section 9
  The various subsections seem to appear in a somewhat random order.
It would probably be clearer to discuss the three SSH-level security
considerations, before moving on to SNMP/MIB-related issues.

The titles of these subsection describe SSH protocol-level details,
which are possibly not familiar to non-SSH-experts.  More general
titles (describing "what" rather than "how") would be helpful.
(see proposals below)

Section 9.1
  The first two paragraphs (justifying the use of userauth "none")
seem to be inconsistent with the third (recommending against this).
A simpler description would perhaps be less confusing.

  <proposal confidence=0>
     9.1.  Skipping client authentication

   SSH includes the "none" userauth method, which could in principle
   be used to support access by anonymous clients.  This would not
   compromise the authentication of the server to the clients, nor
   data confidentiality or data integrity.

   However such a configuration effectively provides a securityLevel
   of "noAuthPriv", which is not permitted by RFC 3411.  The SSH
   Transport Model SHOULD NOT be used with an SSH connection using
   the "none" userauth method.
  </proposal>

Qn: Why is this SHOULD NOT rather than MUST NOT ?

This text may well be an over-simplification, in which case it would be
useful to give a clearer description of when/how anonymous access can
provide an authenticated principal.

Section 9.2
  The issues discussed here are not specific to community-based versions
of SNMP.  The same considerations would apply to SNMPv3 with USM, or any
other non-transport-aware Security Model.

  <proposal>
     9.4  Use with non-transport-aware Security Models.

   The SNMPv1 and SNMPv2c message processing described in [RFC3584]
   always select the SNMPv1 or SNMPv2c Security Models respectively.
   Both of these, and the User-based Security Model typically used with
   SNMPv3, derive the securityName and securityLevel from the SNMP
   message received, even when the message was received over a secure
   transport.  Access control decisions are therefore made based on the
   contents of the SNMP message, rather than using the authenticated
   identity and securityLevel provided by the SSH Transport Model.
  </proposal>

Section 9.3

  <proposal>
     9.2.  Skipping server authentication

   s/if this step is skipped/
     if this step is skipped (e.g. by blindly
           accepting the offered public key)/

   Start new paragraph before "Data confidentiality"
  </proposal>

Section 9.4

  <proposal>
     9.3.  Skipping data integrity validation

   SSH provides the "none" MAC algorithm, which disables the validation
   of data integrity, while maintaining data confidentiality.  However
   if this is done, then an attacker might be able to modify the data
   in flight, thus compromising both data integrity and authentication.

   SSH MUST NOT ...
  </proposal>

Qn: Wouldn't this also compromise the confidentiality of returned data?

Section 9.5
  The MIB module _does_ contain writeable objects (paragraph 1), which
affect the mapping between SSH principal and tmSecurityName (and hence
the SNMP securityName).  These could be used to subvert SNMP-level access
control restrictions.

  The values of SSH principals and tmSecurityName could themselves be
sensitive (pararaph 2), as might the addresses of communicating SNMP engines.

Section 10, item 1
  IANA is requested to assign a default port for SNMP-over-SSH.  But
nowhere in this document is there a placeholder location for this port
number to be specified.
_______________________________________________
Isms mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/isms

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 25 Aug 2008 12:10:00 +0200

> to the mapping of security names.

Dave,

many thanks for your reviews and the detailed comments. Since many
comments are more editorial, I would like to ask David Harrington to
make a first pass through your comments to identify any comments that
according to his judgement are more than just editorial and require
the attention of the WG. For any of those comments, we should start
separate discussion threads to find a resolution.

David Harrington, is that approach OK with you?

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>
_______________________________________________
Isms mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/isms