Network Working Group                                     W. Doonan
Internet Draft                                  Surety Technologies
Expires April 20, 2000

                   SPKM with Shared Secret Keys (SSKM)
                      <draft-ietf-cat-sskm-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.

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 presents a method for using [SPKM] with exclusively
shared secret key technologies.  The messages and tokens of [SPKM] are
unchanged; the only modifications required are to replace the default
public-key cipher suite with ciphers and algorithms 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].  Integrity
algorithms and key establishment algorithms suitable for use with
secret keys are added to those specified in [SPKM], which are well
known and specified for use in other existing IETF standards.  We in
effect implement the implicit authenticated key exchange protocol
proposed in [BR94] using the messages and tokens defined in [SPKM].

An overview and brief discussion of the protocol 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.


. Overview


                                                                Page 1

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

The token formats and messages defined in [SPKM] are used without
modification, but employ only shared secret key technologies for
authentication and computation of session keys.  The rationale 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.

Well-known algorithms such as [DES] and [HMAC] are used, 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 with a strong existing proof of security, we avoid
introducing new cryptographic transforms or protocols requiring
extensive new analysis.


1.1  Two-Party Authenticated Key Exchange

The authentication and key establishment algorithms presented here
have 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 threat model.  The protocol variant implemented here
is 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.

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


                                                                Page 2

   function.  The strong pseudorandom permutation function is seeded
   with the shared secret key.

The key exchange algorithm 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 here
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.  However,
[DES] is only being here 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, no changes to the token formats or messages
defined in [SPKM] are required to operate with shared secrey keys, and
all existing operating modes are preserved.  The only changes to
[SPKM] required 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
md5WithRSAEncryption.  To use [SPKM] with shared secret keys,
additional integrity algorithms are needed. When operating this way 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)
        }


                                                                Page 3

        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.  To operate exclusively 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
        }

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

When using [SPKM] exclusively with shared secret keys, there are no
certificates present and hence various required name fields must be


                                                                Page 4

obtained and expressed in some alternate form.  We thus 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

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
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

When using [SPKM] with shared secret keys, 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


                                                                Page 5

[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

When using [SPKM] with shared secret keys, 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 protocol, 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
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


                                                                Page 6

been exchanged, all SPKM-MIC, SPKM-WRAP, and SPKM-DEL messages are
unchanged.


. Security Considerations

The authentication and key establishment algorithms presented here
were 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
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 system is directly
related to the strength of the keys in use.  The shared secret keys
used here should conform to the usual and well-known criteria for
selecting strong keys.


4.3  Session key computation

A strong pseudorandom permutation function is required 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.



                                                                Page 7

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 [SPKM].


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
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.


.  Intellectual Property Rights

The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to per-
tain to the implementation or use of the technology described in this
document or the extent to which any license under such rights might
or might not be available; neither does it represent that it has made
any effort to identify any such rights.  Information on the IETF's
procedures with respect to rights in standards-track and standards-
related documentation can be found in BCP-11.  Copies of claims of
rights made available for publication and any assurances of licenses
to be made available, or the result of an attempt made to obtain a
general license or permission for the use of such proprietary rights
by implementors or users of this specification can be obtained from
the IETF Secretariat.

The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard.  Please address the information to the IETF Executive
Director.



                                                                Page 8

. 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 April 20, 2000                                          Page 9