Internet Draft                                               K. Jackson
Document: draft-ietf-tls-delegation-01.txt                         LBNL
                                                              S. Tuecke
                                                              D. Engert
                                                                    ANL
Expires: July 2001                                        Feburary 2002

                        TLS Delegation Protocol

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 specifies a delegation protocol for use with the
   Transport Layer Security (TLS) protocol.  When the TLS session is
   using X.509 certificates for authentication, then the delegation is
   of an X.509 Proxy Certificate, as defined in draft-ggf-x509-proxy.
   When the TSL session is using Kerberos 5 for authentication, then
   the delegation is of a Kerberos 5 forwardable ticket, as defined in
   RFC 1510.

Jackson, et. al.        Expires February 2002                       1
Internet Draft         TLS Delegation Protocol              July 2001



Table of Contents

   TLS Delegation Protocol............................................1
   Status of this Memo................................................1
   Abstract...........................................................1
   Table of Contents..................................................2
   1.   Introduction.................................................3
   2.   Assumed Session Properties...................................3
   3.   TLS Record Layer.............................................3
   4.   Delegation Protocol..........................................4
   4.1.   Delegation Protocol Overview................................4
   4.2.   Delegation Protocol Messages................................5
   4.3.   Delegation Init.............................................5
   4.4.   Delegation Begin............................................6
   4.5.   Credential Request..........................................6
   4.6.   Delegation Complete.........................................7
   4.7.   Delegation Error............................................7
   4.7.1.  No Delegation.............................................8
   4.7.2.  Unsupported Credential Type...............................8
   4.7.3.  Unsupported Version.......................................8
   4.7.4.  Delegation Denied.........................................8
   4.7.5.  Invalid Session...........................................9
   5.   Security Considerations......................................9
   6.   References...................................................9
   7.   Acknowledgments..............................................9
   8.   Contact Information..........................................9


Jackson, et. al.        Expires Feburary 2002                       2
Internet Draft         TLS Delegation Protocol              July 2001


1.      Introduction

   The TLS protocol, as defined in RFC 2246 [2], provides for
   authentication and data protection for communication between two
   entities.  However, missing from the protocol is a way to perform
   delegation of a credential.

   This document defines extensions to the TLS protocol to allow it to
   perform delegation of a Proxy credential.  When X.509 public key
   certificates are used, this delegation protocol will delegate a
   Proxy Certificate, as defined by draft-ggf-x509-proxy [5].  When
   Kerberos 5 is used, this delegation protocol will delegate a
   Kerberos 5 forwardable ticket, as defined by RFC 1510 [3].

   The motivation for proxies is discussed at length in draft-ggf-x509-
   proxy, and therefore will not be discussed here.

   Section 2 contains the assumptions this protocol makes about the
   underlying session established by TLS.  Section 3 contains
   information about the necessary additions to the TLS Record Layer.
   Section 4 contains a description of the proposed delegation
   protocol.

   Section 5 discusses security considerations relating to this TLS
   Delegation Protocol.  Section 6 contains the references.  Section 7
   contains acknowledgements.  Section 8 contains contact information
   for the authors.

   This document deals with the formatting of data in an external
   representation.  The presentation language defined in RFC 2246 [2]
   will be used.

   This document was written under the auspices of the Global Grid
   Forum Security Working Group.  For more information on this and
   other related work, see http://www.gridforum.org/security.

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

2.      Assumed Session Properties

   This protocol relies on several properties of the underlying TLS
   session.  In particular the protocol assumes that the communications
   channel is integrity checked, protects against man-in-the-middle
   attacks, and prevents replay attacks.  In the case of PKI based
   delegation, the delegatee must have authenticated itself to the
   delegator.  It is a fatal protocol error to attempt to initiate the
   delegation protocol in a session that does not meet these minimum
   requirements.

3.      TLS Record Layer


Jackson, et. al.        Expires Feburary 2002                       3
Internet Draft         TLS Delegation Protocol              July 2001

   The TLS Protocol is a layered protocol.  The TLS Record Protocol is
   the lowest layer.  It provides the low-level message fragmentation,
   encryption/decryption, etc.  Layered on top of this protocol are
   four record protocol clients: the handshake protocol, the alert
   protocol, the change cipher spec protocol, and the application data
   protocol.  The delegation protocol is a fifth record protocol
   client.  To support this the ContentType definition from section A.1
   of RFC 2246 becomes:

   enum { change_cipher_spec(20), alert(21),
          handshake(22), application_data(23),
          delegation(24), (255)
   } ContentType;

4.      Delegation Protocol

   The TLS Delegation Protocol is a higher-level client of the TLS
   Record Protocol.  This protocol is used to allow the initiator to
   delegate the ability to act on its behalf to the acceptor in the
   event that the acceptor must make a request to a third party on
   behalf of the initiator.  In the case of X.509 certificate based
   delegation, the delegated credential will be a Proxy Certificate as
   defined by draft-ggf-x509-proxy.  In the case of Kerberos 5 based
   delegation, the delegated credential will be a Kerberos 5
   forwardable ticket.  Delegation request messages are supplied to the
   TLS Record Layer, where they are encapsulated within one or more
   TLSCiphertext structures, which are processed and transmitted as
   specified by the current active session state.

4.1. Delegation Protocol Overview

   The TLS Delegation Protocol involves the following steps:

   *  Exchange delegation initiation messages and negotiate the
      credential type.

   *  Create the delegated credential.

   Either the initiator or the acceptor may initiate the protocol.  The
   acceptor optionally sends a DelegationInit message if it is
   initiating the protocol.  The initiator sends a DelegationBegin
   message in response, or this message may be sent to initiate the
   protocol.  The acceptor will now create an algorithm specific
   delegation request.  It then sends a CredentialRequest message to
   the initiator containing the request.  The initiator returns the
   resulting delegation credential to the acceptor in a
   DelegationComplete message.  At this point, the delegation protocol
   is complete and the acceptor is in possession of a delegated
   credential.  (See flow chart below.)

   Initiator                                     Acceptor
   ---------                                     --------
                                 <-------        DelegationInit *
   DelegationBegin               ------->

Jackson, et. al.        Expires Feburary 2002                       4
Internet Draft         TLS Delegation Protocol              July 2001

                                 <-------        CredentialRequest
   DelegationComplete            ------->

   * Indicates optional or situation-dependent messages that are not
   always sent.

4.2.    Delegation Protocol Messages

   enum {
      delegation_init(8), delegation_begin(16),
      delegation_request(24), delegation_complete(32),
      delegation_error(40), (255)
   } DelegationType;

   struct {
      DelegationType msg_type;   /* delegation type */
      uint24 length;             /* bytes in message */
      select (DelegationType) {
         case delegation_init:         DelegationInit;
         case delegation_begin:        DelegationBegin;
         case credential_request:      CredentialRequest;
         case delegation_complete:     DelegationComplete;
         case delegation_error:        DelegationError;
      } body;
   } Delegation;

4.3.    Delegation Init

   When this message will be sent:
      The acceptor may send the delegation request message at any time.

   Meaning of this message:
      Delegation init is a notification to the initiator that the
      acceptor would like the initiator to initiate the delegation
      protocol.  The initiator may ignore the message if it is
      unwilling to perform delegation at this time, or it may respond
      with a no delegation error message if unwilling to perform
      delegation.  This message will contain the type of requested
      delegation credential.  This allows for the ability to delegate a
      credential of a different type than was authenticated with.  This
      may be useful if crossing authentication boundaries.

   After sending the delegation init message, acceptors should not
   repeat the request until the delegation protocol is complete.

   Structure of this message:
      enum {
         PKI(8), Kerberos(9),
         (255)
      } CredentialType;

      struct {
         opaque policy_list<0..??>  [Not sure on the total size here]
      } PolicyList;

Jackson, et. al.        Expires Feburary 2002                       5
Internet Draft         TLS Delegation Protocol              July 2001


      struct {
         CredentialType requested_type;
         PolicyList policy_list;
      } DelegationInit;

   requested_type
      The type of delegation credential the acceptor is requesting.
      Currently supported types are PKI and Kerberos.

   policy_list
      An opaque structure that may contain policy information to be
      used by the initiator.


4.4.    Delegation Begin

   When this message will be sent:
      The initiator may send this message at any time to initiate the
      protocol, or it will send this message in response to a
      delegation begin message.

   Structure of this message:
      struct {
         uint8 major, minor;
      } ProtocolVersion;

      struct {
         opaque policy_list<0..??>  [Not sure on the total size here]
      } PolicyList;

      struct {
         ProtocolVersion initiator_version;
         CredentialType type;
         PolicyList policy_list;
      } DelegationBegin;

   initiator_version
      The version of the delegation protocol the initiator wishes to
      use.   This should be the latest (highest valued) version
      supported by the initiator.

   type
      The type of delegation credential the initiator is willing to
      delegate.  Currently supported types are PKI and Kerberos 5.

   policy_list
      An opaque structure that may contain policy information to be
      used by the acceptor when creating the credential request.

4.5.    Credential Request

   When this message will be sent:

Jackson, et. al.        Expires Feburary 2002                       6
Internet Draft         TLS Delegation Protocol              July 2001

      The acceptor will send this message in response to the delegation
      begin message.

   Structure of this message:

      struct {
         ProtocolVersion acceptor_version;
         PolicyList policy_list;
         select (CredentialType) {
            case PKI:
               opaque CertReqMessage<1..?>;[Not sure of size]
            case Kerberos:
               opaque [Not sure what should go here, Doug?]
         };
      } CredentialRequest;

   acceptor_version
      The version of the delegation protocol the acceptor is using.
      This should be the latest (highest valued) version supported by
      both the initiator and acceptor.

   policy_list
      An opaque structure that may contain policy information to be
      used by the acceptor when creating the credential request.

   CertReqMessage
      A certificate request message as defined in draft-ietf-pkix-
      rfc2511bis-00.txt [4].

4.6.    Delegation Complete

   When this message will be sent:
      The initiator will send this message in response to the
      credential request message.

   Structure of this message:
      struct {
         select (CredentialType) {
            case PKI:
               opaque ASN.1Cert<0..2^24-1>;
            case Kerberos:
               opaque [I don't know what would go here, Doug?]
         };
      } DelegationComplete;

   ASN.1Cert
      An X.509 Proxy Certificate.

4.7.    Delegation Error

   enum {
      no_delegation(8), unsupported_credential_type(16),
      unsupported_version(24), invalid_session(32), (255)
   } DelegationErrorType;

Jackson, et. al.        Expires Feburary 2002                       7
Internet Draft         TLS Delegation Protocol              July 2001


   struct {
      DelegationErroryType msg_type;
      select (DelegationErrorType) {
         case no_delegation:               NoDelegation;
         case unsupported_credential_type  UnsupportedCredential;
         case unsupported_version          UnsupportedVersion;
         case delegation_denied            DelegationDenied;
         case invalid_session              InvalidSession;
      };
   } DelegationError;

4.7.1.  No Delegation

   When this message will be sent:
      The initiator, in response to a delegation init message, may send
      this if unwilling to delegate to this acceptor.

   Structure of this message:
      struct { } NoDelegation;

4.7.2.  Unsupported Credential Type

   When this message will be sent:
      The initiator, in response to a delegation init message, may send
      this if it does not support the credential type the acceptor
      requested.  The acceptor, in response to a delegation begin
      message, may send this if it does not support the credential type
      the initiator is willing to delegate.

   Structure of this message:
      struct { } UnsupportedCredential;

4.7.3.  Unsupported Version

   When this message will be sent:
      The acceptor, in response to a delegation begin message, may send
      this message if it is unable to support the protocol version the
      initiator requested.  The initiator, in response to a delegation
      request message, may send this if unable to support the protocol
      version the acceptor requested.

   Structure of this message:
      struct {} UnsupportedVersion;

4.7.4.  Delegation Denied

   When this message will be sent:
      The initiator, in response to a credential request message, may
      send this if it is unwilling to generate the requested
      credential.

   Structure of this message:
      struct { } DelegationDenied;

Jackson, et. al.        Expires Feburary 2002                       8
Internet Draft         TLS Delegation Protocol              July 2001


4.7.5.  Invalid Session

   When this message will be sent:
      Either the initiator or acceptor must send this message if it
      receives a delegation message while the current session does not
      support the minimum requirements of the protocol.

   Structure of this message:
      struct { } InvalidSession;

5.      Security Considerations

   Security issues are discussed throughout this memo.

6.      References

   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels," BCP 14, RFC 2119, March 1997.

   [2]  Dierks, T. and C. Allen, "The TLS Protocol, Version 1.0," RFC
        2246, January 1999.

   [3]  Kohl, J. and C. Neuman, "The Kerberos Network Authentication
        Service (V5)," RFC 1510, September 1993.

   [4]  Myers, M., C. Adams, D. Solo, and D. Kemp, "Certificate Request
        Message Format (CRMF)," Internet Draft draft-ietf-pkix-
        rfc2511bis-00.txt, November 2000.

   [5]  Tuecke, S., D. Engert, and M. Thompson, "Internet X.509 Public
        Key Infrastructure Proxy Certificate Profile," Internet Draft
        draft-ggf-x509-Proxy-05.txt, February 2001.

7.      Acknowledgments

   We are grateful to numerous colleagues for discussions on the topics
   covered in this paper, in particular (in alphabetical order, with
   apologies to anybody we've missed): Joe Bester, Randy Butler,
   Olivier Chevassut, William Johnston, Carl Kessleman, Ian Foster,
   Marty Humphrey, Clifford Neuman, Mary Thompson, Gene Tsudik, and Von
   Welch.

   This work was supported in part by the Mathematical, Information,
   and Computational Sciences Division subprogram of the Office of
   Advanced Scientific Computing Research, U.S. Department of Energy,
   under Contract W-31-109-Eng-38 and under Contract DE-AC03-76SF00098
   with the University of California; by the Defense Advanced Research
   Projects Agency under contract N66001-96-C-8523; by the National
   Science Foundation; and by the NASA Information Power Grid project.

8.      Contact Information


Jackson, et. al.        Expires Feburary 2002                       9
Internet Draft         TLS Delegation Protocol              July 2001

   Keith R. Jackson
   Lawrence Berkeley National Laboratory
   Berkeley, CA 94702
   Phone: 510-486-4401
   Email: KRJackson@lbl.gov

   Steven Tuecke
   Distributed Systems Laboratory
   Mathematics and Computer Science Division
   Argonne National Laboratory
   Argonne, IL 60439
   Email: tuecke@mcs.anl.gov

   Doug Engert
   Argonne National Laboratory
   Argonne, IL 60439
   Email: deengert@anl.gov


Jackson, et. al.        Expires Feburary 2002                      10