Internet Draft R. Moskowitz Document: draft-moskowitz-sspp-snmp-00.txt ICSAlabs Expires: July 2003 January 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]. Moskowitz Expires - July 2003 [Page 1]
SSPP over SNMP January 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 Validating the Diffie-Hellman Public Keys..................6 3. Additional exchanges...........................................6 3.1 Changing a shared secret...................................6 3.2 Proxying SSPP through an established Client................7 4. Application of SSPP over SNMP..................................8 4.1 EXAMPLE: RADIUS Client Secret..............................9 Security Considerations...........................................9 References.......................................................10 Acknowledgments..................................................10 Author's Addresses...............................................10 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. SSPP is presented in three forms. The principle 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: Moskowitz Expires - July 2003 [Page 2]
SSPP over SNMP January 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 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 +-------------+ +-------------+ | SSPP Client | | SSPP Server | | | SSPP | | | |<-------------------------->| | | SNMP Manager| SNMP | SNMP Agent | | | | | +-------------+ +-------------+ Figure 1. Basic system flow +-------------+ +-------------+ +-------------+ | SSPP Client | | SSPP Proxy | | SSPP Server | | | SSPP | | SSPP | | | |<-------->| |<-------->| | | SNMP Manager| SNMP | SNMP Agent/ | SNMP | SNMP Agent | | |<-+ | Manager| +->| | +-------------+ | +-------------+ | +-------------+ | SSPP | +-----------------------------+ SNMP Moskowitz Expires - July 2003 [Page 3]
SSPP over SNMP January 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 Moskowitz Expires - July 2003 [Page 4]
SSPP over SNMP January 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 Moskowitz Expires - July 2003 [Page 5]
SSPP over SNMP January 2003 Else Generate SigS, New NonceS C: GET SigS until not NULL If SigS is "Error", stop 2.1 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. 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 Moskowitz Expires - July 2003 [Page 6]
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----------> <-------Response-------- ---SET-----> -----SET---> ---GET-----> <-Responseù ----------GET----------> <-------Response-------- The exchange and process are: S: Generate NonceS C: GET from S - Parms, DHS, NonceS, AddressS Moskowitz Expires - July 2003 [Page 7]
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)) 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)) 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)) 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. 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. Moskowitz Expires - July 2003 [Page 8]
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). 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. Moskowitz Expires - July 2003 [Page 9]
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. 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 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. Author's Addresses Robert Moskowitz TruSecure/ICSAlabs 1000 Bent Creek Blvd, Suite 200 Mechanicsburg, PA Email: rgm@trusecure.com Moskowitz Expires - July 2003 [Page 10]