Subject: [Isms] Security/Protocol Naming agreement: take II

From: Wes Hardaker <[email-masked]>
Date: Wed, 20 Aug 2008 14:55:35 -0700

At the last IETF and over the mailing list we discussed having
securityNames handed up by TMs to be prefixed with a PROTO: name type
tag, where PROTO: would be ssh: dtls: etc.  I won't rehash why this was
desired as that's in the list archives (and minutes).  But I'm going to
revamp my write up of what I thought was close to consensus (which I'll
leave to the chairs to decide if it's been reached).

I know David understandable wanted as concrete proposals as possible and
this text is an update only to serve that purpose.  David, of course,
you're free to change the text at will as you think is necessary.  I'm
just trying to be helpful and provide as much starting ground for you as
possible :-)

  - Adds an IANA considerations sections

     (which IANA assignment method is used is probably subject to
     debate.  I'd argue flexibility should be a good thing, but
     willy-nilly is probably overkill.  And thus "Specification
     Required" is specified below, but "Expert Review" would probably
     bee an adequate choice as well)

  - Adds in a few more references to the 
  - Clarifies where I think the text needs to be added in the documents.
  - Clarified what steps need modification to deal with the prefix

Proposed wording/changes:

== In the TMSM document: ===================================================

   In section 3.2.2.1 at the end of the second paragraph add
   (or add as a new 3rd paragraph on its own):

     "Documents defining a new TM specification MUST define a security
     name prefix that will be pre-pended to all passed securityNames.
     Implementations MUST pre-pend this prefix to the security-model
     independent securityName used for subsequent processing.  This
     prefix MUST be defined from 1-4 securityName compatible octets
     followed by a ':' (ASCII 0x3a) character.  Prefix names are
     coordinated by the IANA registry XXX.  This prefix is defined
     solely as a signaling mechanism and should not be considered part
     of the Elements of Procedure for securityNames, unless otherwise
     specified.

     [NOTE to RFC editor: please replace XXX with the IANA established
     registry reference]"

  In section 3.2.4 add this sentence to the end of
  the 6th paragraph:

     The transport-model specific prefix string that gets prepended to
     the securityName field for incoming messages, as discussed in
     section 3.2.2.1, can be used by architecture components like the
     Security Model or Access Control Model to distinguish between
     transport protocols that a message may have been received over.

  Section 6.3, first paragraph:

      Change "securityName" to "transport model prefixed securityName"

  The last paragraph of Section 7 (Security Considerations) should be
  appended with:

     A security transport model prepends a prefix string and an ascii
     colon to the front of a securityName to provide the security model
     with additional information to aid in its securityName selection
     process.

  Replace section 8 (IANA Considerations) with:
  
     This document describes a new prefix registry that has been created
     by IANA.  This registry, discussed in section 3.2.2.1, will contain
     1-4 length ASCII string prefixes to be prepended by transport
     modules to securityNames when incoming messages are received.
     Values are to be assigned via RFC2434 "Specification Required".

== In the TSM document: =================================================

  In section 2.3, last paragraph add:

   ... "and to leave or strip ASCII string transport prefixes from
   securityNames."

  In section 5.2, replace step 4 with:

   If the tsmStripSecurityNamePrefix object is set to false then set the
   securityName to the value of tmSecurityName from the cache referenced
   by tmStateReference.  If the tsmStripSecurityNamePrefix object is set
   to true then set the securityName to the portion of the value of
   tmSecurityName beyond the first colon (':', ASCII 0x3a).

   4) Set securityName to the value of tmSecurityName from the cache
      referenced by tmStateReference.  If the tsmStripSecurityNamePrefix
      object indicates that the TM prefix should be removed (i.e., its
      value is false(2)), remove everything up to and including the
      first ':' (ASCII 0x3a) character in the securityName value.

  Section 7, add the following objects (or similar) to the MIB:

     snmpTsmConfiguration         OBJECT IDENTIFIER ::= { snmpTsmMIBObjects 3 }

     tsmStripSecurityNamePrefix OBJECT-TYPE
         SYNTAX      TruthValue
         MAX-ACCESS  read-write
         STATUS      current
         DESCRIPTION
             "This object indicates whether the transport modules string
             prefix will be removed before being passing the securityName
             to the message processing model.  If set to true, the string
             prefix will be removed.  If set to false, the string prefix
             will be left in place in front of the securityName passed up
             from the transport.

             In particular authorization decisions made by an Access
             Control Module (e.g. the VACM) will be able to use this
             transport prefix in it's authorization decisions if this
             object is set to 'false'.  If set to 'true' then the TSM
             security model will strip the leading prefix and, for
             example, 'ssh:david' will become 'david' for purposes of
             authorization verification."
         DEFVAL { true }
         ::= {  }     

    (And add the tsmStripSecurityNamePrefix object to the snmpTsmGroup
    group)

   Section 8, update the second paragraph to read:

     Transport Security Model relies on a Transport Model to provide an
     authenticated principal that has been prefixed with the assigned
     Transport Model's prefix name for mapping to securityName, and an
     assertion of tmTransportSecurityLevel.

== In the SSH document ==================================================

  In section 3.1.1, append to bullet 4:

    The securityName provided by the SSH transport model is prefixed
    with "ssh:" to provide consuming SNMPv3 modules (like a security
    model) to understand what transport a given securityName originated
    from.

  In section 4.1, for the line starting "tmSecurityName =" change to:

    tmSecurityName = the concatenation of the ASCII string "ssh:" with the
    principal name [to be] authenticated by SSH.  See the section on
    tmSecurityName below.

  In section 4.2, change the second paragraph to:

    tmSecurityName is a human-readable name in SnmpAdminString format
    that is mapped from the identity that has been successfully
    authenticated by SSH.  By default, tmSecurityName is created by
    concatinating the ASCII string "ssh:" with the value of the user
    name field of the SSH_MSG_USERAUTH_REQUEST message for which a
    SSH_MSG_USERAUTH_SUCCESS has been received.

  In section 4.2, add in a new second sentence to the 4th paragraph
  (IE, after the sentence "The SSH protocol is not always clear..."):

    Regardless of what mapping system may be utilized, the
    implementation must prefix the resulting tmSecurityName with "ssh:".

  In section 5.1, step 2 add a second sentence:

    Note: The calculated value at this point should not include the
    "ssh:" prefix.

  And in step 4 of 5.1:

     tmSecurityName = "ssh:" | sshtmLCDTmSecurityName

  In section 5.2 in step 1 add a second sentence:

    Remove the "ssh:" prefix from the tmSecurityName found in the
    tmStateReference for processing purposes in these steps.

  In section 10 (IANA Considerations) add:

    5) "ssh" as a prefix assignment in the XXX registry which will
       indicate the prefix string to attach to securityNames returned by
       the SSH Transport model

-- 
Wes Hardaker
Sparta, Inc.
_______________________________________________
Isms mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/isms