Internet Draft R. Moskowitz
Document: draft-moskowitz-shared-secret- ICSAlabs
provprotocol-01.txt
Expires: June 2003 January 2003
Shared Secret Provisioning Protocol
draft-moskowitz-shared-secret-provprotocol-01.txt
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
Shared secrets are common in IETF protocols. Setting these shared
secrets is typically defined as out of scope of those protocols.
The upshot of this approach is poor security practices in setting
these secrets and, through the life of the implementation, changing
these secrets. The Shared Secret Provisioning Protocol (SSPP)
provides a mechanism for both setting and changing shared secrets
that are provably strong.
Conventions used in this document
In examples, "C:" and "S:" indicate activities by the client and
server respectively.
Moskowitz Expires - June 2003 [Page 1]
Shared Secret Provisioning Protocol December 2002
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 [2].
Table of Contents
1. Introduction...................................................2
1.1 Diffie-Hellman and Man-in-the-Middle Attacks...............2
2. The Diffie-Hellman Key Agreement Schemes.......................3
2.1 The Fixed Field Diffie-Hellman exchange....................3
2.2 The Elliptic Curve Diffie-Hellman exchange.................3
2.3 The Key Derivation Function................................4
3. The Shared Secret Provisioning Protocol........................5
3.1 Managing Risk in SSPP......................................6
Security Considerations...........................................6
References........................................................7
Acknowledgments...................................................7
Author's Addresses................................................7
1. Introduction
Provisioning strong, shared secrets is frequently considered as
'out-of-scope' in most protocols that use them. Yet, the quality of
shared secrets has a significant impact on the security
characteristics of these protocols. Many of the attacks are
specifically related to the prevalent use of weak shared secrets.
This calls out for a standard protocol to provisioning strong shared
secrets that can be implemented over case-specific transports.
The Shared Secret Provisioning Protocol (SSPP) provides a mechanism
for both setting and changing shared secrets that are provably
strong. It is based on the well-known properties of a Diffie-
Hellman Key Agreement. Both Fixed Field and Elliptic Curve forms
are available. The key derivation methodology is derived from the
NIST Key Management Schemes proposal [3] which drew heavily on X9.42
and x9.63.
This is a basic exchange; the actual implementation is left to
specific cases. Although SSPP is based on static Diffie-Hellman
keys, the use of nonces permit it to be rerun whenever a new shared
secret is needed without changing a Diffie-Hellman key.
1.1 Diffie-Hellman and Man-in-the-Middle Attacks
Although Diffie-Hellman is commonly used for establishing a secret
between two parties, typically buried within a complex protocol like
Moskowitz Expires - April 2003 [Page 2]
Shared Secret Provisioning Protocol December 2002
IKE [4], Diffie-Hellman by itself has a significant man-in-the-middle
attack. The method used to detect this attack is to validate the
public Diffie-Hellman keys that they really came for the expected
party. This attack is symmetric. That is really only one party
needs to validate the otherÆs public key and back off on the
exchange if the validation fails.
This symmetric property is important as it allows SSPP to be used in
headless devices that cannot easily validate the public key of the
other party.
2. The Diffie-Hellman Key Agreement Schemes
There are many variants defined for Diffie-Hellman Key Agreement
Schemes. They vary first in how many static and ephemeral key pairs
and if the math is Fixed Field or Elliptic Curve. Then they vary in
if the derived Diffie-Hellman secret is used directly or if it is an
input to a keyed hash that produces the actual shared secret.
SSPP uses 2 static and no ephemeral Diffie-Hellman key pairs. Both
Fixed Field and Elliptic Curve methods are allowed. The key produce
from the Diffie-Hellman exchange is inputted into an HMAC-SHA1 [5]
keyed hash along with identities for each party and a large, random
nonce from each party.
2.1 The Fixed Field Diffie-Hellman exchange
Each party has a static key pair (X, Y) that was previously
generated using the same domain parameters (p, q, g). Party C has
(Xc, Yc); party S has (Xs, Ys). Each party must obtain the other
partyÆs static public key. One must obtain the other's in a trusted
manner.
Each party computes the shared secret Zs as shown below, and then
computes the shared secret by invoking the key derivation function
using Zs.
Party C Party S
Input (p, q, g), Xc, Ys (p, q, g), Xs, Yc
Computation Zs = Ys^Xc mod p Zs = Yc^Xs mod p
2.2 The Elliptic Curve Diffie-Hellman exchange
Moskowitz Expires - April 2003 [Page 3]
Shared Secret Provisioning Protocol December 2002
Each party has a static key pair (ds, Qs) that was previously
generated using the same domain parameters (q, FR, a, b, [SEED], G,
n, h). Party C has (dsC, QsC); party S has (dsS, QsS). Each party
must obtain the other partyÆs static public key. One must obtain
the other's in a trusted manner.
Each party computes the shared secret Zs as shown below, and then
computes the shared secret by invoking the key derivation function
using Zs.
Party C Party S
Input (q, FR, a, b, [SEED], (q, FR, a, b, [SEED],
G, n, h), dsC,QsS G, n, h), dsS,QsC
Computation (Xs, Ys) = hdsCQsS (Xs, Ys) = hdsSQsC
Zs = Xs Zs = Xs
2.3 The Key Derivation Function
The key derivation function is used to shared secret from Zs as
follows:
Function call:
kdf(Zs, C, S, keydatalen, hashlen, NonceC, NonceS)
Input description:
1. A bit string Zs is defined above.
2. Bit strings C and S that denote the identities of the
participating parties, where C is the party that initiated the
key establishment process, and S is the responder in the key
establishment process.
3. An integer keydatalen that is the length in bits of the shared
secret to be generated. keydatalen must be less than hashlen x
(2^32-1).
4. An integer hashlen that is the length in bits of the hash
function to be used to derive the shared secret. Thus the
selection of SHA-1, 256, or 512 is determined by the size of the
desired shared secret.
5. Bit strings NonceC and NonceS are nonces from the parties C and S
respectively. The recommended size for the nonces is twice
hashlen.
Moskowitz Expires - April 2003 [Page 4]
Shared Secret Provisioning Protocol December 2002
Process:
a. Initiate a 32-bit, big-endian bit string counter as x00000001.
b. For i=1 to i= int(keydatalen/hashlen), do the following:
Compute Hashi = HMAC-SHAn(Zs,(counter || min(C,S) || max(C,S) ||
keydatalen || hashlen || min(NonceC,NonceS) ||
max(NonceC,NonceS)))
Increment counter
Increment i.
c. Let Hhashj denote Hashj if keydatalen/hashlen is an integer, and
let it denote the (keydatalen - (hashlen x (j-1))) leftmost bits
of Hashj otherwise.
d. Set sharedsecret = Hash1 || Hash2 ||...|| Hashj-1 || Hhashj.
Any attempt to call the key derivation function for a shared secret
of length greater than or equal to hashlen x (2^32-1) bits must
output "invalid" and stop.
3. The Shared Secret Provisioning Protocol
In SSPP, the client is the party that starts the exchange and is
capable of validating the other partyÆs public key. This may well
NOT be the client in the normal sense. For example, if SSPP is used
to set a shared secret between a headless monitoring device and a
data collection server, the server may be the SSPP client, as it may
have a UI to check the fingerprint of the headless device's public
key.
The basic protocol is:
C: REQUEST values from Server
S: Generate NonceS
SEND (Domain parameters, Public key, AddressS, NonceS)
C: If Domain parameters do not match Client's, stop
If the Public key is not valid, stop
Generate NonceC
Generate Shared Secret
SEND (Public key, AddressC, NonceC),
LTRUN96(HMAC-SHA1(Shared Secret, (Public key || AddressC ||
NonceC)))
S: Generate Shared Secret
SEND LTRUNC96(HMAC-SHA1(Shared Secret, (AddressS || NonceS)))
Moskowitz Expires - April 2003 [Page 5]
Shared Secret Provisioning Protocol December 2002
3.1 Managing Risk in SSPP
There are many potential opportunities for attacks against SSPP
unless limits are placed on its usage as a PROVISIONING protocol.
An SSPP implementation MUST have controls placed on servers as to
when they are available to limit attacks against them. A server has
no control over which clients provision secrets with them. A
resource limited headless device could be rendered useless through
this way. It is best if SSPP is only available at device setup time
or when triggered through a process authenticated with an existing
established shared secret.
Since for the server, it is possible to attack the nonce state, the
server implementation could use the same nonce until an SSPP
exchange is completed, and only then select a new nonce for the next
SSPP request.
The client needs some method of validating the serverÆs public key.
This can be through a check of the fingerprint (hash) of the public
key, where the fingerprint was obtained in some out-of-band process.
Or the physical network between the client and server might be such
that no man-in-the-middle is possible (for example with a crossover
cable in a deployment staging area).
Any instantiation of SSPP needs to examine how an attack might occur
and mitigate those attacks.
Security Considerations
This protocol uses an un-authenticated 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,
there must be an external control on the use of SSPP for the
Moskowitz Expires - April 2003 [Page 6]
Shared Secret Provisioning Protocol December 2002
servers. For example, a device might only be an SSPP server when in
factory default state or when put into it via some protocol
authenticated with an existing shared secret.
The size of the Diffie-Hellman keys and the size of the SHA hash
determine the strength of the shared secret. It is up to each
application of SSPP to select these values, based on the needed
shared secret strength.
References
1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996.
2 Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997
3 NIST, "Key Establishment Schemes Workshop Document", November
2001.
http://csrc.nist.gov/encryption/kms/schemes_workshop_doc.pdf
4 Harkins, D., and Carrel, D., "The Internet Key Exchange", RFC
2409, November 1998.
5 Krawczyk, H., and Bellare, R., "HMAC: Keyed-Hashing for Message
Authentication", RFC 2104, February 1997
Acknowledgments
This document is the result of the first IETF Credential
provisioning workshop and extracted from the original RADIUS Client
Kickstart Internet Draft.
Author's Addresses
Robert Moskowitz
TruSecure/ICSAlabs
1000 Bent Creek Blvd, Suite 200
Mechanicsburg, PA
Email: rgm@trusecure.com
Moskowitz Expires - April 2003 [Page 7]