One document matched: draft-ietf-cat-kerberos-anoncred-00.txt

INTERNET-DRAFT                                           Ari Medvinsky
draft-ietf-cat-kerberos-anoncred-00.txt                   Jon Cargille
                                                              Matt Hur
                                                         
expires March 1998                               CyberSafe Corporation      


    Anonymous Credentials in Kerberos


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 ds.internic.net (US East Coast),
    nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or
    munnari.oz.au (Pacific Rim).

    The distribution of this memo is unlimited.  It is filed as
    draft-ietf-cat-kerberos-anoncred-01.txt, and expires December 31,
    1997.  Please send comments to the authors.


1.  Abstract

    This document defines the concept of anonymous Kerberos
    credentials, and describes how such credentials can be securely
    obtained from a Kerberos KDC via the PKINIT extension.  This draft
    defines no new mechanisms or protocols; instead, it defines the
    concepts and proposes usage and naming conventions.


2.  Introduction

    In the Kerberos system[1], the establishment of a secure
    client-server channel requires both parties to be registered with
    an authentication service (e.g., a Kerberos realm or a
    certification service ala PKINIT[2]).  In an environment where
    users are transitory (e.g. a public terminal room or an anonymous
    ftp site), advance user registration may not be a viable option,
    yet protection against passive and active attacks is still needed.

    Similarly to SSH and SSL, Kerberos should facilitate a way to
    establish an encrypted channel between a server and an anonymous
    user; this can be accomplished using anonymous credentials, as
    described in Section 3.  Additionally, the approach presented in
    this draft enables users who are registered in a Kerberos realm to
    establish secure, anonymous sessions (e.g., for anonymous
    e-payment transactions[3]).


3. Framework for Anonymous Credentials

    An anonymous ticket is identical to a regular Kerberos ticket
    defined in RFC 1510.  The only difference is that the client
    principal name, specified in the ticket, is not assigned to any
    user in a Kerberos realm, nor is there an entry for that name in
    the Kerberos database.  The particular anonymous name will be
    configurable on a per-realm basis (e.g., anonymous@ISI.EDU or
    nobody@ISI.EDU for the ISI.EDU realm).

    An anonymous ticket can be a ticket granting ticket (TGT) or an
    end service ticket.  A user, in possession of an anonymous ticket
    and the corresponding session key, can establish an encrypted
    channel (resilient to passive and active attacks) with the server
    specified in the ticket.

    We propose two methods for obtaining an anonymous ticket from the
    KDC:

    1) In the first method, the user does not share a secret with a
       KDC or posses a public key certificate.  The challenge, is to
       securely deliver to the client the session key associated with
       the ticket.  Without any modifications, we can utilize the
       PKINIT extension to Kerberos to achieve this goal.  PKINIT
       employs public key cryptography to obtain a standard ticket
       granting ticket.  In PKINIT the AS-REQ and AS-REP remain the
       same (per RFC 1510); all PK operations take place in the
       pre-authentication structure (see [2] for details).  PKINIT
       section 3.2 employs Diffie-Hellman to establish a shared secret
       which is then used to protect the session key returned in the
       AS-REQ.  In this option, both the client and the KDC
       authenticate their respective DH public values by signing with
       a private key.
        
       To obtain anonymous credentials, we propose that the user
       performs a NULL signature over the DH public value.  This is
       basically a no-op operation which is legal according to the
       PKINIT specification. The client also sets a new flag,
       ANONYMOUS_REQUEST in the kdc-options field of KRB_KDC_REQ (see
       5.4.1 of [4]).
               
       Upon receiving the request, the KDC creates an anonymous
       ticket (for the TGT service or for an end service, depending on
       server principal name requested) and returns in the AS-REP with
       the corresponding preauth data type ( PA-PK-AS-REP).  If it was
       an anonymous TGT, then a client may use it to obtain an
       anonymous end service ticket using a standard TGT-REQ.

    2) The second method enables users already registered in a
       Kerberos realm to obtain anonymous credentials.  A client
       simply makes a standard AS-REQ or TGS-REQ with the
       ANONYMOUS_REQUEST flag set.  The KDC returns an anonymous
       ticket.  Thus, users that wish to remain anonymous to an
       application service can setup a secure channel without
       incurring the cost of PK operations (see case 1).  It is
       important to note that, in the second method, the Kerberos
       server is trusted to not record and later reveal the principal
       name of the client that obtained the anonymous ticket.


4.  Discussion

    We solicit discussion on the implications of the following aspects
    of the proposal:

    ANONYMOUS_REQUEST flag: The use of the ANONYMOUS_REQUEST flag raises
    issues regarding its propagation.  The flag is set by the client
    in the AS-REQ or a TGS-REQ.  Should it be propagated to tickets,
    and if so, under what conditions?

    Services generally should not need to know that clients are
    anonymous. Authentication and authorization are completely
    distinct operations.  The fact that a user is anonymous rather
    than well-known should not be important to services, since they
    should not be basing authorization decisions merely on the fact
    that the client has a service ticket; any server that does so is
    arguably broken.  Thus propagation of the ANONYMOUS_TICKET flag
    into service tickets need not be mandatory, and servers may be
    unaware of a user's anonymity.

    However, there are cases where a service may need to know whether
    a client principal is anonymous or well-known.  For example,
    consider a service that allows all users access but wishes to
    maintain an audit log of all actions performed and on whose behalf
    they are performed.  Such a service might want to deny service to
    anonymous users, not because they are not authorized, but because
    they are not auditable.  The need for such detection is an
    argument for mandatory propagation of the flag into all service
    tickets.

    We solicit discussion on whether ANONYMOUS_TICKET-flag propagation
    behavior should be mandated, or whether it should be configurable
    on a per-realm basis.
 

5.  Bibliography

    [1] J. Kohl, C. Neuman.  The Kerberos Network Authentication
    Service (V5).  Request for Comments: 1510

    [2] B. Tung, C. Neuman, J. Wray, A. Medvinsky, M. Hur, J. Trostle.
    Public Key Cryptography for Initial Authentication in Kerberos
    draft-ietf-cat-kerberos-pkinit-03.txt

    [3] Ari Gennady Medvinsky.  NetCash: A Framework for Electronic
    Currency.  Ph.D. dissertation, University of Southern California,
    May 1997.

    [4] C. Neuman, J. Kohl, T. Ts'o.  The Kerberos Network 
    Authentication Service (V5).  
    draft-ietf-cat-kerberos-revisions-00.txt


6.  Acknowledgements

    Some of the ideas contained in this proposal are based on
    suggestions by Clifford Neuman, offered in the course of developing
    the ideas for NetCash[3].


7.  Authors

    Ari Medvinsky
    Matt Hur
    Jon Cargille
    CyberSafe Corporation
    1605 NW Sammamish Road Suite 310
    Issaquah WA 98027-5378
    Phone: +1 425 391 6000
    E-mail: {jonathan.cargille, matt.hur, ari.medvinsky}@cybersafe.com