RE: [Isms] A session-less fix to SNMP security issues?

["Blumenthal, Uri" <[e-mail]>]

I think the authors of this proposal fail to understand one fundamental
issue.

   Authentication is necessary for each and every packet. Desired means
for 
   authentication are way too expensive to be carried out on per-packet
basis.
   Thus it is necessary to split the work - authenticate something (i.e.
session
   keys) and define the (relatively short) lifetime of that
authenticated <thing>.
   It enables cost-efficient per-session mechanisms to co-exist with
desirable
   but expensive session-establishment mechanisms.

   This THEORETICALLY does not allow for conceptual connection-less.

Please explain - as briefly as possible - how you propose to circumvent
this
issue. I.e. how to provide online authentication with RADIUS, and yet
stay
session-less?

[From what I read below - it looks like an attempt to find a problem for
the
solution.]


-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Thierry Moreau
Sent: Wednesday, March 23, 2005 9:51 AM
To: [e-mail]
Subject: [Isms] A session-less fix to SNMP security issues?

Subject: A session-less fix to SNMP security issues?

Dear isms wg members,

      The current isms activity is an architectural review. This
message is intended as a contribution towards the isms
advancement, however not based on either architectural proposals
currently under review.

      I am taking the isms pursuit from a security perspective. I
recently became aware and interested in the proposal comparison
document ([COMPAR]) during a search of security scheme documents
addressing the provisioning of pre-shared secrets.

Table of contents

1. Situation analysis

2. Proposal
      2.1. Desirable Properties
      2.2. Proposal Strategy

3. Solution
      3.1. Solution Context
      3.2. A Sample Protocol Suite
           3.2.1. SSH
           3.2.2. RADIUS
           3.2.3. SNMPv3
      3.3. SAKEM Use Pattern
      3.4. Elements of Operations Applicable to SNMPv3 Agents
           3.4.1. Initial Out-of-box Procedure
           3.4.2. SNMPv3 Installation-Related Operation
           3.4.3. The SNMPv3 Agent User Management Operations
      3.5. Server-Side Arrangements

4. Conclusion

5. Intellectual Property Notice

6. References


1. Situation analysis

      The following situation analysis uses some external sources
of understanding:

        o  the isms meeting audio recording ([AUDIO]) -- somehow
           usable despite low recording level and missing
           recording from some seats in the meeting room,

        o  the reference [MSG445]

        o  the author's organization promoted solution element,
           SAKEM (Secret Authentication Key Establishment Method)
           ([SAKEM_WP] and [SAKEM_IND]),

        o  an inference from a mailing list message ([MSG319]) ()
           that a workable SNMP agent configuration strategy can
           rest on a single "initial user" account, even with the
           initial-no-access-configuration option (defined in
           [RFC3415]).

      The main situation analysis elements are:

        o  The major discomfort with the SNMPv3 security scheme is
           that "Key management with manual keying is extremely
           difficult in any system." From [COMPAR].

        o  There are very few proposals that directly address the
           above difficulty. From [SAKEM_WP].

        o  The SNMPv3 security scheme is application-level
           security, implementing datagram security
           (connectionless security protocol) with symmetric-key
           cryptography.

        o  The SNMPv3 key management is a simple symmetric key
           derivation scheme, i.e. key derived from user
           passwords. Accordingly, the derived symmetric keys need
           to be (securely) configured in each SNMP agent, but the
           user passwords need not be stored on the SNMP manager
           side (it is a local implementation decision to store a
           user passwords on the SNMP manager side).

        o  The current SNMPv3 security solution comprises no
           notion of a session to which a security association can
           be plugged. The three isms proposals appear to change
           this architectural trait in order to benefit from
           various security protocols which derive session master
           keys from long-term authentication secrets. From
           [COMPAR].

        o  According to [MSG319], the out-of-box security
           configuration for SNMPv3 would be a single pre-shared
           secret key derived from an "initial user" password.

        o  Operational stability is best ensured if the "initial
           user" password is stored or backed up in a secure
           server for the administrative domain (hereafter "USM
           secure store").

        o  VACM is not broken. From [AUDIO], circa 58 minutes from
           start of recording. (Without further supporting data,
           not even having understood VACM, I assume that VACM
           need not be fixed.)

2. Proposal

2.1. Desirable Properties

      The desirable properties of a solution path, mainly
motivated by the network operator's operational needs:

        o  As little change as possible to the SNMPv3
           implementations. From [AUDIO].

        o  The typical out-of-box procedure for a new network
           element comprises the installation of a number of
           security protocols, each with its manual cryptographic
           key configuration requirement (pre-shared secret
           passwords are analogue to cryptographic keys in this
           context):
             .  SSH (host public key to be certified,
                see[SSH_ARCH])
             .  Radius NAS-to-server (symmetric secret key for
                mutual authentication, see [RFC2865])
             .  VPN enrolment (...)
             .  SNMPv3 (pre-shared secret key derived from the
                "initial user" password)
           From [MSG445], [MSG319], and [AUDIO]. See also [OPSEC],
           section 2.3.2.

        o  Perhaps a fallback mode of operation (or backwards
           compatibility) to the original SNMPv3 USM is an
           inescapable requirement. From [MSG445].

      A secondary goal is ignored herein to keep focused on the
main issues:

        o  In SNMPv3, authentication and privacy keys are derived
           with a single mechanism. This looks like an original
           SNMPv3 design flaw (i.e. it would have been easy to
           specify differentiated derivations for authentication
           and privacy). In any case, a fix would be to use the
           recently standardized CCM mode of operation [CCM]. From
           [RFC3414] section 11.2.

2.2. Proposal Strategy

      The main strategy for this proposal is
       1.  stick to connectionless security as specified in
           SNMPv3,
       2.  specify additional symmetric key management operations,
       3.  allow protocol elements to remain unspecified at this
           stage (because symmetric-key cryptography is simpler,
           e.g. fewer rounds of session key derivation protocol,
           than public-key cryptography, at the expense of more
           limited set of threat prevention, e.g. lack of perfect
           forward secrecy),
       4.  address the manual pre-shared secret distribution
           problem in a systematic way (SAKEM), and
       5.  attempt to apply this systematic approach to other
           security protocols configured in a typical out-of-box
           installation (a network device authentication
           consolidation approach, not unlike the single-sign-on
           paradigm for user authentication).

      Stepping back in the isms activities, this proposal re-
focuses on the SNMPv3 operational hindrance and shows (?) that
the three isms proposals carry a major architectural change
(moving away from the SNMPv3 connectionless protocol and simple
symmetric-key security model) that is not clearly related to the
major operational issue.

3. Solution

3.1. Solution Context

      Within an administrative domain, the solution assumes three
execution environments:
        1) field network devices, which may run SNMP agents,
        2) secure servers premises, and
        3) administrative systems, which may run SNMP manager
           applications.
The secure server premises is the proper place for secure
databases (e.g. Radius server databases) and security certificate
issuing systems/applications in support of public key
cryptography (e.g. to certify a network device public key for the
SSH protocol). Note that public key cryptography is introduced in
the present proposal because protocols alongside SNMPv3 use it,
and the consolidation approach supports it (in some
configurations at least).

3.2. A Sample Protocol Suite

      Since we are contemplating a consolidated solution to the
device authentication needs of a number of security protocols, we
may list some candidate protocols with some explanation about how
the individual solutions can converge towards a common method for
the very initial authentication of keys and secrets.

3.2.1. SSH

      In SSH, the network device needs to set up a private/public
key pair for routine device authentication afterwards. Within the
secure server premises, SSH deployment needs either a trusted
database of public keys or a security certificate issuance
function (see section 4.1 of [SSH_ARCH]). In either case, a
proof-of-possession should be delivered to the secure server
premises, providing confidence that the network device is able to
sign some authenticated shared secret with the private
counterpart of the alleged public key.

      Thus, the SAKEM procedure and technology may be used to
authenticate a shared secret between a new SSH host protocol
entity in a network device and a central organization's secure
server premises. The SSH host implementation need to digitally
sign this shared secret (specifically, a conventional string
containing the shared secret or a string conventionally derived
from the shared secret, as a necessary countermeasure against
chosen ciphertext attacks, as is well understood among public key
cryptography experts). The SSH host implementation already
performs digital signature operations. The additional requirement
shouldn't be overly difficult.

3.2.2. RADIUS

      If RADIUS is used to control access to a network device e.g.
for command line system management interface, the network device
acts as a NAS (Network Access Server) in the RADIUS terminology.
The RADIUS protocol links the NAS to the RADIUS server (in the
secure server premises). Upon device installation, the NAS and
RADIUS server must be provisioned with a pre-shared secret. This
is a straightforward application for the SAKEM procedure and
technology.

3.2.3. SNMPv3

      In the secure server premises, the SNMPv3 "USM secure store"
(where SNMPv3 passwords are stored for an administrative domain)
holds the "initial user" password from which the initial SNMPv3
pre-shared secret must be derived for any new network device. In
this case, the SAKEM procedure and technology can pre-share an
unpredictable binary secret key, which is neither a password nor
a value derived from a password. Some key management provisions
must be made to turn this network device pre-shared secret into a
secret derived (localized) from a password for every SNPMv3 agent
implementations on this device.

      First, there is a many-to-one relationship between SNMPv3
agents (identified by snmpEngineID) and network devices. This
needs to be reflected in the procedural aspect of SAKEM, i.e. the
identity that is verified in this context is the list of
snmpEngineID-s installed (or to be installed) on this device. The
key management provision addressing this many-to-one relationship
is a secret key derivation (details to be specified) based on the
snmpEngineID value.

      Then, the derived secret key for an SNMPv3 engine can be
used to protect (e.g. for confidentiality and data authentication
using the CCM mode of operation [CCM]) a message from the "USM
secure store" to the SNMPv3 engine with the data triplet "initial
user" name, privacy key, authentication key. We later refer to
such message as the *protected message*.

3.3. SAKEM Use Pattern

      Although the three protocols SSH / RADIUS / SNMPv3 are
introduced as a representative set of protocols for out-of-box
installation, we also get representatives of three different
SAKEM integration patterns:

      Protocol  Authenticated pre-shared secret use pattern
      ========  ===========================================

      RADIUS    Direct use of authenticated pre-shared secret

      SSH       Authenticated pre-shared secret used in a proof-
                of-possession for public key certificate issuance

      SNMPv3    Authenticated pre-shared secret protecting a
                password (or value derived from password)
                configuration message

3.4. Elements of Operations Applicable to SNMPv3 Agents

3.4.1. Initial Out-of-box Procedure

      The SNMPv3 agent must securely store (same kind of secure
storage applicable to shared secrets) an authenticated pre-shared
secret received from the SAKEM client-side software.

3.4.2. SNMPv3 Installation-Related Operation

      The SNMPv3 agent must receive the *protected message*
holding the "initial user" account data (user name,
authentication key, privacy key). The triggering of this message
transmission from the "USM secure store" to the local SNMPv3
agent is left unspecified at this point. Once so installed, the
SNMPv3 agent is configured with a fallback "initial user"
account.

3.4.3. The SNMPv3 Agent User Management Operations

      Synchronization between SNMP user management and
authentication protocols (e.g. RADIUS) is a goal of the isms
working group charter. The present proposal implements this with
1) a small change to SNMPv3 agent implementation, and 2) use of
some RADIUS protocol implementation-specific attributes for the
purpose of SNMPv3 user management integration (IANA
considerations set aside).

      The main change in the SNMPv3 agent implementation is the
support for the receipt of a *protected message* holding user
account data for a given user (user name, authentication key,
privacy key). Implementation-wise, this looks like the re-use of
the "initial user" setup as described above. Security-wise, there
a important difference: the SNMPv3 agent implementation must be
protected from replay attacks (e.g. local mitigation by
implementation integration of the SNMPv3 security code and the
RADIUS NAS code).

      The RADIUS protocol support of SNMPv3 user management is an
implementation-specific attribute in the Access-Request packet to
indicate to the RADIUS server that some "Authenticate Only"
service type request is a request to a) authenticate the end-
user, b) validate that the end-user is allowed SNMPv3 agent
registration, and c) convey the above *protected message* to the
NAS in the network device, in an implementation-specific
attribute to the RADIUS Access-Accept packet.

      The daily network management operations work as follows:
        o  Upon hiring a new employee in the network management
           function, a user name and password is created in the
           "USM secure store."
        o  The first time an employee wishes to perform an SNMP
           operation targeted at an SNMP agent, he/she must first
           authenticate with the RADIUS NAS server residing on the
           same network device, requesting the implementation-
           specific service arrangement described above. This is
           when the "USM secure store" application prepares the
           *protected message* for users other than the initial
           one.
        o  When the employee leaves or when a password change is
           required, every SNMP agents which was within his/her
           reach must be notified (i.e. the employee user name
           must be removed or disabled). Most SNMP management
           systems should be flexible enough to have this task
           automated.

3.5. Server-Side Arrangements

      The server-side arrangement details are numerous but
"straightforward" (for the present author to formulate, and maybe
for some readers). A SAKEM implementation document uses the term
"Functional Area" for the required secure application in the
secure server premises ("FA systems"). The SAKEM FA system
required for the current proposal integrates the support of SSH
out-of-box deployment, RADIUS NAS out-of-box deployment, and the
proposed RADIUS-SNMPv3 integration.

4. Conclusion

      The above proposal is a two-sided solution to the SNMPv3
operational difficulties:
   A) the "initial user" manual configuration is recognized as a
      familiar difficulty with other protocols in an out-of-box
      procedures for new network devices (we propose the IP-
      restricted SAKEM procedure and technology), and
   B) the SNMPv3 user management function is facilitated with a
      simple integration scheme that do not change the original
      SNMPv3 security model.
Obviously, the present proposal reliance on RADIUS is mostly for
convenience of feasability demonstration.

      This proposal author does not claim that a session-oriented
security protocol is inappropriate for SNMPv3 (e.g. we do nothing
about the 150 seconds anti-replay protection timeout). However,
we suggest that SNMPv3 difficulties can also be addressed
differently.

5. Intellectual Property Notice

      The SAKEM procedure and technology is covered by the United
States patent number 6,061,791. Generally speaking, if
proprietary elements of the SAKEM procedure and technology
becomes part of a publicly available standard established by an
open standardization body, CONNOTECH is willing to negotiate
licenses for these intellectual property rights on reasonable and
nondiscriminatory terms and conditions. Please contact CONNOTECH
Experts-conseils inc. for further details.

6. References

[COMPAR]
      R. Presuhn, Ed., U. Blumenthal, L. Dondeti, E. Rescorla,
      "Comparison of Proposals for Integrated Security Models for
      SNMP (Simple Network Management Protocol)", Internet-Draft,
      draft-ietf-isms-proposal-comparison-00.txt, February 13,
      2005

[AUDIO]
      audio recording file ietf62-ch5-mon-eve.mp3 retrieved from
      the IETF web site

[MSG445]
      a mailing list message from Wes Hardaker about "design
      decisions in SBSM",
      http://www1.ietf.org/mail-archive/web/isms/current/msg00445.
      html

[SAKEM_WP]
      http://www.connotech.com/sakem_white_paper_06.htm

[SAKEM_IND]
      http://www.connotech.com/sakem_index.htm

[MSG319]
      http://www1.ietf.org/mail-archive/web/isms/current/msg00379.
      html

[RFC3415]
      B. Wijnen, R. Presuhn, K. McCloghrie, "View-based Access
      Control Model (VACM) for the Simple Network Management
      Protocol (SNMP)", RFC3415, December 2002

[SSH_ARCH]
      draft-ietf-secsh-architecture-21.txt

[RFC2865]
      C. Rigney, S. Willens, A. Rubens, W. Simpson, "Remote
      Authentication Dial In User Service (RADIUS).", RFC-2865,
      June 2000

[OPSEC]
      draft-ietf-opsec-current-practices-00.txt

[CCM]
      Morris Dworkin, "Recommendation for Block Cipher Modes of
      Operation: The CCM Mode for Authentication and
      Confidentiality", NIST Special Publication 800-38C, May 2004

[RFC3414]
      U. Blumenthal, B. Wijnen, "User-based Security Model (USM)
      for version 3 of the Simple Network Management Protocol
      (SNMPv3)", RFC-3414, December 2002

-- 

- Thierry Moreau

CONNOTECH Experts-conseils inc.
9130 Place de Montgolfier
Montreal, Qc
Canada   H2M 2A1

Tel.: [phone]
Fax:  [phone]

web site: http://www.connotech.com
e-mail: [e-mail]



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

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