wdiff draft-moskowitz-sspp-snmp-00.txt draft-moskowitz-sspp-snmp-01.txt

Internet Draft R. Moskowitz
Document: draft-moskowitz-sspp-snmp-00.txt draft-moskowitz-sspp-snmp-01.txt ICSAlabs
Expires: July 2003 January May 2004 November 2003

SSPP over SNMP

Status of this Memo

This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [1].

Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.

Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

Abstract

The Shared Secret Provisioning Protocol (SSPP) [2] provides the both
the cryptographic functions and the basic protocol for provisioning
shared secrets based on a Diffie-Hellman key exchange. This
document describes the basic SNMP functions to support SSPP.

Conventions used in this document

In examples, "C:" and "S:" indicate activities by the SSPP client
and SSPP server respectively. "P:" indicate activities by the SSPP
proxy.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC-2119 [3].

SSPP over SNMP January November 2003

Table of Contents

1. Introduction...................................................2
1.1 Reasoning for using SNMP as an SSPP transport..............2
1.2 Terms and Protocol components..............................3
1.3 Variables used.............................................4
1.4 The MIB objects............................................4
2. The basic SNMP exchange........................................5
2.1 Timing to generate Shared Secret...........................6
2.2 Validating the Diffie-Hellman Public Keys..................6
3. Additional exchanges...........................................6
3.1 Changing a shared secret...................................6 secret...................................7
3.2 Proxying SSPP through an established Client................7
4. Application of SSPP over SNMP..................................8 SNMP..................................9
4.1 EXAMPLE: RADIUS Client Secret..............................9
Security Considerations...........................................9
References.......................................................10
Acknowledgments..................................................10
Author's Addresses...............................................10 Addresses...............................................11

1. Introduction

The Shared Secret Provisioning Protocol (SSPP) provides the
cryptographic functions and basic protocol for provisioning strong,
shared secrets. For SSPP to be deployed, it needs a transport-layer
protocol. This document describes the use of SNMP for transporting
SSPP. In this usage, SSPP is an application on top of SNMP.

SSPP is presented in three forms. The principle principal form is the basic
exchange. An important adjunct form is the modified exchange for
changing the shared secret where there already is a relationship
between the client and server. Finally there is the proxy exchange
where the server's policy restricts it to only one client using the
basic exchange, but that client can act as a proxy to other clients.

At this state in its development, SSPP over SNMP is very general.
It will evolve through reviews and its application in provisioning
existing shared secrets like the shared secret between a RADIUS
Client and Server.

1.1 Reasoning for using SNMP as an SSPP transport

There are many shared secrets that protect machine-to-machine or
process-to-process datagrams. SNMP is a common protocol on the
systems that have these shared secrets, making it an attractive
transport for SSPP. SNMP is attractive for transporting SSPP for
the following additional reasons:

SSPP over SNMP January November 2003

Shared secrets are typically the first item to be configured in a
new deployment and at the 'out of the box' state, SNMP is ready to
configure and use in most systems.

The SSPP client needs to discover the SSPP server after the later is
deployed. SNMP has a well-developed system discovery methodology.

SNMP is a very lightweight protocol to use in small headless
devices.

1.2 Terms and Protocol components

SSPP is a Client/Server protocol that can use a specialized proxy.
In this standard, all references to Client, Server are SSPP clients
and servers unless specifically named (e.g. RADIUS Server). All
references to a proxy are for an SSPP proxy. SNMP components are
Agents and Managers as follows:

SSPP SNMP

Client Manager
Server Agent
Proxy Agent to the SSPP client
Manager to the SSPP server

Figure 1. Basic system flow

SSPP over SNMP January November 2003

Figure 2. Proxied system flow

1.3 Variables used

AddressC The address of the Client, as chosen by the Client
AddressP The address of the Proxy, as chosen by the Proxy
AddressS The address of the Server, as chosen by the Server
DHC The Client's Diffie-Hellman public key
DHS The Server's Diffie-Hellman public key
NonceC Nonce from the Client
NonceS Nonce from the Server
Parms Diffie-Hellman Domain Parameters
SigC The HMAC signature generated by the Client
SigP The HMAC signature generated by the Proxy
SigS The HMAC signature generated by the Server

1.4 The MIB objects

The Server has some specific MIB objects and two tables of objects
for each Client. The Proxy also has a table of objects. The Server
specific objects are:

Domain Parameters
Diffie-Hellman key pair (the private key MUST be protected from
reading)
Server Address
Nonce

The Server's Client table objects are:

Client Address
Client Diffie-Hellman public key
Client Nonce
Client Signature
Server Signature
Change Flag
Shared Secret (MUST be protected from reading)

The Server's Proxied Client table is a temporary table with objects:

Proxy Address
Proxy Signature
Client Address
Client Diffie-Hellman public key
Client Nonce
Client Signature
SSPP over SNMP January November 2003

Server Signature
Shared Secret (MUST be protected from reading)

The Proxy's Client table is a temporary table with objects:

Client Address
Client Diffie-Hellman public key
Client Nonce
Client Signature
ForwardFlag
Proxy Signature

A Client SHOULD keep the following objects in the MIB:

Domain Parameters
Diffie-Hellman key pair (the private key MUST be protected from
reading)
Client Address
Nonce
Server Address
Server Signature
Proxy Address
Shared Secret (MUST be protected from reading)

2. The basic SNMP exchange

Using SNMP for SSPP presents a few challenges that are not new to
SNMP. There are two processes performed by the server: generating a
Nonce and generating the shared secret along with a signature.
Since there is no concept of a Request/Process/Response in SNMP, the
practice is to set one MIB object to poke to start the process.
Another MIB object is polled to see the status of the process, and a
third object is queried for the answer when the status object says
the process is done. That would be for a process that's slow
compared to network round-trip times like the shared secret
generation. The Nonce can be handled by having it set at system
start time and immediately after a shared secret is generated, so it
is ready for a second SSPP exchange.

S: Generate NonceS
C: GET Parms, DHS, NonceS, AddressS
C: If the Server's Parms do not match Client's, stop
If the Public key is not valid, stop
Else Generate NonceC, Shared Secret, SigC
C: SET AddressC, NonceC, DHC, SigC
(note: setting the Signature starts the process on the Server)
S: set SigS as NULL, Generate Shared Secret
If SigC is not valid, set SigS as "Error" and stop
SSPP over SNMP January November 2003

Else Generate SigS, New NonceS
C: GET SigS until not NULL
If SigS is "Error", stop

2.1 Timing to generate Shared Secret

For keys of 128 bits and a 1 MIP machine that can do a
multiplication in one cycle, it will take about 3 seconds for a 2048
bit modulus and 7 seconds for a 3072 bit modulus Diffie-Hellman key
derivation. These are extremely rough estimates, but they are
seconds, not minutes. This also assumes that Client has precomputed
g^a and Server has pre-computed g^b. If they haven't, then double
the estimates.

2.2 Validating the Diffie-Hellman Public Keys

The SSPP client MUST present DHS to some form of validation process.
This might be in a UI as a fingerprint of the public key for visual
inspection. A recommended fingerprint of the public key is a SHA1
hash. If 160 bits is too large for visual inspection an LTRUNC96
can be used to reduce the fingerprint to 96 bits. An X.509 Diffie-
Hellman certificate may be used instead of a raw public key for
implementations where a PKI can be deployed.

SSPP does not require the server to validate DHC. This presents a
policy challenge: the server has no way of controlling which clients
negotiate a shared secret. SSPP does provide for a binding by the
client between AddressC and DHC. In controlled situations, this
could be used in a control policy.

The preferred control method is to allow only one client to use SSPP
to directly establish a shared secret with a server. In this
manner, if the server rejects an SSPP exchange, this could be a
signal that a rouge client has taken that one client slot with the
server. If the intended implementation can have multiple clients
per server, the proxy method described below can be used for the
additional clients.

3. Additional exchanges

There are two special forms of the SSPP exchange. One is to support
changing the shared secret and the other to proxy the SSPP exchange
through a client that already has a shared secret with the server.

SSPP over SNMP November 2003

3.1 Changing a shared secret

To change a shared secret, new pair of nonces are used with an
existing set of Diffie-Hellman keys and addresses. The exchange is:

S: Generate NonceS
C: GET NonceS
Generate NonceC, Shared Secret, SigC
C: SET AddressC, NonceC, DHC, SigC
(note: setting the Signature starts the process on the Server)
S: If AddressC/DHC is already in the Client MIB table and the new
NonceC is different from the prior NonceC, set Change
SSPP over SNMP January 2003
Flag in old table entry
set SigS as NULL, Generate Shared Secret
If SigC is not valid, set SigS as "Error", clear Change Flag in
old table entry and stop
Else Generate SigS, New NonceS and delete the old
AddressC/DHC table entry
C: GET SigS until not NULL
If SigS is "Error", stop

A successful exchange identifies the client as the owner of DHC and
through the SigC binding of AddressC to DHC, allows the server to
delete the old shared secret and start using the new secret.

NonceC and NonceS MUST be different with each Change. This is to
produce a new shared secret with the same Diffie-Hellman keys and
Addresses. The change in NonceC is also used as a test by the
server to prevent a resource DOS attack against by replaying an old
change request.

3.2 Proxying SSPP through an established Client

When an SSPP server controls which clients it has a shared secret
with by only accepting one SSPP exchange, additional clients can
obtain their shared secret with the server by proxying through the
established client. A second signature complicates the proxied SSPP
exchange. This second signature is between the server and the proxy
to 'authorize' the exchange. To prevent a hidden man-in-the-middle
attack by a rogue proxy, the principle signature is modified to
include the proxy's address. That is the client is aware of the
proxy's role in the exchange.

The datagram flow is:

C P S

----------GET---------->
SSPP over SNMP November 2003

<-------Response--------
---SET----->
-----SET--->
---GET----->
<-Responseù
----------GET---------->
<-------Response--------

The exchange and process are:

S: Generate NonceS
C: GET from S - Parms, DHS, NonceS, AddressS
SSPP over SNMP January 2003
(note the client already has AddressP)
C: If the ServerÆs Parms do not match Client's, stop
If the Public key is not valid, stop
Else Generate NonceC, Shared Secret, SigC
(note SigC uses (Public key || AddressC || AddressP || NonceC)) NonceS))
C: SET to P û AddressS, AddressC, NonceC, DHC, SigC
(note: setting the Signature starts the process on the Proxy)
P: set ForwardFlag to Null
If the Proxy does not have a Shared Secret with AddressS,
Set ForwardFlag to "Error" and stop
Generate SigP
(note SigP uses (Public key || AddressC || AddressP || NonceC)) NonceS))
P: SET to S û AddressP, AddressC, NonceC, DHC, SigC, SigP
set ForwardFlag to AddressS
(note: setting the Signature starts the process on the Server)
S: set SigS as NULL, Generate Shared Secret
If the Server does not have a Shared Secret with AddressP,
set SigS as "ErrorP" and stop
If SigP is not valid, set SigS as "ErrorP" and stop
If SigC is not valid, set SigS as "Error" and stop
Else Generate SigS, New NonceS
(note SigS uses (AddressS || AddressP || NonceS)) NonceC))
C: GET from P - ForwardFlag until not NULL
If ForwardFlag is "Error", stop
C: GET from S - SigS until not NULL
If SigS is "Error" or "ErrorP", stop

The Client may start checking ForwardFlag as soon as it performs the
SET operation to the Proxy. Since the Proxy only acts as an
'introducer' of the client to the server, the server checks SigC for
inclusion of AddressP, and the client gets SigS directly from the
Server, a rogue cannot insert itself between an SSPP client and
server and force a proxied exchange. Once a client has a shared
secret with a server, it can directly change the shared secret and
can itself be a proxy for another client.

SSPP over SNMP November 2003

4. Application of SSPP over SNMP

SSPP over SNMP is well suited to provisioning shared secrets where
the SSPP server is 'headless'. That is where the server does not
have a UI. Traditionally these sorts of systems are either forced
to have a server, like HTTP, implementation to support
configuration, or SNMP is used in an insecure method to configure
the secret, leaving it up to the deployer to deal with the risk of
secret theft. SSPP not only provides a secure provisioning
methodology, it produces strong shared secrets and provides for
managing those secrets.

SSPP over SNMP January 2003

4.1 EXAMPLE: RADIUS Client Secret

The RADIUS Client Secret is used to authenticate RADIUS exchanges
between a RADIUS Server and its client(s). With the advent of IEEE
802.1x [4], RADIUS clients are proliferating in the form of 802.3
switches and 802.11 access points. The problems in managing the
RADIUS Client Secret are broader than just getting a good secret and
managing it. This is detailed in RADIUS Client Kickstart [5], but
the general usage is as follows.

To protect against a rogue RADIUS server, the RADIUS client will
only allow one server to directly setup a shared secret via SSPP.
If the server gets an SSPP error, it can assume that a rouge server
authenticated first, and that the client needs to be reset. This
will typically be a physical reset button on the client (perhaps
part of the factory reset function). If the RADIUS client has more
than one RADIUS server, the additional servers will use the first
server as their SSPP proxy.

Security Considerations

This protocol uses an unauthenticated Diffie-Hellman exchange. This
is open to a Man-in-the-Middle attack. The recommended practice for
this is that there MUST be a mechanism for the client to validate
the serverÆs Diffie-Hellman public key, or for a risk-appropriate
assurance that there is no man in the middle between the client and
server.

The former can be addressed by client system presenting in its UI
the fingerprint of the public key. The operator would check the
fingerprint with a copy obtained out-of-band (for example stamped on
the server). The later can be addressed by connecting the client
and server with a crossover cable or by trusting the deployed
cabling (as in a small office).

SSPP over SNMP November 2003

The server is potentially open to establishing a shared secret with
any system. Since the SSPP server is typically a client for all
other services, this could leave it open to attack through the
services that the shared secret is suppose to protect. As such a
server might have a policy to only allow one client to use the basic
exchange and all additional clients must use the proxy exchange.
Typically, the first client, while the server is in factory default
state, will be able to use the basic exchange. If a rogue client
intervened before the intended client established its shared secret,
this would be discovered and the server could be reset to its
factory default state.

SSPP over SNMP January 2003

The nonces are an important contributor to the shared secret
generation. The current cryptographic literature recommends that
the nonces be twice the length of the desired final key.
Additionally, it is the unique nonces that produce a unique key each
time the Change Secret exchange occurs. The nonces MUST be unique
and random.

References

1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996.

2 Moskowitz, R., "The Shared Secret Provisioning Protocol",
Internet Draft draft-moskowitz-shared-secret-provprotocol-00.txt,
December 2002. draft-moskowitz-shared-secret-provprotocol-02.txt,
November 2003.

3 Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.

4 IEEE Std 802.1X-2001, "Port-Based Network Access Control", June
2001.

5 Moskowitz, R., "RADIUS Client Kickstart", Internet Draft draft-
moskowitz-radius-client-kickstart-01.txt, January
moskowitz-radius-client-kickstart-02.txt, November 2003.

Acknowledgments

This document is the result of the first IETF Credential
provisioning workshop and extracted from the original RADIUS Client
Kickstart Internet Draft. Bob Stewart helped explain how an SNMP
SET can trigger internal processes and how the SNMP manager polls
the SNMP agent for objects set as a result of such a process.

SSPP over SNMP November 2003

Author's Addresses

Robert Moskowitz
TruSecure/ICSAlabs
1000 Bent Creek Blvd, Suite 200
Mechanicsburg, PA
Email: rgm@trusecure.com