[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

Transport Layer Security Working Group                 S. Farrell
INTERNET-DRAFT                                                SSE
Expires Feb. 20, 1999.                            August 20, 1998


            TLS extensions for AttributeCertificate
                      based authorization

               <draft-ietf-tls-attr-cert-01.txt>

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),  ftp.ietf.org  (US
   East  Coast),  or ftp.isi.edu (US West Coast).

Abstract

   This document describes extensions to [TLS] providing
   authorization support based on the use of X.509
   AttributeCertificates.

1.   Introduction

   TLS provides authentication, data integrity and
   confidentiality services for Internet protocols. In many
   applications these services are not sufficient to provide
   the type of authorization services required.

   For example, it may be that access to a resource should
   be controlled on the basis of the client's clearance or
   role.

   An additional requirement is support for delegation,
   where a intermediate TLS server acts as a client but
   where the final target TLS server must make its access
   decision on the basis of the initial client's rights.

Farrell, S.                Expires Feb. 20,      1999   [Page  1]

INTERNET-DRAFT                AC PROF              August 20 1998

   While TLS doesn't provide support for these features,
   AttributeCertificates (ACs) in conjunction with TLS do
   provide a solution. [AC509] defines a profile of the
   X.509 AttributeCertificate which can be used in this
   context.

   In the remainder of this document we describe the
   operational models, then the new messages and data
   structures and finally describe a method for embedding AC
   exchange into the TLS handshake.

2.   Operational Models

   In some environments it is suitable for the client to
   "push" an AC to a server. This means that no new
   connections between the client and server domains are
   required. It also means that no search burden is imposed
   on servers, which improves performance.

   In other cases it is more suitable for the client simply
   to authenticate to the server and for the server to
   request ("pull") the client's AC from the AC issuer or a
   repository. A major benefit of the "pull" model is that
   it can be implemented without changes to the client. It
   is also more suitable for some extranet cases, where the
   client's rights should be assigned within the server's
   domain.

   There are a number of possible exchanges which can occur
   and three entities involved (client, server and AC
   issuer). In addition the use of a directory service as a
   repository for AC retrieval may be supported.

Farrell, S.                Expires Feb. 20,      1999   [Page  2]

INTERNET-DRAFT                AC PROF              August 20 1998

   The diagram below shows the exchanges defined which are
   described in later sections.

   +--------------+                        +---------------+
   |              |                        |               |
   | AC Issuer    +----+                   | Directory     |
   |              |    |                   |               |
   +--+-----------+    | Server            +-------+-------+
      |                | Acquisition               |
      |Client          |                           |Server
      |Acquisition     +----------------------+    |Lookup
      |                                       |    |
   +--+-----------+                        +--+----+-------+
   |              |       AC "push"        |               |
   | Client       +------------------------+ Server        |
   |              | (part of TLS h/shake)  |               |
   +--------------+                        +---------------+
      |
      | Client Lookup
   +--+-----------+
   |              |
   | Directory    |            Figure 1: AC Exchanges
   |              |
   +--------------+


   Of the above exchanges, the most important to embed in
   the TLS protocol is that between client and server. AC
   acquisition (from an issuer or directory) is handled as a
   higher layer protocol (a payload protocol from the TLS
   perspective).

   An AC carrier structure (acinfo) is defined which allows
   for requests for ACs, responses to same and for pushing
   ACs plus external controls in a standard manner. This
   structure is used in all messages.

Farrell, S.                Expires Feb. 20,      1999   [Page  3]

INTERNET-DRAFT                AC PROF              August 20 1998

3.   Data Structures

   acinfo is the data structure which is used to "push" or
   "pull" an AC and/or associated control information.
   acinfo may also be used when requesting an AC from an
   issuer.

   A set of public key certificates may also be "pushed"
   with an acinfo in order to assist the recipient in
   certificate handling.

        ACInfo ::= SEQUENCE {
             type      INTEGER {
                            clientAcquire       (0),
                            clientAcquireResp   (1),
                            serverAcquire       (2),
                            serverAcquireResp   (3),
                            acRequest           (4),
                            acResponse          (5)
                       },
             peer      [0] GeneralName     OPTIONAL,
             template  [1] SEQUENCE OF Attribute OPTIONAL,
                  -- only one occurrence of each attr type
             ac        [2] AttributeCertificate OPTIONAL,
             pps       [3] PairingProofs   OPTIONAL,
             certs     [4] Certificates    OPTIONAL
        }

   When an intermediate server (IS) delegates an AC to a
   target server (TS) then the target (TS) must be able to
   verify that the intermediate (IS) hasn't "stolen" the AC.
   This is achieved by having the IS produce the following
   signed ASN.1 structure:

        PairingProof ::= SIGNED SEQUENCE {
             init      GeneralName,
             target    GeneralName,
             issuer    GeneralName,
             serial    INTEGER,
             time      GeneralizedTime,
             nonce     BIT STRING,
             sigalg    AlgorithmIdentifier
        }

   If traced delegation is required (ensuring that no entity
   in the chain stole the AC) then a sequence of pairing
   proofs must be sent (with the current one left most):

        PairingProofs ::= SEQUENCE OF PairingProof

Farrell, S.                Expires Feb. 20,      1999   [Page  4]

INTERNET-DRAFT                AC PROF              August 20 1998

   So long as TS can verify this data then it can check (via
   whatever targeting is included in the AC) that IS hasn't
   stolen the AC.

   <<note: a scheme which didn't require the client to sign
   would be better (assuming all servers have signature keys
   is reasonable). We would still need to provide a trace of
   delegation starting with the client somehow.>>

   <<additional checks to be defined, e.g. initiator from
   current pair must be target from next pair. times
   shouldn't be out of whack by too much, etc.>>

4.   AC Acquisition

4.1  Client Acquisition

   This exchange occurs when a client requires a new AC from
   an issuer. The AC issuer MUST ensure that the client is
   authenticated, most simply via TLS with client
   authentication. This exchange may occur at network login
   time or may happen automatically during (or before) the
   client handshake with a TLS server (e.g. upon receipt of
   the ACRequest message from the server - see section 8
   below).

   <<a full handshake between client and issuer may to too
   much overhead (e.g. if 10,000 clients arrive at 9am). A
   simple CMS over UDP wrapping of the acinfo would be more
   efficient and may be added later>>

   The client sends the following message to the server (the
   syntax used is described in [TLS]):

        struct {
             opaque acinfo<1..2^24-1>
        } ClientACRequest

   acinfo field contents are specified below.

   Field        Description
   =====        ===========
   type         clientAcquireResp
   peer         server name or missing
   template     attributes which the client wishes to be
                present in the AC
   ac           missing
   pps          missing
   certs        missing

Farrell, S.                Expires Feb. 20,      1999   [Page  5]

INTERNET-DRAFT                AC PROF              August 20 1998

   The server responds with:

        struct {
             enum {
                  success(0),
                  success_with_changes(1),
                  failure(2),
                  denied(3),
                  (255)
             } acstatus;
             opaque acinfo<1..2^24-1>
        } ClientACResponse

   acinfo field contents are specified below.

   Field        Description
   =====        ===========
   type         clientAcquireResp
   peer         missing
   template     missing
   ac           the AC or missing
   pps          missing
   certs        missing

4.2  Server Acquisition

   Server acquisition occurs where a client has established
   a TLS connection to the server, but hasn't provided (or
   can't provide) an AC. The case where the client provides
   a PairingProof is also supported.

   Note that the server may keep a TLS session open (or
   resume a session) with the issuer for multiple exchanges.
   AC issuers MUST support this feature, servers MAY make
   use of this feature.

Farrell, S.                Expires Feb. 20,      1999   [Page  6]

INTERNET-DRAFT                AC PROF              August 20 1998

   The server sends the following message to the issuer:

   struct {
        opaque acinfo<1..s^24-1>
   } ServerACRequest

   Field        Description
   =====        ===========
   type         serverAcquire
   peer         missing if pps supplied
                mandatory containing client name if pps
                missing
   template     missing
   ac           missing
   pps          missing if peer supplied
                mandatory if peer missing
   certs        may be present if pps supplied

   The issuer responds with:

        struct {
             enum {
                  success(0),
                  success_with_changes(1),
                  failure(2),
                  denied(3),
                  (255)
             } acstatus;
             opaque acinfo<1..2^24-1>
        } ServerACResponse

   The fields here are as described for the ClientACResponse
   except that the type is serverAcquireResp.

4.3  Client and Server Lookup

   ACs are retrieved via LDAP. The LDAP connection MAY be
   secured with TLS according to local policy.

   Given a GeneralName for the peer a client or server will
   perform the following lookup.

   <<derivation of an entry name from the peer GeneralName
   is tbs - and probably very hard!>>

Farrell, S.                Expires Feb. 20,      1999   [Page  7]

INTERNET-DRAFT                AC PROF              August 20 1998

   Once the directory entry has been identified then the
   value(s) of the attributeCertificateAttribute should be
   retrieved. This is defined in [X.509] as:

   attributeCertificateAttribute ATTRIBUTE  ::= {
        WITH SYNTAX              AttributeCertificate
        EQUALITY MATCHING-RULE   certificateExactMatch
        ID                       id-at-attributeCertificate
   }

   id-at-attributeCertificate ::= OBJECT IDENTIFIER
                                      { 2 5 4 58 }

   The selection of which of the values of the attribute are
   to be read is out of scope of this specfication.

5.   TLS Protocol Extensions

   The basic requirement is to be able to include an acinfo
   structure into TLS handshakes.

5.1  Session Management

   The TLS session state (section 7, p22) now requires a new
   item:

        authorization information
             An acinfo structure containing the
             authorization information for the session. This
             element of the state may be null.

5.2  Use of TLS Alerts

   No new TLS alerts are required.

5.3  Handshake Protocol Extensions

   The basic approach is to handle the acinfo structure in
   the same way as X.509 public key certificates are
   handled. This means that we define an ACRequest which the
   server can send to the client and an ACInfo with which
   the client can respond. These are analogous to the
   existing CertificateRequest and CertificateResponse
   messages. The extension to the interworking diagram from
   TLS (section 7.3) is shown on the next page.

Farrell, S.                Expires Feb. 20,      1999   [Page  8]

INTERNET-DRAFT                AC PROF              August 20 1998

   Client                                             Server
   ClientHello            ----->
                                                 ServerHello
                                                Certificate*
                                          ServerKeyExchange*
                                         CertificateRequest*
                                                  ACRequest*
                          <-----             ServerHelloDone
   Certificate*
   ACInfo*
   ClientKeyExchange
   CertificateVerify*
   [ChangeCipherSpec]
   Finished               ----->
                                          [ChangeCipherSpec]
                                                    Finished
   ApplicationData        <---->             ApplicationData

   <<note: the new messages could be avoided if the
   Certificate and CertificateRequest messages were
   extended, however, the syntax and handling of the
   ACRequest and ACInfo seem sufficiently different to
   warrant new messages.>>

   It is to be expected that a typical scenario would be
   where a client establishes a session with a server
   without authorization support. At some point the client
   requests access to a resource which can only be granted
   if a client AC is verified. At this point the server may
   cause a renegotiation using a HelloRequest message.

   This is similar to cases where a client first establishes
   anonymously and is then forced into mutual
   authentication.

   The following sections define the new messages in more
   detail.

5.3.1     ACRequest message

   When this message will be sent:
        A server can optionally request an AC from the
        client. This message, if sent, will immediately
        follow the CertificateRequest (if it is sent).

   Structure of this message:
        struct {
             opaque acinfo<1..2^24-1>
        } ACRequest

Farrell, S.                Expires Feb. 20,      1999   [Page  9]


INTERNET-DRAFT                AC PROF              August 20 1998

   Field        Description
   =====        ===========
   type         acRequest
   peer         missing
   template     a hint to show the client which attributes
                are required
   ac           missing
   pps          missing
   certs        missing

   The client MAY ignore the template field if present.

5.3.2     ACInfo message

   When this message will be sent:
        This message must be sent if the client has received
        an ACRequest message from the server. If sent, it
        will immediately follow the Certificate message sent
        by the client (if sent).

   Structure of this message:
        struct {
             opaque acinfo<1..2^24-1>
        } ACInfo

   Field        Description
   =====        ===========
   type         acResponse
   peer         missing
   template     missing
   ac           the AC ; may be missing if a pps is present
   pps          optionally present
   certs        optionally present

   If the ac is missing but the pps is present then the
   server may attempt to acquire or lookup the AC on the
   basis of validation of the pps signature. Note however
   that the pps signature does not authenticate the client
   to the server as it is not necessarily tied to the TLS
   session.

   Upon receipt of this message the server can now validate
   the AC. However the server may have to wait until after
   the Finished message in order to trust the AC (i.e. when
   the client is authenticated).

Farrell, S.                Expires Feb. 20,      1999   [Page 10]


INTERNET-DRAFT                AC PROF              August 20 1998

6.   Conformance

   Both clients and servers MUST support the AC "push" and
   the relevant acquisition exchanges. Client and servers
   MAY support the lookup exchanges.

   A signing algorithm is required for the PairingProof
   structure, dsaWithSHA1 MUST be supported. Other signature
   algorithms specified in [CMS] MAY be supported.

7.  Security Considerations

   A server which accepts an AC from an unauthenticated
   client may be using a stolen AC. For this reason it is
   strongly recommended that servers only accept ACs from
   authenticated clients.

   A server which is presented with an AC which is
   delegatable will be able to masquerade as the AC owner to
   any of the other servers to which the AC can be
   delegated. This means that the client is effectively
   trusting the server to the extent that the AC is
   delegatable by that server. For this reason it is
   recommended to limit the delegation scope of ACs to the
   minimum required.

8.  References

   [AC509]    Farrell, S,"An Internet AttributeCertificate
              Profile for Authorization",
              draft-ietf-tls-ac509prof-00.txt, August 1998.
   [CMS]      Housley, R., "Cryptographic Message Syntax",
              draft-ietf-smime-cms-05.txt, May 1998.
   [TLS]      Dierks, T., Allen C., "The TLS Protocol
              Version 1.0", draft-ietf-tls-protocol-05.txt,
              November 1997.
   [X.509]    ITU-T Recommendation X.509 (1997 E):
              Information Technology - Open Systems
              Interconnection - The Directory:
              Authentication Framework, June 1997.

Author's Address

   Stephen Farrell,
   SSE Ltd.
   Fitzwilliam Court,
   Leeson Close,
   Dublin 2,
   IRELAND

   tel: +353-1-676-9089
   email: stephen.farrell@sse.ie

Farrell, S.                Expires Feb. 20,      1999   [Page 11]


Html markup produced by rfcmarkup 1.123, available from https://tools.ietf.org/tools/rfcmarkup/