Network Working Group                                     W. Doonan
Internet Draft                                  Surety Technologies
Expires November 19, 1999

                   SPKM with Shared Secret Keys (SSKM)
                      <draft-ietf-cat-sskm-00.txt>


Status of this Memo

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

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

This document describes a low-infrastructure, shared secret key
authentication mechanism for use with [GSS2].  The mechanism consists
of using the mechanism specified in [SPKM] with shared secret keys.
The only modification required to use [SPKM] without public-key
certificates is to replace the default public-key cipher suite with
ciphers suitable for use with shared secret keys.

All messages and tokens defined in [SPKM] are preserved; no changes
are required to the various authentication modes of [SPKM].  The
mechanism described here adds new integrity algorithms and a new key
establishment algorithm to those specified in [SPKM], however those
algorithms are well understood and have already been accepted for use
in other IETF standards.  This mechanism in effect implements the
implicit authenticate key exchange protocol proposed in [BR94] using
the messages and tokens defined in [SPKM].

An overview and brief discussion of the mechanism appears in section
.  The specific algorithms and object identifiers are listed in
section 2.  Discussion of how [SPKM] messages are used with shared
secret keys appears in section 3.  Security concerns are addressed in
section 4.  Patent issues are covered in section 5.



                                                                Page 1

.  Mechanism overview

The purpose of any [GSS2] mechanism is to establish a security context
between peers for use in securing communications between those peers.
In turn, the mechanism specified in [SPKM] provides the means for
peers to use digital certificates for both authentication and for
computing session keys.

The mechanism described here uses the token formats and messages
defined in [SPKM], but employs only shared secret key technologies for
authentication and computation of session keys.  The rationale behind
this mechanism is to provide a bridge between existing secret key
(username/password or token-based) infrastructures and more scalable
infrastructures based on digital signatures and certificates.

Implementing a new security infrastructure is difficult, and ideally
should be implementable in a series of discrete steps.  This mechanism
allows an organization to implement a security framework based on
[GSS2] while still retaining their existing secret key infrastructure.
The organization can then at a later time move to public-key digital
certificates, or a mix of public-key certificates and shared secret
key systems, by simply using different cipher suites with the same
protocol, rather than changing the protocol itself.

Further, the mechanism specified here uses well-known algorithms such
as [DES] and [HMAC], which have also been extensively analyzed, and in
fact are required by recently-adpoted standards such as [IKE].  By
using both existing algorithms and a protocol that has been proven to
be secure against a real-world threat model, we avoid introducing new
cryptographic transforms or protocols requiring extensive new
analysis.


1.1  Two-Party Authenticated Key Exchange

The mechanism proposed here has been extensively analyzed by Mihir
Bellare and Phillip Rogaway in [BR94].  In this paper the authors
prove the security of a series of two-party, shared secret key
authentication and key exchange protocols against a strong adversary
threat model.  The mechanism proposed here implements the implicit key
exchange variant, referred to in the paper as AKEP2.  The protocol
conversation is summarized below:

A. The initiator generates a random number and sends it to the target.

B. The target generates another random number and sends both random
   numbers back to the initiator, along with an integrity value
   computed using both random values and a shared secret key.

C. The initiator uses both random values and the shared secret key to
   compute the expected integrity value.  If the integrity value sent
   by the target matches the computed integrity value, the target is
   authenticated.


                                                                Page 2

D. The initiator sends the target's random value back to the target,
   along with an integrity value computed using the target's random
   value and the shared secret key.

E. The target uses the random value and the shared secret key to
   compute the expected integrity value.  If the integrity value sent
   by the initiator matches the computed integrity value, the
   initiator is authenticated.

F. Both initiator and target compute a session key by passing the
   target's random value through a strong pseudorandom permutation
   function.  The strong pseudorandom permutation function is seeded
   with the shared secret key.

The key exchange mechanism is referred to as "implicit" because the
eventual session key is computed using the random values exchanged
during mutual authentication.  Steps A through E are essentially
identical to the SPKM-1 operating mode when used with mutual
authentication, hence [SPKM] can be used to implement this portion of
AKEP2 directly.

Step F is essentially a new key establishment algorithm, and hence can
be chosen as the desired K-ALG during initial algorithm negotiation.
The key establishment algorithm in step F is based on using a strong
pseudorandom permutation function, rather than a simple pseudorandom
number generator.  [BR94] identifies [DES] as a good candidate for
such a function, hence the key establishment algorithm specified for
this mechanism is [DES].

Use of [DES] in this manner is prone to confusion, as [DES] is
normally used as a confidentiality algorithm, and is also under fire
as being relatively insecure for confidentiality purposes.  In this
mechanism, however, [DES] is being used for it's pseudorandom
permutation properties, and only for computing a session key, rather
than as a means for encrypting actual data traffic.  In addition,
[BR94] only requires that the key establishment algorithm exhibit
strong pseudorandom permutation properties; thus if [DES] is
considered unsuitable for use even in this capacity it can be replaced
with other functions with better or stronger permutation properties.


.  Algorithms, Name Types, and Object Identifiers

As mentioned above, this mechanism makes no changes to the token
formats or messages defined in [SPKM].  Additionally, this mechanism
can operate using exchange of random values as in SPKM-1, or using
loosely-synchronized clocks as in SPKM-2.  The only changes required
to SPKM to operate exclusively with shared secret keys is to augment
the choice of integrity and key establishment algorithms.

2.1  Integrity Algorithm (I-ALG)

The MANDATORY message integrity algorithm specified in [SPKM] is


                                                                Page 3

md5WithRSAEncryption.  As the mechanism presented here does not use
public-key certificates, additional integrity algorithms are needed.
When [SPKM] is used with shared secret keys, we allow the I-ALG to be
any of the [HMAC] transforms currently defined for use in [IKE].

Examples:

        HMAC-MD5 OBJECT IDENTIFIER ::= {
                iso(1) org(3) dod(6) internet(1) security(5) mechanisms(5)
                ipsec(8) isakmpOakley(1) HMAC-MD5(1)
        }

        HMAC-SHA OBJECT IDENTIFIER ::= {
                iso(1) org(3) dod(6) internet(1) security(5) mechanisms(5)
                ipsec(8) isakmpOakley(1) HMAC-SHA(2)
        }

        HMAC-TIGER OBJECT IDENTIFIER ::= {
                iso(1) org(3) dod(6) internet(1) security(5) mechanisms(5)
                ipsec(8) isakmpOakley(1) HMAC-TIGER(3)
        }

        HMAC-RIPEMD160 OBJECT IDENTIFIER ::= {
                iso(1) org(3) dod(6) internet(1) security(5) mechanisms(5)
                ipsec(8) isakmpOakley(1) HMAC-RIPEMD160(4)
        }

To ensure interoperability, HMAC-SHA is the MANDATORY integrity
algorithm.


2.2  Confidentiality Algorithm (C-ALG)

Using [SPKM] with shared secret keys does not require changes to the
set of available confidentiality algorithms.


2.3  Key Establishment Algorithm (K-ALG)

The MANDATORY algorithm for key establishment specified in [SPKM] is
RSAEncryption.  As the mechanism presented here does not use public-
key certificates, additional key establishment algorithms are needed.
To use [SPKM] with shared secret keys, the session key is computed by
randomizing the exchanged random key material with a suitable strong
pseudorandom permutation function.  The [DES] algorithm is one such
algorithm, and is in fact recommended by [BR94].

        DES-CBC OBJECT IDENTIFIER ::= {
                iso(1) identified-organization(3) oiw(14) secsig(3)
                algorithm(2) 7
        }




                                                                Page 4

The key establishment algorithm is applied to the random value
generated by the target, as in section 1.1.F.


2.4  One-Way Function for Subkey Derivation (O-ALG)

Using [SPKM] with shared secret keys does not require changes to the
set of available one-way functions for subkey derivation.


2.5  Name Types

This mechanism allows the use of existing shared secret key
infrastructures such as username/password with software systems
secured with [GSS2].  As there are no public key certificates in use,
user name and server name information must be obtained and expressed
in some alternate form.  When using [SPKM] with shared secret keys we
express names using the name forms and object identifiers defined in
[GSS2].

        gss-host-based-services OBJECT IDENTIFIER ::= {
                iso(1) org(3) dod(6) internet(1) security(5) nametypes(6)
                gss-host-based-services(2)
        }

        user-name OBJECT IDENTIFIER ::= {
                iso(1) member-body(2) United States(840) mit(113554)
                infosys(1) gssapi(2) generic(1) user_name(1)
        }


.  Using SPKM with shared secret keys

As explained above, this mechanism does not modify the token formats
or messages defined in [SPKM], but rather uses the algorithms listed
above to securely authenticate and exchange session key meterial using
existing [SPKM] messages.

When using [SPKM] with shared secret keys, the purpose of the initial
message exchange is to both authenticate the parties to the exchange
and to agree upon some randomly-generated key material.  The protocol
presented in [BR94] can be expressed directly through use of SPKM-1
with mutual authentication enabled.  However, the additional message
exchanges (SPKM-2) and authentication modes (unilateral) supported by
[SPKM] can also be used when operating with shared secret keys.

All authentication exchanges and modes eventually allow the peers to
reliably exchange some random key material.  The random key material
is used to compute a session key according to the method detailed in
section 1.1.F.  The session key is computed by encrypting the random
key material with [DES], in this case using a subkey derived from the
shared secret key according to the agreed upon one-way function and



                                                                Page 5

key derivation algorithm.  The computed session key is then used to
derive all other subkeys according to normal [SPKM] practices.


3.1  SPKM-REQ message

As this mechanism uses [SPKM] without public key certificates, various
optional fields in the message are always absent.  The "certif-data",
"auth-data", "validity", and "key-src-bind" fields are all absent, and
the "options" field of the "Context-Data" structure cannot have the
"target-certif-data-required" bit set.  The "key-estb-req" field is
also empty, except for unilateral authentication of initiator to
target using SPKM-2.  In this case the "key-estb-req" field contains
the random key material to be used in computing the session key.

The "src-name" field MUST contain a name indicating the identity of
the initiator, so that the target can find the secret key it shares
with the initiator.  For example, in applications with existing
username/password infrastructures, the "src-name" would be a username
encoded in the user-name name form.  All other fields are filled with
values appropriate for the current [SPKM] operating mode.

The "req-integrity" field is formed by computing any of the supported
[HMAC] transforms on the "req-contents" field, as with other I-ALGs.
The key used by the [HMAC] transform to compute the integrity value is
derived from the shared secret key according to the key derivation
algorithm defined in Section 2.4 of [SPKM].

The "owf-alg" field of the "Context-Data" structure MUST have as its
first element the OID of the one-way function used by the subkey
derivation algorithm to compute the key used in the [HMAC] transform.


3.2  SPKM-REP-TI message

As this mechanism uses [SPKM] without public key certificates, the
optional "certif-data" and "validity" fields are always absent.  The
"key-estb-str" field contains the random key material used to compute
the session key.  All other fields are filled with values appropriate
to the current [SPKM] operating mode.  The "rep-ti-integ" field is
formed in the same manner as the "req-integrity" field is formed in
section 3.1.

The protocol presented in [BR94] and summarized in section 1.1 uses a
single random number generated by the target to both authenticate the
initiator and target, and for computing the session key.  When
implemented using [SPKM], we use the "randTarg" value to authenticate
the parties, and the "key-estb-str" value as the value from which we
compute the session key.  Separating the values does not violate the
security of the mechanism, as both fields are part of the integrity
computation.  Separating them allows the random values used to
authenticate the parties to be fixed length, while allowing the key



                                                                Page 6

material exchanged for use in computing session keys to vary in
length, to suit the needs of the integrity and confidentiality
algorithms negotiated by the parties.  Separating the values also
follows good cryptographic practice of using a single entity for a
single purpose.


3.3  SPKM-REP-IT message

The "key-estb-rep" field is always absent, while all other fields are
filled with values appropriate to the current [SPKM] operating mode.
The "rep-it-integ" field is formed in the same manner as the "req-
integrity" field is formed in section 3.1.


3.4  SPKM-ERROR message

All fields are filled with values appropriate to the current [SPKM]
operating modes.  The "integrity" field is formed in the same manner
as the "req-integrity" field is formed in section 3.1.


3.5  Other messages

Once the initial authentication and key establishment messages have
been exchanged, all SPKM-MIC, SPKM-WRAP, and SPKM-DEL messages are
unchanged.


. Security Considerations

This mechanism was proven secure in [BR94] according to the realistic
threat model also presented in that paper.  The theorems and proofs
are presented in the paper and are outside the scope of this document.
The paper makes certain cryptographic requirements on various
primitives used in constructing the protocol, however.


4.1  Random values

The protocols presented in [BR94] require that the random challenges
be "unpredictable", in the cryptographic sense, rather than simple
nonces.  The [SPKM] specification, however, requires only that the
random challenges be "fresh".  Hence, using [SPKM] with shared secret
keys imposes additional requirements on the process used to generate
the random challenges.

While it is impossible to generate "unpredictable" random values
algorithmically, one can use software functions that gather entropy
to generate "unpredictable" values of reasonable quality.  An example
of an entropy-based random number generator can be found in the
CryptoLib software package, written by Matt Blaze et.al. at AT&T



                                                                Page 7

Labs.  This package includes a "truerand" function which uses the
variability of the number of times a simple calculation can occur
within a fixed amount of clock time on common timesharing operating
systems.  This approach works well compared to other entropy gathering
algorithms that capture mouse clicks and keyboard events, and which
thus require user interaction.


4.2  Shared secret keys

As with any cryptosystem, the security of this mechanism is directly
related to the strength of the keys in use.  The shared secret key
used by this mechanism should conform to the usual and well-known
criteria for selecting strong keys.


4.3  Session key computation

This mechanism requires a strong pseudorandom permutation function in
order to compute the negotiated session key.  [BR94] suggests that the
[DES] algorithm, while under strong attack as an encryption algorithm,
is suitable for use as a strong pseudorandom permutation function.
Rather than invent a new generator, then, we choose to follow this
recommendation and use [DES] to compute session keys. However, when the
pseudorandom properties of [DES] are called into question the
algorithm can be replaced with a different key establishment
algorithm, such as 3DES.


4.4  Message integrity

The message integrity functions used in [BR94] are based on strong
pseudorandom generators, such as DES-MAC or md5-DES-CBC.  The paper
also lists pure hash functions as possible candidates, but warns that
their security characteristics in this application are less well
justified.  However, in the time since [BR94] was initially published
the authors have developed and analyzed the [HMAC] constructions,
which in turn have been deemed suitably strong for use in other IETF
standards.  Hence we add them to the list of recommended integrity
algorithms for this mechanism.


4.5 Initial subkey derivation

Two keys are needed during initial message exchange, one to compute
integrity values on the messages and one to compute the eventual
session key.  [BR94] uses the same shared secret key both for
computing integrity values and for computing the session key.  To
avoid concerns about using a single cryptographic object for two
different purposes, the two keys used during initial message exchange
are derived from the single shared secret using the key derivation
algorithm specified in Section 2.4 of [SPKM].  An integrity subkey is



                                                                Page 8

derived from the single shared secret and used to compute the [HMAC]
integrity values on all initial messages.  Likewise a confidentiality
subkey is derived from the single shared secret and is used to compute
the negotiated session key.  The one-way function used to derive these
initial subkeys is indicated in the "owf-alg" field of the
"Context-Data" element included in the initial message exchange.


.  Patent Information

There are no known patent claims for this mechanism.


. References

[GSS2] J. Linn, "Generic Security Service Application Program
Interface, Version 2," RFC 2078, January 1997.

[SPKM] C. Adams, "The Simple Public-Key GSS-API Mechanism (SPKM),"
RFC 2025, October 1996.

[BR94] M. Bellare, P. Rogaway,  "Entity Authentication and Key
Distribution," Extended abstract in Advances in Cryptology - Crypto 93
Proceedings, Lecture Notes in Computer Science Vol. 773, D. Stinson
ed, Springer-Verlag, 1994.

[DES] ANSI X3.106, "American National Standard for Information
Systems-Data Link Encryption," American National Standards Institute,
1983.

[HMAC] H. Krawczyk, M. Bellare, R. Canetti, "HMAC: Keyed-Hashing for
Message Authentication," RFC 2104, February 1997.

[IKE] D. Harkins, D. Carrel, "The Internet Key Exchange (IKE),"
RFC 2409, November 1998.


. Authors' Addresses

Address comments related to this submission to:

        cat-ietf@mit.edu

Wes Doonan
Surety Technologies Inc.
 Preston White Drive
Reston, VA  20191
wes@surety.com







Expires November 19, 1999                                       Page 9