Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/drafts/draft_ietf_a_c/draft-ietf-cat-pktapp-00.txt

Text File | 1997-02-17 | 11KB | 264 lines

INTERNET-DRAFT                                    Ari Medvinsky
Common Authentication Technology Working Group    Matthew Hur
                                                  CyberSafe Corporation

                                                  B. Clifford Neuman
                                                  USC/ISI


                                                  Jan. 97 (Expires July, 97)


Public Key Utilizing Tickets for Application Servers (PKTAPP)


0. Status Of this Memo

This document is an Internet-Draft.  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.''

To learn the current status of any Internet-Draft, please check
the ``1id-abstracts.txt'' listing contained in the Internet-
Drafts Shadow Directories on ftp.is.co.za (Africa),
nic.nordu.net (Europe), munnari.oz.au (Pacific Rim),
ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast).


1. Abstract

Public key based Kerberos for Distributed Authentication[1], (PKDA)
proposed by Sirbu & Chuang, describes PK based authentication that
eliminates the use of a centralized key distribution center while
retaining the advantages of Kerberos tickets.  This draft describes how,
without any modification, the PKINIT specification[2] may be used to
implement the ideas introduced in PKDA.  The benefit is that only a
single PK Kerberos extension is needed to address the goals of PKINIT &
PKDA.


2. Introduction

With the proliferation of public key cryptography, a number of public
key extensions to Kerberos have been proposed to provide
interoperability with the PK infrastructure and to improve the Kerberos
authentication system [4].  Among these are PKINIT[2] (under development in
the CAT working group) and more recently PKDA [1] proposed by Sirbu &
Chuang of CMU.  One of the principal goals of PKINIT is to provide for
interoperability between a PK infrastructure and Kerberos.  Using
PKINIT, a user can authenticate to the KDC via a public key certificate.
A ticket granting ticket (TGT), returned by the KDC, enables a PK user
to obtain tickets and authenticate to kerberized services.  The PKDA
proposal goes a step further.  It supports direct client to server
authentication, eliminating the need for an online key distribution
center.  In this draft, we describe how, without any modification, the
PKINIT protocol may be applied to achieve the goals of PKDA. For direct
client to server authentication, the client will use PKINIT to
authenticate to the end server (instead of a central KDC), which then,
will issue a ticket for itself.  The benefit of this proposal, is that a
single PK extension to Kerberos can addresses the goals of PKINIT and
PKDA.


3. PKDA background

The PKDA proposal provides direct client to server authentication, thus
eliminating the need for an online key distribution center.  A client
and server take part in an initial PK based authentication exchange,
with an added caveat that the server acts as a Kerberos ticket granting
service and issues a traditional Kerberos ticket for itself.  In
subsequent communication, the client makes use of the Kerberos ticket,
thus eliminating the need for public key operations on the server.  This
approach has an advantage over SSL in that the server does not need to
save state (cache session keys).  Furthermore, an additional benefit, is
that Kerberos tickets can facilitate delegation (see Neuman[3]).

Below is a brief overview of the PKDA protocol.  For a more detailed
description see [1].

SCERT_REQ: Client α Server
The client requests a certificate from the server.  If the serverÆs
certificate is cached locally, SCERT_REQ and SCERT_REP are omitted.

SCERT_REP:  Server α Client
The server returns its certificate to the client.

PKTGS_REQ: Client α Server
The client sends a request for a service ticket to the server.  To
authenticate the request, the client signs, among other fields, a time
stamp and a newly generated symmetric key .  The time stamp is used to
foil replay attacks;  the symmetric key is used by the server to secure
the PKTGS_REP message.
The client provides a certificate in the request (the certificate
enables the server to verify the validity of the clientÆs signature) and
seals it along with the signed information using the serverÆs public
key.

PKTGS_REP:  Server α Client
The server returns a service ticket (which it issued for itself) along
with the session key for the ticket.  The session key is protected by
the client-generated key from the PKTGS_REQ message.

AP_REQ:  Client α Server
After the above exchange, the client can proceed in a normal fashion,
using the conventional Kerberos ticket in an AP_REQ message.


4. PKINIT background

One of the principal goals of PKINIT is to provide for interoperability
between a public key infrastructure and Kerberos.  Using a public key
certificate, a client can authenticate to the KDC and receive a TGT
which enables the client to obtain service tickets to kerberized
services..  In PKINIT, the AS-REQ and AS-REP messages remain the same;
new preauthentication data types are used to conduct the PK exchange.
Client and server certificates are exchanged via the preauthentication
data.  Thus, the exchange of certificates , PK authentication, and
delivery of a TGT can occur in two messages.

Below is a brief overview of the PKINIT protocol.  For a more detailed
description see [2].

PreAuthentication data of AS-REQ:  Client α Server
The client sends a list of trusted certifiers, a signed PK
authenticator, and its certificate.  The PK authenticator, based on the
Kerberos authenticator, contains the name of the KDC, a timestamp, and a
nonce.

PreAuthentication data of AS-REP:  Server ▀ Client
The server responds with its certificate and the key used for decrypting
the encrypted part of the AS-REQ.  This key is encrypted with the
clientÆs public key.

AP_REQ:  Client α Server
After the above exchange, the client can proceed in a normal fashion,
using the conventional Kerberos ticket in an AP_REQ message.


5. Application of PKINIT to achieve equivalence to PKDA

While PKINIT is normally used to retrieve a ticket granting ticket
(TGT), it may also be used to request an end service ticket.  When used
in this fashion, PKINIT is functionally equivalent to PKDA.  We
introduce the concept of a local ticket granting server (LTGS) to
illustrate how PKINIT may be used for issuing end service tickets based
on public key authentication.  It is important to note that the LTGS may
be built into an application server, or it may be a stand-alone server
used for issuing tickets within a well-defined realm, such as a single
machine.  We will discuss both of these options.


5.1. The LTGS

The LTGS processes the Kerberos AS-REQ and AS-REP messages with PKINIT
preauthentication data.  When a client submits an AS-REQ to the LTGS, it
specifies an application server, in order to receive an end service
ticket instead of a TGT.


5.1.1. The LTGS as a standalone server

The LTGS may run as a separate process that serves applications which
reside on the same machine. This serves to consolidate administrative
functions and provide an easier migration path for a heterogeneous
environment consisting of both public key and Kerberos.  The LTGS would
use one well-known port (port #88 - same as the KDC) for all message
traffic and would share a symmetric with each service.  After the client
receives a service ticket, it then contacts the application server
directly.  This approach is similar to the one suggested by Sirbu , et
al [1].


5.1.2. The LTGS as part of an application server

The LTGS may be combined with an application server.  This accomplishes
direct client to application server authentication; however, it requires
that applications be modified to process AS-REQ and AS-REP messages.
The LTGS would communicate over the port assigned to the application
server or over the well known Kerberos port for that particular
application.


6. Protocol differences between PKINIT and PKDA

Both PKINIT and PKDA will accomplish the same goal of issuing end
service tickets, based on initial public key authentication.  A PKINIT-
based implementation and a PKDA implementation would be functionally
equivalent.  The primary differences are that 1)PKDA requires the client
to create the symmetric key while PKINIT requires the server to create
the key and 2)PKINIT accomplishes in two messages what PKDA accomplishes
in four messages.


7. Discussion

The concept of Kerberos names (i.e. domain based names) is orthogonal to
the concept of public key names, in that X.500 distinguished names do
not reside within a particular realm.  The assumption is that all user
principals will use X.500 distinguished names and that PKINIT will
support both X.500 and Kerberos names for application servers.  However,
it is our recommendation that X.500 be the default naming convention.


8. Summary

The PKINIT protocol can be used, without modification to facilitate
client to server authentication without the use of a central KDC.  The
approach described in this draft  (and originally proposed in PKDA[1])
is essentially a public key authentication protocol that retains the
advantages of Kerberos tickets.

Given that PKINIT has progressed through the CAT working group of the
IETF, with plans for non-commercial distribution (via MITÆs v5 Kerberos)
as well as commercial support, it is worthwhile to provide PKDA
functionality, under the PKINIT umbrella.


9. Bibliography

[1] M. Sirbu, J. Chuang.  Distributed Authentication in Kerberos Using
Public Key Cryptography.  Symposium On Network and Distributed System
Security, 1997

[2] B.C. Neuman, B. Tung, J. Wray, . Trostle.  Public Key Cryptography
for Initial Authentication in Kerberos.  Internet Draft, October 1996.
(ftp://ietf.org/internet-drafts/draft-ietf-cat-kerberos-pk-init-02.txt)

[3] B.C. Neuman, Proxy-Based Authorization and Accounting for
Distributed Systems.  In Proceedings of the 13th International
Conference on Distributed Computing Systems, May 1993

[4] B.C. Neuman, Theodore Ts'o. Kerberos: An Authentication Service
for Computer Networks, IEEE Communications, 32(9):33-38.
September 1994.


Authors' Addresses

Ari Medvinsky <[e-mail]>
Matthew Hur   <[e-mail]>

CyberSafe Corporation
1605 NW Sammamish Raod
Suite 310
Issaquah, WA 98027-5378
Phone: [phone]
Fax:   [phone]
http:/www.cybersafe.com


B. Clifford Neuman

USC Information Sciences Institute
4676 Admiralty Way Suite 1001
Marina del Rey CA 90292-6695
Phone: [phone]
E-mail: [e-mail]