[Search] [txt|pdf|bibtex] [Tracker] [WG] [Email] [Nits]

Versions: 00 01                                                         
Internet-Draft                                       ERIC BAIZE, BULL
IETF Common Authentication Technology WG         STEPHEN FARRELL, SSE
                                                      TOM PARKER, ICL
<draft-ietf-cat-sesamemech-00.txt>                  November 21, 1995

                    The SESAME GSS-API Mechanism

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

Comments on this document should be sent to "cat-ietf@mit.edu", the
IETF Common Authentication Technology WG discussion list.


ABSTRACT

   This specification defines protocols, data elements, and
   conventions to be employed by peers implementing the Generic
   Security Service Application Program Interface (as specified in
   RFCs 1508 and 1509) when using the SESAME Mechanism.

1.  BACKGROUND

   In most systems of today, protection of resources in a
   distributed computing environment is principally achieved by
   direct login to each end-system accessed, using passwords
   transmitted in clear and unprotected. This has a number of
   drawbacks: firstly it is not very secure; secondly it is not
   convenient to have to remember several passwords, and thirdly the
   user is not known as one single user to the distributed system as
   a whole - there is no co-ordination of his use of the distributed
   system across the different servers of the system.

   To find solutions to these and related problems, work has been
   underway for a number of years in Europe, under the aegis of
   ECMA, to develop security standards for open systems. The SESAME

Baize, Farrell, Parker     Document Expiration: 21 May 1996     [Page 1]


internet-draft                                       November 21, 1995

   project, initiated in the wake of the ECMA work by the Commission
   of the European Communities (CEC), has implemented a profile of
   the ECMA standards.

   This draft specifies the use of the security protocols
   implemented in the SESAME project in a GSS-API [GSSAPI]
   environment. A more complete overview of SESAME is available in
   [SESOV].

1.1 Table of Contents

1. BACKGROUND                                                       1
1.1 TABLE OF CONTENTS                                               2
1.2 ACKNOWLEDGEMENTS                                                3
2. THE SESAME TECHNOLOGY                                            3
2.1 OVERVIEW                                                        3
2.2 SESAME CONCEPTS                                                 4
2.2.1 SESAME ACCESS CONTROL CONCEPTS                                4
2.2.2 TARGET ACCESS ENFORCEMENT FUNCTION                            7
2.2.3 SESAME KEY DISTRIBUTION                                       8
2.2.4 USE OF CRYPTOGRAPHY IN SESAME                                10
3. GSS-API TOKEN FORMATS                                           10
3.1 TOKEN FRAMINGS                                                 10
3.2 INITIALCONTEXTTOKEN FORMAT                                     12
3.3 TARGETRESULTTOKEN                                              15
3.4 ERRORTOKEN                                                     16
3.5 PER MESSAGE TOKENS                                             17
3.5.1 MICTOKEN                                                     18
3.5.2 WRAPTOKEN                                                    19
3.6 CONTEXTDELETETOKEN                                             19
4. DATA ELEMENT DEFINITIONS                                        20
4.1 ACCESS CONTROL DATA ELEMENTS                                   20
4.1.1 GENERALISED CERTIFICATE                                      20
4.1.2 SECURITY ATTRIBUTES                                          25
4.1.3 PAC CONTENTS                                                 26
4.1.4 PROTECTION METHODS                                           28
4.1.5 EXTERNAL CONTROL VALUES CONSTRUCT                            33
4.2 BASIC KEY DISTRIBUTION                                         34
4.2.1 KEYING INFORMATION SYNTAX                                    34
4.2.2 OBJECT IDENTIFIERS                                           36
4.2.3 HYBRID INTER-DOMAIN KEY DISTRIBUTION SCHEME DATA ELEMENTS    37
4.2.4 KEY ESTABLISHMENT DATA ELEMENTS                              38
4.2.5 KERBEROS DATA ELEMENTS                                       39
4.2.6 PROFILING OF KD-SCHEMES                                      39
4.3 DIALOGUE KEY BLOCK                                             42
4.4 ATTRIBUTE DEFINITIONS                                          43
4.4.1 PRIVILEGE ATTRIBUTES                                         44
4.4.2 MISCELLANEOUS ATTRIBUTES                                     45
4.4.3 QUALIFIER ATTRIBUTES                                         45
5. ALGORITHMS AND CIPHERTEXT FORMATS                               46

Baize, Farrell, Parker    Document Expiration: 21 May 1996   [Page 2]


internet-draft                                       November 21, 1995

6. SESAME MECHANISM NEGOTIATION                                    48
7. NAME TYPES                                                      50
7.1 KERBEROS NAMING                                                50
7.2 DIRECTORY NAMING                                               51
8. ERROR CODES                                                     52
9. SECURITY CONSIDERATIONS                                         52
10. REFERENCES                                                     52
11. AUTHOR'S ADDRESSES                                             53
APPENDIX A: ASN.1 MODULE DEFINITIONS                               53
A.1 SESAME ASN.1 DEFINITIONS                                       53
A.2  KERBEROS ASN.1 DEFINITIONS                                    62
A.3  SPKM ASN.1 DEFINITIONS                                        64
APPENDIX B: ECMA BACKGROUND MATERIAL.                              68
APPENDIX C: SESAME IMPLEMENTATION STATUS                           68


1.2 Acknowledgements

   The SESAME project has been carried out by Bull SA, ICL and
   Siemens (SNI, Siemens ZFE and SSE) under part funding from the
   CEC as RACE project R2051.

   The SESAME GSS-API protocols re-use data structures developed in
   Kerberos V5 [Kerberos] and SPKM [SPKM] for key management and
   authentication. SESAME has merged these into a wider framework
   supporting distributed access control and delegation features.

   With apologies to those omitted, the following are amongst the
   people who have made significant contributions to the ECMA and
   SESAME work: Helmut Baumgaertner, John Cosgrove, Hiep Doan,
   Belinda Fairthorne, Peter Hartmann, Keith Howker, Per Kaijser,
   Jacques Lebastard, Ronan Long, Piers McMahon, Frank O'Dwyer,
   Denis Pinkas, Mike Roe, Laurent Rouilhac, Don Salmon, Asmund
   Skomedal and Mark Van DenWauver.

2.  THE SESAME TECHNOLOGY

2.1 Overview

   SESAME supports authentication, access control, communication
   integrity and communication confidentiality, and offers the means
   to ensure that access to services is policed to the appropriate
   level of security.

   The SESAME authentication service supports authentication using
   either the Kerberos V5 protocols or public key technology (based
   on X.511). In SESAME then, principals may authenticate using
   either a password or their private key.

   After successful authentication by an Authentication Server (AS),
   the initiator obtains a ticket (a "PAS Ticket") which he can

Baize, Farrell, Parker    Document Expiration: 21 May 1996   [Page 3]


internet-draft                                       November 21, 1995

   present to a Privilege Attribute Server (PAS) to obtain proof of
   his access rights in the form of a Privilege Attribute
   Certificate (PAC) which is a specific form of the Access Control
   Certificate defined in [ISO 10181-3], the Access Control
   Framework.

   Having selected a target application, the initiator requires
   keying information which, in SESAME provides two functions:

   -  PAC protection, in order to prevent anybody but the owner or
       authorised delegates making use of the PAC, and,
   -  key distribution, to support integrity or confidentiality
       protection of application data.

   Depending on whether the initiator and/or target make use of
   asymmetric or symmetric key technology for key distribution, the
   keying information is either fully constructed by the initiator
   or constructed with the assistance of a Key Distribution Service
   (KDS).

   The PAC and the keying information are then presented by the
   initiator to the target application in an initial context token.

   An access control decision can then be made based on the
   initiator's security attributes and the access control
   information attached to the controlled resource.

   Some extensions to the base GSS-API are required in order for
   applications to take full advantage of the access control and
   delegation capabilities of SESAME. As these extensions are
   independent of the SESAME mechanism they are specified in a
   separate draft [XGSSAPI].

   Having established a security context the initiator and target
   application can then use the per message protection services
   provided by GSS-API.

   This draft specifies the exchanges between initiator and target
   which take place in this environment.

2.2 SESAME Concepts

   The next sections contain very brief descriptions of the key
   concepts from the ECMA architecture which are implemented in
   SESAME. For full details refer to [SESOV].

2.2.1    SESAME Access Control Concepts

2.2.1.1  Domains

   A `security domain' is a set of elements, a security authority

Baize, Farrell, Parker    Document Expiration: 21 May 1996   [Page 4]


internet-draft                                       November 21, 1995

   and a set of security relevant activities in which the set of
   elements are subject to the security policy, administered by the
   security authority, for the specified activities [ISO 10181-1].
   In the current SESAME UNIX implementation there is one
   authentication service (AS), privilege attribute service (PAS)
   and key distribution service (KDS) per domain.

2.2.1.2  Identity

   Identity is a real world attribute having multiple uses in
   computer systems. Amongst the uses to which identity may be put
   are:

   -  as a means of claiming who you are, i.e. it is what you
       present when logging on to a system to help the system locate
       the authentication information that it will use to verify your
       claim. Call this use "Login",
   -  as a means of making you accountable for your actions, i.e. it
       is the identity that appears in audit trails. Call this use
       "Audit",
   -  as a means of obtaining access to protected objects, for
       example the identity that appears in an Access Control List.
       Call this use "Access",
   -  as a means of locating and permitting the release of your
       Privilege Attributes within a Privilege Attribute Service.
       This is a special case of the "Access" use. Call this use
       "Access to Privilege Attributes".

   All of these uses could in theory be encompassed by implementing
   one single type of attribute called "Identity Attribute" used for
   everything, and this is commonly done; however this results in
   there being a number of security policies that are impossible to
   implement.

   The question now arises: In order to support a reasonable
   spectrum of real world security policies, how many separate types
   of identity attribute is it appropriate to support in a
   distributed security architecture? The SESAME answer is:
   potentially all of them, but the identity used for login (the
   "Login Name") need not appear other than as a parameter in
   authentication exchanges. Most of the others are optional. The
   names that have been chosen for the identity attribute types that
   are supported in SESAME are as follows:

   Authenticated Identity   which in SESAME is the identity held in
                             the PAS ticket obtained from
                             Authentication Server. This is used for
                             "Access to Privilege Attributes",
   Access Identity          which is used in PACs for "Access" In
                             SESAME this attribute reflects a value
                             given by the PAS administrator,

Baize, Farrell, Parker    Document Expiration: 21 May 1996   [Page 5]


internet-draft                                       November 21, 1995

   Audit Identity           which is used in PACs for "Audit". In
                             SESAME this is a separate field in the
                             PAC, which reflects a value given by
                             the PAS administrator.


2.2.1.3  Privilege Attributes

   SESAME is designed to cater for heterogeneous systems where users
   need to access UNIX applications as well as proprietary
   applications in the same session. The user's security manager
   does not have to manage separate sets of Privilege Attributes for
   each of end-system even if they handle the same global values in
   different ways.

   ECMA addressed this problem by defining standard Privilege
   Attribute types that are independent of specific end-system
   representations but which can be mapped as appropriate in the
   receiving system. When a SESAME user is granted membership of
   e.g. a group, this can be represented once as a Privilege
   Attribute in a global form.

   The privilege attributes which are supported in this draft are:
                 access identity
                 primary group
                 group
                 role

   SESAME also allows for domain defined attributes (i.e. defined by
   the PAS administrator) to be placed in the PAC.

2.2.1.4  Roles

   SESAME supports access control policies based on the concept of a
   user's organisational role or job. A user working in a particular
   role is likely to need particular privileges and controls which
   give the required access to particular applications and services.
   For example, he may need to be a member of a particular group and
   have access to particular target application groups. The
   administrator defines a set of Privilege Attributes which are
   associated with a role, and the controls (see later) which are to
   apply to their use. The administrator also defines which users
   can take which roles.

   Some of the advantages of role based access control are:

   -  the user does not need to be aware of the Privilege Attributes
       he has. The most he needs to know are his different role names
       (e.g. quality controller, or pay clerk) and select one of
       these. However he does not necessarily even need to know these
       since he always has either an individual default role name or

Baize, Farrell, Parker    Document Expiration: 21 May 1996   [Page 6]


internet-draft                                       November 21, 1995

       the system default role name,
   -  if the user changes job, once the administrator has updated
       his roles, when he next uses the system, he automatically gets
       the privileges associated with the new job,
   -  administration is significantly simplified if many users take
       the same role, as the set of Privilege Attributes for the role
       only need to be defined once,
   -  if a specific "Role" Privilege Attribute is associated with
       the job role, access control in applications can be based on
       this, rather than on individual user identities, thus
       simplifying administration of the target system.

2.2.1.5  Access Paths and Delegation

   Distributed systems commonly contain application services that
   are themselves distributed over a number of servers. An initiator
   accessing such a service may not know which server can support
   its requests, and may simply make a request on a convenient
   server, expecting that server to act as its delegate with respect
   to another server if necessary. This delegation could be repeated
   until the server that can handle the request directly is found.

   An initiator may not wish to delegate all his rights, and may
   also want to restrict the area within which the PAC may be used.
   For that purpose, PACs can be arranged to be valid only for
   specific nominated targets. A PAC may contain many target names.

   Mechanisms are provided to prevent a PAC from being delegated
   where this is appropriate. In fact the same PAC can be sometimes
   delegatable, sometime not.

2.2.1.6  Application trust Groups

   A PAC may contain one or more target or delegate application or
   "Trust Group" names specifying which targets or delegate-targets
   the PAC is valid for. A Trust Group name is simply the name of a
   group of applications, defined by the security administrator,
   that mutually trust each other not to spoof each others'
   identities.

   In order to allow for a PAC which is usable at all targets a
   special trust group is defined - the "universal" trust group. A
   PAC targeted at the universal trust group can still be protected
   using target controls (as in delegation) which means that such a
   PAC still cannot be stolen.

2.2.2    Target Access Enforcement Function

   In SESAME the security processing functionality on the target is
   split between two different entities - the target application and
   the target access enforcement function (targetAEF). ISO [ISO/IEC

Baize, Farrell, Parker    Document Expiration: 21 May 1996   [Page 7]


internet-draft                                       November 21, 1995

   10181-3] defines an Access Enforcement Function to be  something
   collocated with a target application which controls access to
   that target application. This has a number of advantages:

   -  the security critical code is isolated which makes security
       evaluation simpler,
   -  administration is simplified as one targetAEF may "serve" many
       target applications,
   -  the number of long-term keys in the system can be reduced
       since only the targetAEF need share a symmetric key with the
       security server or possess a key pair,
   -  different administrators can be responsible for the target
       application and targetAEF,
   -  as the initiator establishes a key with the targetAEF (see
       later) this keying information can be re-used whenever another
       target on the same machine is accessed.

   The functions for which the targetAEF is responsible are:

   -  processing of keying information (resulting in the
       establishment of a shared symmetric key between initiator and
       target)
   -  PAC validation; including e.g. checking that the PAS that
       produced the PAC is trusted, the timeliness of the PAC, and
       its cryptographic correctness
   -  target access control; releasing the established keys to the
       appropriate target application

   In the UNIX SESAME implementation, the targetAEF is implemented
   as a separate daemon per machine which deals with all target
   applications on that machine. The SESAME GSS-API library linked
   to the target application communicates with this process.  Of
   course, none of this precludes the targetAEF being linked to the
   target in other implementations (e.g. on Windows) - however, in
   such cases some of the above advantages are lost.

2.2.3    SESAME Key Distribution

   There are three different key distribution schemes in SESAME.
   Each depends upon the existence of long term cryptographic keys
   which held by targetsAEFs and KDSs. These keys may be either
   symmetric or asymmetric. In the case where the keys are symmetric
   they are always shared between the targetAEF and its KDS. In the
   case where the long term keys are asymmetric we speak of, for
   example, the KDS's private key.

   Initiators may also possess symmetric or asymmetric keys.  In the
   case where an initiator possesses a  symmetric key this will have
   been established as a result of an earlier authentication.

   SESAME can be extended to support other variants, e.g. where the

Baize, Farrell, Parker    Document Expiration: 21 May 1996   [Page 8]


internet-draft                                       November 21, 1995

   initiator shares a symmetric key with a KDS and the targetAEF
   possesses a key pair.

2.2.3.1  Basic keys and dialogue keys

   In SESAME two separate keys which are established between the
   initiator and target for the purpose of application data
   protection. These are known as the integrity and confidentiality
   dialogue keys and are always symmetric.

   Another symmetric key, called the basic key, is established
   between the initiator and targetAEF which is used in PAC
   protection and to derive the dialogue keys.

   The basic key is transmitted from the initiator to the target in
   a structure called a TargetKeyBlock. The information required to
   derive the dialogue keys is transmitted in a structure called a
   DialogueKeyPackage.

2.2.3.2  Basic symmetric key distribution scheme (symmIntradomain)

   In this scheme, the initiator and the targetAEF each share
   different secret keys with the same KDS.

   To establish a basic key between an initiator and a targetAEF,
   the initiator KDS returns, as a result of an initiator request, a
   targetKeyBlock containing a basic key encrypted under the
   targetAEF's long term secret key. On receipt of the
   targetKeyBlock, the targetAEF can extract the basic key directly
   from it.

   An unmodified Kerberos TGS can be used as the KDS in this case.

2.2.3.3  Symmetric key distribution scheme with asymmetric KDSs
(hybridInterdomain)

   In this scheme, the initiator shares a key with a KDS that is
   different from the KDS with which the targetAEF shares its long
   term key. In addition, each KDS possesses an asymmetric key pair.

   To establish a basic key between an initiator and a targetAEF,
   the initiator KDS returns, as a result of an initiator request, a
   TargetKeyBlock containing a basic key encrypted under a temporary
   key and the temporary key encrypted under the targetAEF KDS's
   public key. The TargetKeyBlock is signed using the initiator
   KDS's private key.

   On receipt of the TargetKeyBlock, the targetAEF transmits it to
   its own KDS, and gets back the basic key encrypted under the long
   term secret key it (the targetAEF) shares with its KDS.


Baize, Farrell, Parker    Document Expiration: 21 May 1996   [Page 9]


internet-draft                                       November 21, 1995

   A modified Kerberos TGS can be used as the KDS in this case.

2.2.3.4  Full public key distribution scheme (asymmetric)

   In this scheme, neither the initiator nor the targetAEF uses a
   KDS. Both the initiator and the targetAEF possesses a
   private/public key pair.

   To establish a basic key with a targetAEF, the initiator
   constructs a TargetKeyBlock containing a basic key encrypted
   under the targetAEF's public key. The TargetKeyBlock is signed
   using the initiator's private key.

   On receipt of the TargetKeyBlock, the targetAEF directly
   establishes a basic key from it.

   Modified SPKM handling code can be used for this scheme.

2.2.3.5  Derivation of Dialogue Keys

   Once a basic key has been established between the initiator and
   targetAEF, the derivation of the dialogue keys can take place.
   The dialogue keys are derived using key offsetting - see the
   description of the dialogue key package below.

2.2.4    Use of Cryptography in SESAME

   In several countries of the world the use of cryptography is
   subject to government control, particularly in relation to the
   hiding of information by enciphering it.

   The SESAME architecture has been designed to address these
   problems. The use of confidentiality is kept to a minimum. It is
   provided only where it is an essential function (for example in
   the SESAME key distribution protocols it is necessary to encipher
   the basic key being distributed). PACs are cryptographically
   signed, not enciphered. When encipherment of user and system data
   is a requirement, SESAME allows the algorithms and keys used to
   be separately specified, permitting them to have characteristics
   acceptable to the prevailing political environment.

3.  GSS-API TOKEN FORMATS

   This section describes protocol-visible characteristics of the
   GSS-API as implemented above the SESAME mechanism.

3.1 Token framings

   Following [GSS-API], tokens are enclosed within framing as
   follows:


Baize, Farrell, Parker    Document Expiration: 21 May 1996   [Page 10]


internet-draft                                       November 21, 1995

   Token ::=
     [APPLICATION 0] IMPLICIT SEQUENCE {
      thisMech      MechType, -- the OBJECT IDENTIFIER specified
   below
      innerContextToken ANY DEFINED BY thisMech
   }

   The SESAME mechanism type is identified by an OBJECT IDENTIFIER
   with value:

   { generic-sesame-mech (y) (z) }

   Where:

   generic-sesame-mech ::=OBJECT IDENTIFIER { tbs }

   The values of y and z represent architectural options and
   cryptographic algorithm profiles which are specified in section
   5. These values are intended to be negotiated using a generic GSS-
   API mechanism negotiation scheme like that given in [SNEGO].

   The above GSS-API framing is to be applied to all tokens emitted
   by the SESAME GSS-API mechanism, including context-establishment
   tokens, per-message tokens, and context-deletion token.

   The innerContextToken field of context establishment tokens for
   the SESAME GSS-API mechanism will consist of a SESAME token
   (InitialContextToken, TargetResultToken, ErrorToken) containing a
   token identifier (tokenId) field having the value 01 00 (hex) for
   InitialContextToken, 02 00 (hex) for TargetResultToken, and 03 00
   (hex) for ErrorToken. These are defined to be:

   InitialContextToken  sent by the initiator to a target, to start
                         the process of establishing a Security
                         Association. Returned by the
                         GSS_Init_sec_context call.
   TargetResultToken    sent to the initiator by the target
                         following receipt of an Initial Context
                         Token. Returned by the
                         GSS_Accept_sec_context call.
   ErrorToken           sent by target on detection of an error
                         during Security Association establishment.
                         Returned by either the GSS_Init_sec_context
                         call or the GSS_Accept_sec_context call.

   The innerContextToken field of per-message tokens for the SESAME
   GSS-API mechanism will consist of a SESAME  token (MICToken,
   WrapToken) containing a tokenId field having the value 01 01
   (hex) for MICToken, and 02 01 (hex) for WrapToken. These are
   defined to be:


Baize, Farrell, Parker    Document Expiration: 21 May 1996   [Page 11]


internet-draft                                       November 21, 1995

   MICToken             sent either by the initiator or the target
                         to verify the integrity of the user data
                         sent separately. Returned by GSS_GetMIC.
   WrapToken            sent either by the initiator or the target.
                         Encapsulates the input user data
                         (optionally encrypted) along with integrity
                         check values. Returned by GSS_Wrap.

   The innerContextToken field of context-deletion token for the
   SESAME GSS-API mechanism will consist of a SESAME token
   (ContextDeleteToken) containing a tokenId field having the value
   01 02 (hex). This is defined to be:

   ContextDeleteToken   sent either by the initiator, or the target
                         to release a Security Association. Returned
                         by GSS_Delete_sec_context.

3.2 InitialContextToken format

   This construct provides for the carrying of the following
   Security Association information:

   -  replay protection,
   -  keying information for establishing both the key for
       protecting the exchange of context tokens, including this one,
       and keys for later use in protecting user data exchanges,
   -  access control information (ACI) used to determine what access
       is to be granted by the target to the initiator of the
       Security Association,
   -  information to control the applicability of the ACI (e.g.
       whether delegation is permissible, or identifying for which
       targets the access rights are valid),
   -  information to protect the ACI from being tampered with or
       stolen,
   -  accountability information for use in audit trails.

   InitialContextToken ::=  SEQUENCE{
     ictContents    [0]   ICTContents,
     ictSeal        [1]   Seal
   }

   ictContents
   Body of the initial context token

   ictSeal
   Seal of ictContents computed with the integrity dialogue key.
   Only the sealValue field of the Seal data structure is present.
   The cryptographic algorithms that apply are specified by
   integDKUseInfo in the dialogueKeyBlock field of the initial
   context token.


Baize, Farrell, Parker    Document Expiration: 21 May 1996   [Page 12]


internet-draft                                       November 21, 1995

   ICTContents ::= SEQUENCE {
     tokenId              [0]   INTEGER, -- shall contain X'0100'
     SAId               [1]   OCTET STRING,
     targetAEFPart        [2]   TargetAEFPart,

     targetAEFPartSeal    [3]   Seal,
     contextFlags       [4]   BIT STRING {
                              delegation         (0),
                              mutual-auth        (1),
                              replay-detect       (2),
                              sequence           (3),
                              conf-avail         (4),
                              integ-avail        (5)
                              }
     utcTime              [5]   UTCTime      OPTIONAL,
     usec               [6]   INTEGER    OPTIONAL,
     seq-number           [7]   INTEGER      OPTIONAL,
     initiatorAddress     [8]   HostAddress   OPTIONAL,
     targetAddress        [9]   HostAddress   OPTIONAL
        -- imported from [Kerberos] and used as channel bindings
   }

   tokenId
   Identifies the initial-context token. Its value is 01 00 (hex)

   SAId
   A  random number for identifying the Security Association being
   formed; it is one which (with high probability) has not been used
   previously. This random number is generated by the initiator GSS-
   API implementation and processed by the target GSS-API
   implementation as follows :

   -  If no targetResultToken is expected, the SAId value is taken
       to be the identifier of the Security Association being
       established (if this is unacceptable to the target, then an
       error token with etContents value of
       gss_ses_s_sg_sa_already_established must be generated).
   -  If a targetResultToken is expected, the target generates its
       random number and concatenates it to the end on the
       initiator's random number. The concatenated value is then
       taken to be the identifier of the Security Association being
       established.

   targetAEFPart
   Part of the initial-context token to be passed to the target
   access enforcement function.

   targetAEFPartSeal
   Seal of the targetAEFPart computed with the basic key. Only the
   sealValue field of the Seal data structure is present. The
   cryptographic algorithms that apply are specified by algorithm

Baize, Farrell, Parker    Document Expiration: 21 May 1996   [Page 13]


internet-draft                                       November 21, 1995

   profile in the SESAME mechanism option (see section 6).

   contextFlags
   Combination of flags that indicates context-level functions
   requested by the GSS-API initiator implementation.

   delegation       when set to 0, indicates that the initiator
                     explicitly forbids delegation of the PAC in the
                     targetAEFPart.
   mutual-auth      indicates that mutual authentication is
                     requested.
   replay-detect    indicates that replay detection features are
                     requested to be applied to messages transferred
                     on the established Security Association.
   sequence         indicates that sequencing features are
                     requested to be enforced to messages
                     transferred on the established Security
                     Association.
   conf-avail       indicates that a confidentiality service is
                     available on the initiator side for the
                     established Security Association.
   integ-avail      indicates that an integrity service is
                     available on the initiator side for the
                     established Security Association.
   utcTime
   The initiator's UTC time.

   usec
   Micro second part of the initiator's time stamp. This field along
   with utcTime are used together to specify a reasonably accurate
   time stamp

   seq-number
   When present, specifies the initiator's initial sequence number.
   Otherwise, the default value of 0 is to be used as an initial
   sequence number.

   initiatorAddress
   Initiator's network address part of the channel bindings. This
   field is only present when channel bindings are transmitted by
   the GSS-API caller to the SESAME GSS-API implementation.

   targetAddress
   Target's network address part of the channel bindings. This field
   is only present when channel bindings are transmitted by the GSS-
   API caller to the SESAME GSS-API implementation.

   TargetAEFPart ::= SEQUENCE {
     pacAndCVs          [0]   SEQUENCE OF CertandECV OPTIONAL,
     targetKeyBlock   [1]   TargetKeyBlock,
     dialogueKeyBlock [2]   DialogueKeyBlock,

Baize, Farrell, Parker    Document Expiration: 21 May 1996   [Page 14]


internet-draft                                       November 21, 1995

     targetIdentity   [3]   Identifier,
     flags            [4]   BIT STRING   {
                              delegation         (0)
                            }
   }

         Note 1:  SESAME Validity philosophy is that individual
         PACs have validity of their own, and that it is not
         sensible to have an overall separately specified validity
         period for the whole context.
         Note 2:  SESAME does not permit the target to opt for a
         shorter validity time than that specified by the initiator.
         If it wants to cut off the context earlier it just does it,
         returning an appropriate error.

   pacAndCVs
   The initiator ACI to be used for this Security Association. This
   field is not present when the association does not require any
   ACI. This field contains the PAC together with associated PAC
   protection information. In this specification exactly one of
   these should be present.

   targetKeyBlock
   The targetKeyBlock carrying the basic key to be used for the
   Security Association being established.

   dialogueKeyBlock
   A dialogue key block used by the targetAEF along with the basic
   key to establish an integrity dialogue key and a confidentiality
   dialogue key for per-message protection over the Security
   Association being established.

   targetIdentity
   The identity of the intended target of the Security Association.
   Used by the targetAEF to validate the PAC. Can also be used by
   the targetAEF to help protect the delivery of dialogue keys.

   flags
   flags required by the Target AEF for its validation process. Only
   contains a delegation flag, the value of which is the same as the
   value of delegation flag in contextFlag field of ictContents.
   When the flag is set, all ECVs sent in pacAndCVs are made
   available to the target. Other bits are reserved for future use.

3.3 TargetResultToken

   This token is returned by the target if the mutual-req flag is
   set in the Initial Context Token. It serves to authenticate the
   target to the initiator, since only the genuine target could
   derive the integrity dialogue key needed to seal the
   TargetResultToken.

Baize, Farrell, Parker    Document Expiration: 21 May 1996   [Page 15]


internet-draft                                       November 21, 1995


   TargetResultToken ::=  SEQUENCE{
     trtContents    [0] TRTContents,
     trtSeal        [1] Seal
   }

   TRTContents ::= SEQUENCE {
     tokenId        [0]   INTEGER,    -- shall contain X'0200'
     SAId         [1]   OCTET STRING,
     utcTime        [5]   UTCTime     OPTIONAL,
     usec         [6]   INTEGER     OPTIONAL,
     seq-number     [7]   INTEGER     OPTIONAL,
   }

         Note:    There is no field for returning certification
         data here. This is because any such data that may be
         required is assumed to be returned at the conclusion of
         mechanism negotiation.

   trtContents
   This contains only administrative fields, identifying the token
   type, the context and providing exchange integrity.

         seq-number
         When present, specifies the target's initial sequence
         number, otherwise, the default value of 0 is to be used as
         an initial sequence number.

   The other administrative fields are as described in above.

   trtSeal
   Seal of trtContents computed with the integrity dialogue key.
   Only the sealValue field of the Seal data structure is present.
   The cryptographic algorithms that apply are specified by
   integDKUseInfo in the dialogueKeyBlock field of the initial
   context token.

3.4 ErrorToken

   ErrorToken ::=   {
      tokenType     [0]   OCTET STRING VALUE X'0400',
      etContents    [1]   ErrorArgument,
   }

   etContents
   Contains the reason for the creation of the error token. The
   different reasons are given as minor status return values.

   ErrorArgument ::= ENUMERATED {
     gss_ses_s_sg_server_sec_assoc_open              (1),
     gss_ses_s_sg_incomp_cert_syntax                     (2),

Baize, Farrell, Parker    Document Expiration: 21 May 1996   [Page 16]


internet-draft                                       November 21, 1995

     gss_ses_s_sg_bad_cert_attributes                (3),
     gss_ses_s_sg_inval_time_for_attrib              (4),
     gss_ses_s_sg_pac_restrictions_prob              (5),
     gss_ses_s_sg_issuer_problem                         (6),
     gss_ses_s_sg_cert_time_too_early                (7),
     gss_ses_s_sg_cert_time_expired                  (8),
     gss_ses_s_sg_invalid_cert_prot                  (9),
     gss_ses_s_sg_revoked_cert                           (10),
     gss_ses_s_sg_key_constr_not_supp                (11),
     gss_ses_s_sg_init_kd_server_ unknown            (12),
     gss_ses_s_sg_init_unknown                           (13),
     gss_ses_s_sg_alg_problem_in_dialogue_key_block    (14),
     gss_ses_s_sg_no_basic_key_for_dialogue_key_block   (15),
     gss_ses_s_sg_key_distrib_prob                       (16),
     gss_ses_s_sg_invalid_user_cert_in_key_block       (17),
     gss_ses_s_sg_unspecified                        (18),
     gss_ses_s_g_unavail_qop                             (19),
     gss_ses_s_sg_invalid_token_format                   (20)
   }

3.5 Per Message Tokens

   The syntax of the Per Message Token has the same general
   structure for both MIC and Wrap tokens:

   PMToken ::=  SEQUENCE{
     pmtContents    [0]   PMTContents,
     pmtSeal        [1]   Seal
        -- seal over the pmtContents being protected
   }

   PMTContents ::= SEQUENCE {
     tokenId              [0]   INTEGER, -- shall contain X'0101'
     SAId               [1]   OCTET STRING,
     seq-number           [2]   INTEGER
   OPTIONAL,
     userData           [3]   CHOICE {
                                plaintextBIT STRING,
                                ciphertext    OCTET STRING
                        }                            OPTIONAL,
     directionIndicator [4]   BOOLEAN                OPTIONAL
   }

   pmtContents

         tokenId
         SAId
         See above for a description of these fields

         seq-number
         This field must be present if replay detection or message

Baize, Farrell, Parker    Document Expiration: 21 May 1996   [Page 17]


internet-draft                                       November 21, 1995

         sequencing have been specified as being required at
         Security Association initiation time. The field contains a
         message sequence number whose value is incremented by one
         for each message in a given direction, as specified by
         directionIndicator. The first message sent by the initiator
         following the InitialContextToken shall have the message
         sequence number specified in that token, or if this is
         missing, the value 0. The first message returned by the
         target shall have the message sequence number specified in
         the TargetReplyToken if present, or failing this, the value
         0.
         The receiver of the token will verify the sequence number
         field by comparing the sequence number with the expected
         sequence number and the direction indicator with the
         expected direction indicator. If the sequence number in the
         token is higher than the expected number, then the expected
         sequence number is adjusted and GSS_S_GAP_TOKEN is
         returned. If the token sequence number is lower than the
         expected number, then the expected sequence number is not
         adjusted and GSS_S_DUPLICATE_TOKEN or GSS_S_OLD_TOKEN is
         returned, whichever is appropriate. If the direction
         indicator is wrong, then the expected sequence number is
         not adjusted and GSS_S_UNSEQ_TOKEN is returned

         userData
         See specific token type narratives below.

         directionIndicator
         FALSE indicates that the sender is the context initiator,
         TRUE that the sender is the target.

   pmtSeal
   See specific token type narratives below.

3.5.1    MICToken

   Use of the GSS_Get_MIC() call yields a per-message token,
   separate from the user data being protected, which can be used to
   verify the integrity of that data as received. The token and the
   data may be sent separately by the sending application and it is
   the receiving application's responsibility to associate the
   received data with the received token. The syntax of the token
   is:

      MICToken  ::=   PMToken

   The overall structure and field contents of the token are
   described above. Fields specific to the MICToken are:

   userData
   Not present for MIC Tokens.

Baize, Farrell, Parker    Document Expiration: 21 May 1996   [Page 18]


internet-draft                                       November 21, 1995


   pmtSeal
   The Checksum is calculated over the DER encoding of the
   pmtContents field with the user data temporarily placed in the
   userData field. The userData field is not transmitted.


3.5.2    WrapToken

   Use of the GSS_Wrap() call yields a token which encapsulates the
   input user data (optionally encrypted) along with associated
   integrity check values. The token emitted by GSS_Wrap() consists
   of an integrity header followed by a body portion that contains
   either the plaintext data (if conf_alg = NULL) or encrypted data.
   The syntax of the token is:

      WrapToken  ::=   PMToken

   The overall structure and field contents of the token are
   described above. Fields specific to the WrapToken are:

   userData
   Present either in plain text form (the choice is plaintext), or
   encrypted (choice ciphertext). If the data is encrypted, it is
   performed using the Confidentiality Dialogue Key, and as in
   [Kerberos], an 8-byte random confounder is first prepended to the
   data to compensate for the fact that an IV of zero is used for
   encryption.

   wtSeal
   The Checksum is calculated over the pmtContents field, including
   the userData. However if the userData field is to be encrypted,
   the seal value is computed prior to the encryption.

3.6 ContextDeleteToken

   The ContextDeleteToken is issued by either the context initiator
   or the target to indicate to the other party that the context is
   to be deleted.

   ContextDeleteToken ::=  SEQUENCE {
     cdtContents  [0]   CDTContents,
     cdtSeal      [1]   Seal
                          -- seal over cdtContents, encrypted
                          -- under the Integrity Dialogue Key
                          -- contains only the sealValue field
   }

   CDTContents ::= SEQUENCE {
     tokenType    [0]   OCTET STRING VALUE X'0301',
     SAId       [1]   OCTET STRING,

Baize, Farrell, Parker    Document Expiration: 21 May 1996   [Page 19]


internet-draft                                       November 21, 1995

     utcTime      [2]   UTCTime OPTIONAL,
     usec       [3]   INTEGER OPTIONAL,
     seq-number   [4]   INTEGER OPTIONAL,
   }

   cdtContents
   This contains only administrative fields, identifying the token
   type, the context and providing exchange integrity.

         seq-number
         When present, this field contains a value one greater than
         that of the seq-number field of the last token issued from
         this issuer.
         The other administrative fields are as described above.

   trtSeal
   See above for a general description of the use of this construct.

4.  DATA ELEMENT DEFINITIONS

   In this section we give the details of the structures which are
   present in the tokens defined above.

   These ASN.1 definitions represent the profile of the ASN.1 types
   defined in [ECMA-219] which are implemented in the SESAME
   project. In some cases CHOICEs and OPTIONAL fields which are
   defined by ECMA have been omitted as they are not supported in
   this version of SESAME. In order to retain compatibility this
   leads to a non-obvious numbering for tags.

   In this specification all of the type specifying object
   identifiers are below the arc:

   generic-sesame-oids ::= OBJECT IDENTIFIER { tbs }
      -- top of the SESAME types arc


4.1 Access Control Data Elements

   The ASN.1 definitions for the PAC and related data structures.

4.1.1    Generalised certificate

   A Generalised Certificate (PAC) is composed of three main
   structural components :

   The "commonContents" fields collectively serve to provide
   generally required management and control over the use of the
   PAC.

   The "specificContents" fields are different for different types

Baize, Farrell, Parker    Document Expiration: 21 May 1996   [Page 20]


internet-draft                                       November 21, 1995

   of certificate, and contain a type identifier to indicate the
   type. In this draft only one type is defined: the Privilege
   Attribute Certificate (PAC).

   The "checkValue" fields are used to guarantee the origin of the
   certificate.

   GeneralisedCertificate ::= SEQUENCE{
     certificateBody    [0]   CertificateBody,
     checkValue       [1]   CheckValue}

   CertificateBody ::= CHOICE{
     encryptedBody      [0]   BIT STRING,
     normalBody       [1]   SEQUENCE{
                              commonContents  [0] CommonContents,
                              specificContents[1] SpecificContents
                            }
   }

   The next sections describe these three main structural components
   of the Generalised Certificate.

4.1.1.1  Common Contents fields

   CommonContents ::= SEQUENCE{
     comConSyntaxVersion  [0]   INTEGER { version1 (1) }DEFAULT 1,
     issuerDomain       [1]   Identifier             OPTIONAL,
     issuerIdentity     [2]   Identifier,
     serialNumber       [3]   INTEGER,
     creationTime       [4]   UTCTime                OPTIONAL,
     validity           [5]   Validity,
     algId              [6]   AlgorithmIdentifier,
     hashAlgId            [7]   AlgorithmIdentifier    OPTIONAL
   }

         Note:
         In the imported definition of AlgorithmIdentifier, ISO
         currently permits both a hash and a cryptographic algorithm
         to be specified. If this is done, they must appear in the
         algId field. The hashAlgId field is present for those cases
         where a separate hash algorithm specification is required.

   Identifier ::= CHOICE{
     objectId         [0]   OBJECT IDENTIFIER,
     directoryName      [1]   Name,

            -- imported from the Directory Standard
     printableName      [2]   PrintableString,
     octets           [3]   OCTET STRING,
     intVal           [4]   INTEGER,
     bits             [5]   BIT STRING,

Baize, Farrell, Parker    Document Expiration: 21 May 1996   [Page 21]


internet-draft                                       November 21, 1995

     pairedName       [6]   SEQUENCE{
                              printableName   [0] PrintableString,
                              uniqueName     [1] OCTET STRING
                            }
   }

   Validity ::= SEQUENCE {
            notBefore     UTCTime,
            notAfter      UTCTime
   } -- as in [ISO/IEC 9594-8]
   -- Note: Validity is not tagged, for compatibility with the
   -- Directory Standard.

   comConFieldsSyntaxVersion
   Identifies the version of the syntax of the combination of the
   commonContents and the checkValue fields parts of the
   certificate.

   issuerDomain
   The security domain of the issuing authority. Not required if the
   form of issuerIdentity is a full distinguished name, but required
   if other forms of naming are in use, such as proprietary
   identifiers.

   issuerIdentity
   The identity of the issuing authority for the certificate.

         Note
         Identifier is a general syntax which is used for all fields
         containing names or identifiers of various kinds. It can
         take any of the forms listed: object identifier, Directory
         DN or RDN, a printable name, an octet string, an integer
         value, a bit string or a paired value consisting of
         readable and unique components.

   serialNumber
   The serial number of the certificate (PAC) as allocated by the
   issuing authority.

   creationTime
   The UTC time that the certificate was created, according to the
   authority that created it.

   validity
   A pair of start and end times within which the certificate is
   deemed to be valid.

   algId
   The identifier of the symmetric or of the asymmetric
   cryptographic algorithm used to seal or to sign the certificate.
   If there is a single identifier for both the encryption algorithm

Baize, Farrell, Parker    Document Expiration: 21 May 1996   [Page 22]


internet-draft                                       November 21, 1995

   and the hash function, it appears in this field.

   hashAlgId
   The identifier of the hash algorithm used in the seal or in the
   signature.

4.1.1.2  Specific Certificate Contents

   SpecificContents ::= CHOICE{
     pac                [1]   PACSpecificContents
      -- only the PAC is used here
   }

   SpecificContents
     pac               The PAC specific contents defined below.

4.1.1.3  Check value

   In this specification a PAC is protected using by being digitally
   signed by the issuer.

   A signature may be accompanied by information identifying the
   Certification Authority under which the signature can be
   verified, and with an optional convenient reference to or the
   actual value of the user certificate for the private key that the
   signing authority used to sign the certificate.

   CheckValue ::= CHOICE{
     signature      [0]   Signature
        -- only signature supported here
   }

   Signature ::= SEQUENCE{
     signatureValue       [0]   BIT STRING,
     asymmetricAlgId        [1]   AlgorithmIdentifier
   OPTIONAL,
     hashAlgId              [2]   AlgorithmIdentifier
   OPTIONAL,
     issuerCAName         [3]   Identifier
   OPTIONAL,
     caCertInformation      [4]   CHOICE {
            caCertSerialNumber    [0]    INTEGER,
            certificationPath     [1]    CertificationPath
     }
   OPTIONAL
   }
   --CertificationPath    is imported from [ISO/IEC 9594-8]

   signatureValue
   The value of the signature. It is the result of an asymmetric
   encryption of a hash value of the certificateBody.

Baize, Farrell, Parker    Document Expiration: 21 May 1996   [Page 23]


internet-draft                                       November 21, 1995


   asymmetricAlgId
   Only present if the certificate body is encrypted, then it is a
   duplication of the algId value in "commonContents".

   hashAlgId
   Only present if the certificate body is encrypted, then it is a
   duplication of the hashAlgId value in "commonContents".

   issuerCAName
   The identity of the Certification Authority that has signed the
   user certificate corresponding to the private key used to sign
   this certificate.

   caCertInformation
   Contains either just a certificate serial number which together
   with the issuerCAName uniquely identifies the user certificate
   corresponding to the private key used to sign this certificate,
   or a full specification of a certification path via which the
   validity of the signature can be verified. The latter option
   follows the approach used in [ISO/IEC 9594-8].

   The Seal structure is used in the Tokens defined in section 3
   above.

   Seal ::= SEQUENCE{
     sealValue          [0]   BIT STRING,
     symmetricAlgId   [1]   AlgorithmIdentifier        OPTIONAL,
     hashAlgId          [2]   AlgorithmIdentifier      OPTIONAL,
     targetName       [3]   Identifier           OPTIONAL,
     keyId            [4]   INTEGER              OPTIONAL
   }

   sealValue
   The value of the seal. It is the result of a symmetric encryption
   of a hash value of a set of octets (which are the DER encoding of
   some ASN.1 type)

   symmetricAlgId
   An optional indicator of the sealing algorithm.

   hashAlgId
   Only present if the symmetricAlgId does not specify which hashing
   algorithm is used.

   targetName
   This field identifies the targetAEF or target with which the
   symmetric key used for the seal is shared.

   keyId
   This serial number together with the targetName uniquely

Baize, Farrell, Parker    Document Expiration: 21 May 1996   [Page 24]


internet-draft                                       November 21, 1995

   identifies the symmetric key used in the seal.

4.1.1.4  Certificate Identity

   Certificate identity is a named concatenation of the three named
   field types defined in CommonContents which together uniquely
   identify a certificate.

   CertificateId ::= SEQUENCE {
     issuerDomain   [0] Identifier
   OPTIONAL,
     issuerIdentity [1] Identifier,
     serialNumber   [2] INTEGER
   }
            -- serialNumber is the same as in [ISO/IEC 9594-8]

4.1.2    Security Attributes

   The security attribute is a basic construct used in all
   certificate types defined in this specification.

   SecurityAttribute ::= SEQUENCE{
     attributeType    Identifier,
     attributeValue SET OF SEQUENCE {
                      definingAuthority  [0] Identifier
   OPTIONAL,
                      securityValue      [1] SecurityValue
                    }
   }
      --  NOTE: SecurityAttribute is not tagged, for compatibility
      -- with the Directory Standard.

   SecurityValue ::= CHOICE{
     directoryName      [0]   Name,
     printableName      [1]   PrintableString,
     octets           [2]   OCTET STRING,
     intVal           [3]   INTEGER,
     bits             [4]   BIT STRING,
     any                [5]   ANY -- defined by attributeType
   }

   Note:
   Only one set member is permitted in attributeValue. Multivalue
   attributes are effected in the securityValue field, where the
   "SEQUENCE OF" construct can be used. This restriction avoids any
   certificate hash value ambiguity that may occur with
   indeterminacy in the representation of the order of SET members.
   At the same time, by including "SET OF" in the syntax, we enable
   security attributes to be stored as normal in a Directory
   whenever the choice made within Identifier is OBJECT IDENTIFIER.
   If other choices are made, encapsulation in an outer Directory

Baize, Farrell, Parker    Document Expiration: 21 May 1996   [Page 25]


internet-draft                                       November 21, 1995

   Attribute structure would first be necessary.

   attributeType
   Defines the type of the attribute. Attributes of the same type
   have the same semantics when used in Access Decision Functions,
   though they may have different defining authorities.

   definingAuthority
   The authority responsible for the definition of the semantics of
   the value of the security attribute. This optional field of the
   attributeValue can be used to resolve potential value clashes.

         Note:
         This is not to be confused with the Attribute Authority
         responsible for controlling which principals are permitted
         to use which attribute values in PACs - though under some
         security policies they may be the same.

   securityValue
   The value of the security attribute. Its syntax is can be either
   one of the basic syntaxes for attributes or a more complex one
   determined by the attribute type.

4.1.3    PAC Contents

   The syntax of the PAC contents is:

   PACSpecificContents ::= SEQUENCE{
     pacSyntaxVersion [0]   INTEGER{  version1 (1)}
   DEFAULT 1,
     protectionMethods  [2]   SEQUENCE OF MethodGroup
   OPTIONAL,
     pacType            [4]   ENUMERATED{
                                  primaryPrincipal     (1),
                                  temperedSecPrincipal  (2),
                                  untemperedSecPrincipal(3)
                            }
   DEFAULT 3,
     privileges       [5]   SEQUENCE OF PrivilegeAttribute,
     restrictions     [6]   SEQUENCE OF Restriction
   OPTIONAL,
     miscellaneousAtts  [7]   SEQUENCE OF SecurityAttribute
   OPTIONAL,
     timePeriods        [8]   TimePeriods
   OPTIONAL
   }

   PrivilegeAttribute ::= SecurityAttribute

   Restriction ::= SEQUENCE {
     howDefined [0] CHOICE {

Baize, Farrell, Parker    Document Expiration: 21 May 1996   [Page 26]


internet-draft                                       November 21, 1995

                included        [3] BIT STRING
                },
                                -- the actual restriction in a form
                                -- undefined here
     type       [2] ENUMERATED  {
                      mandatory (1),
                      optional    (2)}       DEFAULT mandatory,
     targets      [3] SEQUENCE OF SecurityAttribute    OPTIONAL
   }
                  -- applies to all targets if this is omitted

   pacSyntaxVersion
   Syntax version of the PAC.

   protectionMethods
   A sequence of optional groups of Method fields used to protect
   the certificate from being stolen or misused. For a full
   description see section 4.1.4.

   pacType
   Indicates whether the privileges contained in the PAC are those
   of a Primary Principal, of a Secondary Principal tempered by the
   privileges of a Primary Principal (the privileges of the
   Secondary Principal which appear in the PAC are a subset of the
   whole set of the privileges of the Secondary Principal, taking
   into consideration the privileges of the Primary Principal - or
   the lack of knowledge of them) or of a Secondary Principal (the
   privileges of the Secondary Principal have not been affected by
   any privileges of the Primary Principal).

   privileges
   Privilege Attributes of the principal.

   restrictions
   This field enables the original owner of the PAC to impose
   constraints on the operations for which it is valid. A
   restriction is a bit string which can be either included in the
   PAC or external to it. A restriction can be targeted to one or
   more application components. Two types of restriction are
   supported:
         -   Mandatory: If a target application to which the
              restriction applies cannot understand the bit string
              defining the restriction, access should not be
              granted,
         -   Optional: If a target application to which the
              restriction applies cannot understand the bit string,
              it is expected to ignore it.

    Only one way of expressing the restrictions is supported in this
    specification:


Baize, Farrell, Parker    Document Expiration: 21 May 1996   [Page 27]


internet-draft                                       November 21, 1995

         included
         The restriction is directly included in "restrictions"
         field of the certificate.

   miscellaneousAtts
   Security attributes which are neither privileges attributes nor
   restrictions attributes. In a PAC, this may include identity
   attributes such as Audit Identity.

         Note:
         We do not preclude the authenticated identity to be one of
         the miscellaneous attributes. However, when it is present,
         it must not be used for access control purposes. Access
         identity security attributes, if present in the PAC, appear
         in the privileges field.

   timePeriods
   This field adds further time restrictions to the validity field
   of the commonContents. Either startTime or endTime can be
   optional. The TimePeriods control is passed if the time now is
   within any of the sequence periods, or if there is a period with
   a start before now and no endTime, or there is a period with an
   end after now and no startTime.

4.1.4    Protection Methods

   MethodGroup ::= SEQUENCE OF Method

   Method ::= SEQUENCE{
     methodId         [0] MethodId,
     methodParams     [1] SEQUENCE OF Mparm
   OPTIONAL
   }

   MethodId ::= CHOICE{
     predefinedMethod [0] ENUMERATED {
                                controlProtectionValues     (1),
                                ppQualification
   (2),
                                targetQualification        (3),
                                delegateTargetQualification  (4)
                              }
   }

   Mparm ::= CHOICE{
     pValue               [0]   PValue,
     securityAttribute      [1]   SecurityAttribute
   }

   PValue ::= SEQUENCE{
     pv                   [0]   BIT STRING,

Baize, Farrell, Parker    Document Expiration: 21 May 1996   [Page 28]


internet-draft                                       November 21, 1995

     algorithmIdentifier    [1]   AlgorithmIdentifier
   OPTIONAL
   }


   CertandECV ::=   SEQUENCE {
     certificate      [0]   GeneralisedCertificate,
     ecv              [1]   ECV,             OPTIONAL}
            -- ECV is defined in later

   methodId
   Identifies a protection method. Several methods are here. Methods
   can be used in any combination, and except where stated
   otherwise, multiple occurrences of the same method are permitted.
   The choice of methodId determines the permitted choices of method
   parameters in the methodParams construct as described below.

   methodParams
   Parameters for a protection method. The semantics of each
   protection method is described in following sections below. In
   each case, the syntax choice of the mParm field is defined.

4.1.4.1  "Control/Protection Values" protection method

   The MethodId for this is: controlProtectionValues

   This method protects the certificate from being stolen, at the
   same time controlling its acceptance for use by proxy to defined
   groups of target applications. The syntax choice of Mparm for
   this method is:

                 pValue.

   This scheme uses a PAC Protection Value (PV) to provide a method
   of controlling the forwarding of a certificate for use by proxy,
   without the user of the certificate needing to know the precise
   identity of the final target application. It prevents a line-
   tapper from stealing the certificate for his own use, but does
   not demand that the certificate be encrypted. A maximum of one PV
   method is permitted in each method group. Security attributes can
   be associated with the PV by including appropriate protection
   methods in the PV's method group.

   More than one method group can be specified, each containing a
   PV.

   Also associated with each PV is a certificate Control Value (CV)
   external to the certificate. The PV is the result of a one-way
   function applied to the corresponding CV. When the PAC is offered
   to a targetAEF, it is proof of knowledge of this CV which causes
   the PAC to be accepted (subject to the other controls in the PV's

Baize, Farrell, Parker    Document Expiration: 21 May 1996   [Page 29]


internet-draft                                       November 21, 1995

   method group). Unless otherwise specified, the one-way function
   that is used for this method is MD5.

   Either the CVs are generated and PVs calculated by the PAC issuer
   for the client on request for each occurrence of the method in
   the certificate, or the client itself generates the CVs and
   specifies the PVs to the PAC issuer. The PVs are returned in the
   certificate; the corresponding CVs, if they have been generated
   by PAC issuer, are returned along with the certificate, encrypted
   under the key used to protect the certificate request. They are
   returned in the ECV construct described below.

   When the client now sends the PAC to a targetAEF, one or more CVs
   are also sent encrypted under the basic key used to communicate
   with the target AEF. They are sent in the ECV construct. Not all
   of the CVs associated with the PAC need always be sent. The
   targetAEF knows the one-way function and therefore is able to
   verify that the client knows a CV which corresponds to a PV in
   the certificate. If the other controls in the PV's method group
   are passed, the PAC is acceptable under this method group.

   The targetAEF now knows the value of the CVs that have been sent
   to it, and can make available this value to the application or to
   the infrastructure supporting that application so that it can
   forward the certificate for use with target application. By
   including target qualification controls in the method group,
   proxy can be confined to groups of target applications, for
   example all of the servers in a distributed service.

4.1.4.2  "Primary Principal Qualification" protection method

   The MethodId for this is: ppQualification

   This method protects the certificate from being stolen, by
   confining its use to be from one or more nominated Primary
   Principals. In its most restrictive form it permits a certificate
   to be used only from the Primary Principal of the client entity
   to which it was originally issued. It can also be used to permit
   proxy, when the required attributes of the proxy application
   Primary Principals are precisely known. The method does not limit
   the number of target applications at which a PAC might be
   accepted. The syntax choice of Mparm for this method is :

                 securityAttribute

   A sequence of Mparm constructs is permissible, resulting in
   multiple security attributes being present.

   The attributes are inserted in the certificate by the PAC issuer
   according to security policy. They may be requested by the
   client. They are attributes that must be possessed by any Primary

Baize, Farrell, Parker    Document Expiration: 21 May 1996   [Page 30]


internet-draft                                       November 21, 1995

   Principal from which this certificate is to be validly used. When
   a targetAEF receives such a certificate, it is responsible for
   comparing the attributes found in the PAC with the attributes
   that it knows (by other means described below) are associated
   with the initiating Primary Principal. Only if the initiator has
   all of the ppQualification attributes in the certificate, is the
   PAC accepted under this method.

   There way in which a target AEF can know the attributes
   associated with a Primary Principal is by the use of Security
   Associations or Contexts established via a target key block as
   defined here. Whenever an initiator sends a PAC to a target AEF,
   it does so under the protection of a key established by use of
   the targetKeyBlock constructs defined in below. The targetPart of
   the targetKeyBlock defined there contains a construct which
   includes a sequence of Primary Principal security attributes.

   The attribute values are placed in the target key block by the
   trusted server (the KDS) which created it or by the initiator
   (with the asymmetric key distribution scheme).

   The attribute value used here is termed the primary principal
   identifier (PPID) and takes one of two forms depending on the key
   distribution scheme used by the initiator. For the symmetric
   intradomain and hybrid interdomain schemes the PPID takes the
   form of a random bit string which is also sent in the
   authorization data field of the Kerberos ticket. For the
   asymmetric scheme the PPID contains the certificate serial number
   and CA name for the initiator's X.509 public key certificate.
   Further details are given in the profiling of the target key
   block below.

4.1.4.3  "Target Qualification" protection method

   The MethodId for this is: targetQualification.

   This method protects the PAC from misuse by allowing its use only
   by a nominated set of target applications and at the same time
   preventing it from being forwarded by them.

   The syntax choice of Mparm for this method is :

                 securityAttribute

   A sequence of Mparm constructs is permissible, resulting in
   multiple security attributes being present.

   The attributes are inserted in the PAC by the PAC issuer
   according to security policy. They may be requested by the
   client.


Baize, Farrell, Parker    Document Expiration: 21 May 1996   [Page 31]


internet-draft                                       November 21, 1995

   Target AEFs receiving such PACs will compare the values found in
   the PAC with the attributes of the target application. If the
   target application possesses one of the attributes in one of the
   occurrences of this method that is present in a method group, the
   Certificate is deemed to be acceptable under this method in this
   group but the target AEF is expected not to allow the use of the
   certificate for access to further target applications.

4.1.4.4  "Delegate/Target Qualification" protection method

   The MethodId for this is: delegateTargetQualification

   This method protects the certificate from misuse by confining its
   validity to a set of target applications.

   The syntax choice of Mparm for this method is:

                 securityAttribute

   A sequence of Mparm constructs is permissible, resulting in
   multiple security attributes being present.

   The attributes are inserted in the certificate by the PAC issuer
   according to security policy. They may be requested by the
   client.

   The target AEF makes the comparisons described in section
   4.1.4.5, but if the checks are passed, the nominated target
   application is acceptable as both an accessible target and as a
   delegate. The attributes carried by the certificate are valid at
   the target application for authentication or access control
   purposes and the target AEF will allow the use of the certificate
   for access to further target applications.

4.1.4.5  Combining the methods

   PACs are unlikely to contain complex combinations of many method
   types with multiple occurrences of each type. It is expected that
   one occurrence of each of one or two method types in one method
   group would be normal. However the general rule for validating a
   certificate when received by a target AEF is as follows:

   If the PAC is properly signed by an authority recognised by this
   targetAEF and is within the valid time periods then the
   protection methods in each group are tested in turn as described
   below until one of the groups is passed or the PAC is declared
   invalid.

   A method group is passed if it is empty, or if:

         the PAC is for the nominated target application under any

Baize, Farrell, Parker    Document Expiration: 21 May 1996   [Page 32]


internet-draft                                       November 21, 1995

         target or delegateTarget qualification method in this group

         and

         tests on any ppQualification or controlProtectionValues
         method in the group succeeds. If more than one of these is
         present, at least one must be passed. If only one is
         present it must be passed. If none of them is present this
         last check is not required.

   If the group that has been passed only validates the certificate
   for its recipient being a target, then further groups are checked
   to see if the recipient is also valid as a delegate/target. If,
   following these additional checks, a recipient is still valid
   only as a target, the targetAEF is responsible for preventing its
   use for access to further target applications.

4.1.5    External Control Values Construct

   Whenever the protection controlProtectionValues method is in
   place, when a PAC protected under that method is being presented
   as authorisation for an operation, it may be accompanied by one
   or more control values and indices to the method occurrences in
   the certificate to which they apply. Also, when such a
   certificate is being issued to a requesting client, the CV values
   it will need in order to use that certificate may need to be
   returned with it.

   ECV ::= SEQUENCE {
     crypAlgIdentifier  [0]   AlgorithmIdentifier      OPTIONAL,
     cValues            [1]   CHOICE {
                            encryptedCvalueList    [0] BIT STRING,
                            individualCvalues     [1] CValues
                            }
   }

   CValues ::= SEQUENCE OF SEQUENCE {
     index          [0]   INTEGER,
     value          [1]   BIT STRING
   }

   crypAlgIdentifier
   This specifies the encryption algorithm of the control values.

   cValues
   An ECV construct can contain either an encrypted list of control
   values in the encryptedCvalueList field, or a list of
   individually control values in individualCvalues.

   If the encryptedCvalueList choice is made, the whole list is
   encrypted in bulk, but the in-clear contents of this field are

Baize, Farrell, Parker    Document Expiration: 21 May 1996   [Page 33]


internet-draft                                       November 21, 1995

   expected to have the syntax CValues. If the individualCvalues
   choice is made, values are individually encrypted in the value
   fields of the list. Encryption is always done under the basic key
   protecting the operation.

   In the case of the controlProtectionValues method, value is a CV,
   and index is then the index of the method occurrence in the
   certificate, starting at 1.

4.2 Basic Key Distribution

   The TargetKeyBlock is structured as follows:

   -  an identifier (kdSchemeOID) for the key distribution scheme
       being used, which takes the form of an OBJECT IDENTIFIER,
   -  a part which, if present, the target AEF needs to pass on to
       its KDS (targetKDSPart - will be present only when the target
       AEF's KDS is different from the initiator's),
   -  a part which, if present, can be used directly by the target
       AEF (targetPart).

   When a targetAEF using a separate KDS receives the
   targetKeyBlock, it first checks whether it supports the key
   distribution scheme indicated in kdsSchemeOID. Two different
   cases need to be considered:

   1) Only the targetPart is present. The target AEF computes the
       basic key directly, using the information present in the
       TargetPart. The syntax of targetPart is scheme dependent.
       Expiry information can optionally be present in targetPart. If
       supported by the scheme, the Primary Principal attributes of
       the initiator will also be present for PAC protection under
       the Primary Principal Qualification method (see above).

   2) Only the targetKDSPart is present. The targetAEF forwards
       TargetKeyBlock to its KDS. In return it receives a scheme
       dependent data structure which by itself allows the target AEF
       to determine the basic key and, if supported by the scheme,
       the Primary Principal attributes of the initiator for PAC
       protection purposes. Expiry information can optionally be
       present in the targetKDSPart.

   The form of this information depends on the key distribution
   configuration in place.

4.2.1    Keying Information Syntax

   TargetKeyBlock ::= SEQUENCE {
      kdSchemeOID       [2]   OBJECT IDENTIFIER,
      targetKDSpart     [3]   ANY                OPTIONAL,
                                    -- depending on kdSchemeOID

Baize, Farrell, Parker    Document Expiration: 21 May 1996   [Page 34]


internet-draft                                       November 21, 1995

      targetPart        [4]   ANY                OPTIONAL
                                    -- depending on kdSchemeOID
   }

   kdSchemeOID
   Identifies the key distribution scheme used. Allows the targetAEF
   to determine rapidly whether or not the scheme is supported. It
   also allows for the easy addition of future schemes.

   targetKDSpart
   Part of the Target Key Block which is processable only by the KDS
   of the target AEF. This part is sent by the target AEF to its
   local KDS, in order to get the basic key which is in it. It must
   always contain the name of a target "served" by the targetAEF in
   question. The mapping between the name of the application and the
   name of the target AEF is known to the target AEF's KDS which is
   able to authenticate which target AEF is issuing the request for
   translating the targetKDSpart. It can then verify that the AEF is
   one which is responsible for the application name contained in
   the targetKDSpart. If it is, the key is released and is sent
   protected back to the requesting AEF. targetKDSpart should
   include data that enables the KDS of the target AEF to
   authenticate the KDS of the initiator. When the "Primary
   Principal Qualification" protection method needs to be used for
   the PAC, unless there is an accompanying targetPart,
   targetKDSpart must contain the appropriate primary principal
   security attributes (which is always true in this specification).

   targetPart
   Part of the Target Key Block which is processed only by the
   target AEF. When there is no targetKDSpart it is processable
   directly; otherwise it can only be processed after the target
   KDSpart has been processed by the KDS of the target AEF, and the
   appropriate Keying Information has been returned to the AEF. The
   targetPart construct should include data that enables the target
   AEF to authenticate the KDS of the initiator. When the "Primary
   Principal Qualification" protection method needs to be used for
   the PAC, targetPart must contain the primary principal security
   attributes.

   The following table shows the different syntaxes used for
   targetKDSpart and targetPart for the defined KD-schemes.
   "Missing" in the tables means that the relevant construct is not
   supplied.

     KD-Scheme name        kdSchemeOID    targetKDSpart  targetPart

     symmIntradomain     {kd-schemes 1}      Missing       Ticket
     hybridInterdomain   {kd-schemes 3}   PublicTicket    Missing
     asymmetric          {kd-schemes 6}      Missing      SPKM_REQ


Baize, Farrell, Parker    Document Expiration: 21 May 1996   [Page 35]


internet-draft                                       November 21, 1995

        Table 1 - Key Distribution Scheme OBJECT IDENTIFIERs

   The syntax of PublicTicket is given below, and the syntax of
   Ticket (copied from [Kerberos]) is given in appendix A.2. The
   syntax of SPKM_REQ (copied from [SPKM])is given in appendix A.3.

   We now define the new ASN.1 OBJECT IDENTIFIERs and token
   construct data types required for these KD-schemes.

4.2.2    Object Identifiers

   The OBJECT IDENTIFIERs that are for use in the kdSchemeOID field
   of TargetKeyBlock are formally derived from the kd-schemes OBJECT
   IDENTIFIER which is defined as follows:

   kd-schemes   OBJECT IDENTIFIER ::= { generic-sesame-oids tbs }
      -- arc for SESAME key distribution schemes
   symmIntradomain      OBJECT IDENTIFIER ::= {kd-schemes 1}
   hybridInterdomain    OBJECT IDENTIFIER ::= {kd-schemes 3}
   asymmetric             OBJECT IDENTIFIER ::= {kd-schemes 6}
      -- supported key distribution schemes

   The SPKM_REQ construct used in scheme 6 requires a sequence of
   key establishment algorithm identifier values to be inserted into
   the key_estb_set field. The OBJECT IDENTIFIER below is defined as
   the (single) key establishment "algorithm" for the SESAME
   mechanism:

   sesame-key-estb-alg AlgorithmIdentifier ::= {kd-schemes, NULL }
      -- indicates a SESAME key establishment structure within
      -- an SPKM_REQ structure

   kd-schemes
   This OBJECT IDENTIFIER is the top of the arc of key distribution
   scheme OBJECT IDENTIFIERs defined in this specification.

   symmIntradomain
   This OBJECT IDENTIFIER indicates the basic symmetric key
   distribution scheme described in section 2.2.3. As indicated in
   the third column of Table 1, the targetKDSpart of the
   TargetKeyBlock is not supplied and the targetPart contains a
   Kerberos Ticket (see [Kerberos] and appendix A.2). The profile of
   the ticket that is supported this scheme can be found in Table 2.

   hybridInterdomain
   This OBJECT IDENTIFIER indicates the hybrid scheme described in
   section 2.2.3. The targetKDSpart contains a PublicTicket (defined
   in section 4.2.3). The targetPart field is not supplied. The
   PublicTicket contains a Kerberos Ticket. The profile supported in
   this scheme can be found in Table 3.


Baize, Farrell, Parker    Document Expiration: 21 May 1996   [Page 36]


internet-draft                                       November 21, 1995

   asymmetric
   This OBJECT IDENTIFIER indicates the scheme described in section
   2.2.3. The targetKDSpart is not supplied and the targetPart
   contains an SPKM_REQ. The syntax of SPKM_REQ  is given in
   appendix A.3. The profile of SPKM_REQ that is supported in this
   scheme is given in Table 4.

   sesame-key-estb-alg
   This AlgorithmIdentifier identifies the key establishment
   algorithm value to be used within the key_estb_set field of an
   SPKM_REQ data element as the one defined by SESAME.

   This algorithm is used to establish a symmetric key for use by
   both the initiator and the target AEF as part of the context
   establishment. The corresponding key_estb_req field of the
   SPKM_REQ will be a BIT STRING the content of which is a DER
   encoding of the KeyEstablishmentData element defined later.

4.2.3    Hybrid inter-domain key distribution scheme data elements

   PublicTicket ::= SEQUENCE{
     krb5Ticket     [0]   Ticket,
     publicKeyBlock [1]   PublicKeyBlock}

   PublicKeyBlock ::= SEQUENCE{
     signedPKBPart  [0]   SignedPKBPart,
     signature      [1]   Signature OPTIONAL,
     certificate    [2]   Certificate OPTIONAL
   }

   SignedPKBPart ::= SEQUENCE{
     keyEstablishmentData [0]   KeyEstablishmentData,
     encryptionMethod     [1]   AlgorithmIdentifier
   OPTIONAL,
     issuingKDS           [2]   Identifier,
     uniqueNumber         [3]   UniqueNumber,
     validityTime         [4]   TimePeriods,
     creationTime         [5]   UTCTime
   }

   UniqueNumber ::= SEQUENCE{
     timeStamp      [0] UTCTime,
     random           [1] BIT STRING
   }

   krb5Ticket
   The Kerberos Ticket which contains the basic key. The encrypted
   part of this ticket is encrypted using the key found within the
   encryptedPlainKey field of the KeyEstablishmentData in the
   PublicKeyBlock.


Baize, Farrell, Parker    Document Expiration: 21 May 1996   [Page 37]


internet-draft                                       November 21, 1995

   publicKeyBlock
   Contains the key used to protect the krb5Ticket encrypted using
   the public key of the recipient and signed by the encryptor (i.e.
   the context initiator's KD-Server).

         signedPKBPart
         The part of the publicKeyBlock which is signed. The
         keyEstablishmentData field contains the
         KeyEstablishementData (defined in section 4.2.4), i.e. the
         actual encrypted temporary key (see section 2.2.3). The
         encryptionMethod indicates the algorithm used to encrypt
         the encryptedKey. The issuingKDS is the name of the KD-
         Server who produced the PublicTicket. The uniqueNumber is a
         value (containing a timestamp and a random number) which
         prevents replay of the PublicTicket. validityTime specifies
         the times for which the PublicTicket is valid. creationTime
         contains the time at which the PublicTicket was created.

         signature
         Contains the signature calculated by the issuingKDS on the
         signedPKBPart field.

         certificate
         If present, contains the public key certificate of the
         issuing KDS.

4.2.4    Key establishment data elements

   KeyEstablishmentData ::= SEQUENCE {
      encryptedPlainKey [0]   BIT STRING,-- encrypted PlainKey
      targetName        [1]   Identifier
   OPTIONAL,
      nameHashingAlg    [2]   AlgorithmIdentifier
   OPTIONAL
   }

   HashedNameInput ::= SEQUENCE {
      hniPlainKey       [0]   BIT STRING,-- same as plainKey
      hniIssuingKDS     [1]   Identifier
   }

   PlainKey ::= SEQUENCE {
     plainKey         [0]   BIT STRING,  -- The cleartext key
     hashedName       [1]   BIT STRING
   }

   encryptedPlainKey
   Contains the encrypted key. The BIT STRING contains the result of
   encrypting a PlainKey structure.

   targetName

Baize, Farrell, Parker    Document Expiration: 21 May 1996   [Page 38]


internet-draft                                       November 21, 1995

   If present, contains the name of the target application. This is
   necessary for some of the SESAME KD-schemes.

   nameHashingAlg
   Specifies the algorithm which is used to calculate the hashedName
   field of the PlainKey.

   hniPlainKey
   hniIssuingKDS
   Used as input to a hashing algorithm as a general means to
   prevent ciphertext stealing attacks.

   plainKey
   Contains the actual bits of the plaintext key which is to be
   established.

   hashedName
   A hash of the name of the encrypting KDS calculated using the
   plainkey and KDS name as input (within the HashedNameInput
   structure). The algorithm identified in nameHashingAlg is used to
   calculate this value.

   targetName
   If present, contains the name of the target for which the
   PublicTicket was originally produced. This may be different from
   the targetIdentity field of the initialContextToken if caching of
   PublicTickets has been implemented.

4.2.5    Kerberos Data elements

   The full ASN.1 for the Kerberos elements used by the SESAME GSS-
   API mechanism is given in appendix A.2. This section specifies
   the specific contents of the Kerberos Ticket's authorization_data
   field required by the SESAME GSS-API mechanism.

   Essentially this construct contains the PPID of the context
   initiator, as formally defined below.

   SESAME-AUTHORISATION-DATA-TYPE ::= INTEGER { SESAME-ADATA (65) }

   SESAME-AUTHORISATION-DATA ::= SEQUENCE {
     sesame-ad-type   [0] ENUMERATED  {
                            ppidType  (0)
                          },
     sesame-ad-value    [1] CHOICE  {
                            ppidValue [0]SecurityAttribute
                          }
   }

   ppidType
   Indicates the type of the SESAME authorisation data which is

Baize, Farrell, Parker    Document Expiration: 21 May 1996   [Page 39]


internet-draft                                       November 21, 1995

   included in the Ticket

   ppidValue
   This value is used in the ppQualification PAC protection method
   as defined above

4.2.6    Profiling of KD-schemes

   The following tables provide profiling information for the data
   elements defined above and in appendices A.1 and A.2. The tables
   indicate which optional fields must be present for each of the KD-
   Schemes and indicate the values which are required to be present
   in all fields.

4.2.6.1  Profile of Ticket as used in symmIntradomain scheme

    Field                 Value/Constraint
    -----                 ----------------
    tkt-vno               5
    realm                 ticket issuer's domain name in Kerberos realm
                          name form
    sname                 target application name including the realm of
                          the target
    - EncTicketPart       encrypted with long term key of target AEF
       -- flags           only bits 6, 10 and 11 can be meaningful in
                          the context of the SESAME mechanism, the rest
                          are ignored
       -- key             the basic key
       -- crealm          initiator domain name in Kerberos realm name
                          form
       -- cname           principal name of the initiator (in the case
                          of delegation the cname will be that of the
                          delegate)
       -- transited       not used
       -- authtime        the time at which the initiator was
                          authenticated
       -- starttime       not used
       -- endtime         the time at which the ticket becomes invalid
       -- renew-till      not used
       -- caddr           not used
       -- authorization-  contains the PPID corresponding to cname
          data

             Table 2 - Kerberos ticket fields supported

4.2.6.2  Profile of PublicTicket as used in hybridInterdomain scheme

     Field                  Value/Constraint
     -----                  ----------------
     krb5Ticket
     - tkt-vno              5

Baize, Farrell, Parker    Document Expiration: 21 May 1996   [Page 40]


internet-draft                                       November 21, 1995

     - realm                initiator domain name in Kerberos realm name
                            form
     - sname                target application name including the realm
                            of the target
     -- EncTicketPart       encrypted with temporary key (which is in
                            turn encrypted within the
                            keyEstablishmentData field)
     --- flags              only bits 6, 10 and 11 can be meaningful in
                            the context of the SESAME mechanism, the
                            rest are ignored
     --- key                the basic key
     --- crealm             initiator domain name in Kerberos realm name
                            form
     --- cname              principal name of the initiator (in the case
                            of delegation the cname will be that of the
                            delegate)
     --- transited          not used
     --- authtime           the time at which the initiator was
                            authenticated
     --- starttime          not used
     --- endtime            the time at which the ticket becomes invalid
     --- renew-till         not used
     --- caddr              not used
     --- authorization-     contains the PPID corresponding to cname
         data
     publicKeyBlock
      - signedPKBPart
       -- encryptedKey      KeyEstablishmentData structure
       -- encryptionMethod  sesame-key-estb-alg
       -- issuingKDS        X.500 name of initiator's KDS (the signer)
       -- uniqueNumber      creation time of publicKeyBlock plus a
                            random bit string
       -- validityTime      only one period allowed
       -- creationTime      creation time of publicKeyBlock
      - signature           contains all the signing information as well
                            as the actual signature bits
      - certificate         optional

               Table 3 - PublicTicket fields supported

 4.2.6.3  Profile of SPKM_REQ as used in asymmetric scheme


     Field                  Value/Constraint
     -----                  ----------------
     requestToken
      - tok_id              not used - fixed value of `0'
      - context_id          not used - fixed value of bit string
                            containing one zero bit
      - pvno                not used - fixed value of bit string
                            containing one zero bit

Baize, Farrell, Parker    Document Expiration: 21 May 1996   [Page 41]


internet-draft                                       November 21, 1995

      - timestamp           creation time of SPKM_REQ - required
      - randSrc             random bit string
      - targ_name           X.500 Name of target AEF
      - src_name            X.500 Name of initiator
      - req_data
       -- channelId         not used - octet string of length one value
                            `00'H
       -- seq_number        missing
       -- options           not used - all bits set to zero
       -- conf_alg          not used - use NULL CHOICE
       -- intg_alg          not used - use a SEQUENCE OF with zero
                            elements
      - validity            mandatory
      - key_estb_set        only one element supplied containing sesame-
                            -key-estb-alg
     - key_estb_req         contains KeyEstablishmentData with
                            targetApplication field missing
      - key_src_bind        missing
     req_integrity          sig_integ mandatory
     certif_data            only userCertificate field supported
     auth_data              missing

                 Table 4 - SPKM_REQ fields supported

4.3 Dialogue Key Block

   Dialogue Key Block constructs are used to specify how the
   integrity dialogue key and confidentiality dialogue key should be
   derived from the basic key, and specify the cryptographic
   algorithms with which the keys should be used. Dialogue keys are
   explained in Part 1. The syntax is as follows:

   DialogueKeyBlock   ::=   SEQUENCE {
      integKeySeed            [0]   SeedValue,
      confKeySeed             [1]   SeedValue,
      integKeyDerivationInfo  [2]   KeyDerivationInfo   OPTIONAL,
      confKeyDerivationInfo   [3]   KeyDerivationInfo   OPTIONAL,
      integDKuseInfo          [4]   DKuseInfo         OPTIONAL,
      confDKuseInfo           [5]   DKuseInfo         OPTIONAL
   }

   SeedValue  ::= SEQUENCE {
      timeStamp     [0]   UTCTime                    OPTIONAL,
      random        [1]   BIT STRING
   }

   KeyDerivationInfo::= SEQUENCE {
      owfId         [0]   AlgorithmIdentifier,
      keySize       [1]   INTEGER
   }


Baize, Farrell, Parker    Document Expiration: 21 May 1996   [Page 42]


internet-draft                                       November 21, 1995

   DKuseInfo    ::= SEQUENCE {
      useAlgId        [0]   AlgorithmIdentifier,
      useHashAlgId    [1]   AlgorithmIdentifier
   OPTIONAL
   }

   integKeySeed
   A random number, optionally concatenated with a time value to
   ensure uniqueness, used as input to the one way function
   specified in integKeyDerivationInfo.

   confKeySeed
   A random number, optionally concatenated with a time value to
   ensure uniqueness, used as input to the one way function
   specified in confKeyDerivationInfo.

   integKeyDerivationInfo
   Key derivation information for the integrity dialogue key, as
   follows:

         owfId
         The one way algorithm which takes the basic key XOR the
         seed as input, resulting in the integrity dialogue key.

         keySize
         The size of the key in bits. If the algorithm identified by
         owfId produces a larger key, it is reduced by masking to
         this length, losing its most significant end.

   confKeyDerivationInfo
   Key derivation information for the confidentiality dialogue key.
   The fields in this construct have the same meanings as defined
   above for the integrity dialogue key.

   Note:
   It may be insecure to specify the same derivation algorithms and
   seeds for both integrity and confidentiality dialogue keys,
   particularly if they are to be of different lengths.

   integDKuseInfo
   Information describing how the integrity dialogue key is to be
   used, as follows:

         useAlgId
         The symmetric or asymmetric reversible encryption algorithm
         with which the integrity dialogue key is to be used.

         useHashAlgId
         The one way function with which the integrity dialogue key
         is to be used. It is the hash produced by this algorithm on
         the data to be protected which is encrypted using useAlgId.

Baize, Farrell, Parker    Document Expiration: 21 May 1996   [Page 43]


internet-draft                                       November 21, 1995


   confDKuseInfo
   Information describing how the confidentiality key is to be used.
   The useHashAlgId construct is not used here.

4.4 Attribute Definitions

   Note: the types given for the attributes below use the type
   Identifier whereas the SecurityAttribute type is actually used in
   the PAC. The mapping from Identifier to SecurityAttribute is TBS
   (due to time constraints on the production of this I-D).

4.4.1    Privilege attributes

   Privileges are defined under the OBJECT IDENTIFIER:

   privilege-attributeOBJECT IDENTIFIER ::=
      {   generic-sesame-oids     privilege-attribute(4) }
     -- OID below which privilege attributes are defined

4.4.1.1  Access Identity

   The access identity represents the principal's identity to be
   used for access control purposes.

   The type of this attribute is :

   access-identity-privilege ::= OBJECT IDENTIFIER
        { privilege-attribute 2 }

   Its syntax in the PAC is:

   AccessPrivilegeValueSyntax ::= Identifier

4.4.1.2  Group

   The group represents a characteristic common to several
   principals. A security context may contain more than one group
   for a given principal.

   The type of this attribute is:

   group-privilege ::= OBJECT IDENTIFIER { privilege-attribute 4 }

   Its syntax in the PAC is:

   GroupPrivilegeValueSyntax ::= SEQUENCE OF Identifier

4.4.1.3  Primary group

   The primary group represents a unique group to which a principal

Baize, Farrell, Parker    Document Expiration: 21 May 1996   [Page 44]


internet-draft                                       November 21, 1995

   belongs. A security context must not contain more than one
   primary group for a given principal.

   The type of this attribute is:

   primary-group-privilege ::= OBJECT IDENTIFIER { privilege-
   attribute 3 }

   Its syntax in the PAC is:

   PrimaryGroupValueSyntax ::= Identifier

4.4.1.4  Role attribute

   The role attribute represents the principal's role. There may be
   a one to one mapping between a role name and a role attribute.

   The type of this attribute is:

   role-privilege ::= OBJECT IDENTIFIER { privilege-attribute 1 }

   Its syntax in the PAC is:

   RolePrivilegeValueSyntax ::= Identifier

4.4.2    Miscellaneous attributes

   Miscellaneous attributes are defined under the OBJECT IDENTIFIER:

   misc-attribute   OBJECT IDENTIFIER ::=
      {   generic-sesame-oids   misc-attribute(3) }
     -- OID below which miscellaneous attributes are defined

4.4.2.1  Audit Identity

   The access identity represents the principal's identity to be
   used for audit purposes.

   The type of this attribute is:

   audit-id-misc ::= OBJECT IDENTIFIER { misc-attribute 2 }

   Its syntax in the PAC is:

   AuditIdValueSyntax ::= Identifier

4.4.3    Qualifier Attributes

   When a targetQualifiication or delegateTargetQualification method
   is present in the PAC, the syntax used for the method parameters
   is securityAttribute. In this section we define the OIDs and

Baize, Farrell, Parker    Document Expiration: 21 May 1996   [Page 45]


internet-draft                                       November 21, 1995

   attribute value syntaxes for these methods.

   qualifier-attribute  OBJECT IDENTIFIER ::=
      {   generic-sesame-oids   qualifier-attribute (4) }
     -- OID below which qualifier attributes are defined


4.4.3.1  Target Names

   Within a PAC protection method a target name is indicated using
   the OID:

   target-name-qualifier OBJECT IDENTIFIER ::= { qualifier-attribute
   1 }

   It's syntax in the PAC is:

   TargetNameValueSyntax ::= Identifier

4.4.3.2  Application Trust Groups

   Within a PAC protection method an application trust group name is
   indicated using the OID:

   trust-group-qualifier OBJECT IDENTIFIER ::= { qualifier-attribute 2 }

   It's syntax in the PAC is:

   TrustGroupValueSyntax ::= Identifier

   The universal application trust group (see section 2) is
   specified by using the printableName field of the Identifier
   where the value is an empty string.

5.  ALGORITHMS AND CIPHERTEXT FORMATS

   Cryptographic and hashing algorithms are used for various
   purposes within the SESAME GSS-API mechanism. This section
   categorises these algorithms according to usage so that context
   initiators and acceptors can more easily determine if they have
   the cryptographic support required to allow inter-operation. The
   categorisation is then refined into cryptographic profiles that
   can be incorporated into specific mechanism identifiers for the
   purpose of mechanism negotiation.

   The table below summarises the different uses to which algorithms
   are put within the SESAME GSS-API mechanism.

  Use            Description of use       Type of Algorithm
  Reference
  2              PAC protection           OWF + asymmetric

Baize, Farrell, Parker    Document Expiration: 21 May 1996   [Page 46]


internet-draft                                       November 21, 1995

                 using signature         signature
  3              basic key usage          symmetric
                                         confidentiality and
                                         integrity
  4              integrity dialogue       OWF
                 key derivation
  5              integrity dialogue       symmetric integrity
                 key usage
  6              CA public keys           OWF + asymmetric
                                         signature
  7              encryption using         symmetric
                 shared long term        confidentiality.
                 symmetric key
  8              name hash to             OWF
                 prevent ciphertext
                 stealing
  9              asymmetric basic         asymmetric encryption
                 key distribution        and OWF + signature
  10             key estab. within        (fixed value)
                 SPKM_REQ
  11             confidentiality          OWF
                 dialogue key
                 derivation
  12             confidentiality          symmetric
                 dialogue key use        confidentiality

                Table 5 - Summary of algorithm uses:

   The algorithms can now be further categorised into broader
   classes as follows:

   Class 1: symmetric for security of mechanism:
               Uses 3, 5, 7
   Class 2: all OWFs:
               Uses 2, 4, 6, 8, 11
   Class 3: internal mechanism asymmetric, encrypting:
               Use 9
   Class 4: internal mechanism asymmetric, non-encrypting:
               Use 2
   Class 5: CA's asymmetric non-encrypting:
               Use 6
   Class 6: Data confidentiality, symmetric:
               Use  12

   Use 10 is a fixed value, and does not contribute to mechanism use
   options. The fixed value for this has already been defined above.

   Based on these classes, the following cryptographic algorithm
   usage profiles are defined. Other profiles are possible and can
   be defined as required. Note that symmetric algorithm key sizes
   are included in this profiling, thus DES/64 indicates DES with a

Baize, Farrell, Parker    Document Expiration: 21 May 1996   [Page 47]


internet-draft                                       November 21, 1995

   64 bit key.

             Profile 1:  Profile 2: Profile 3:  Profile 5:
             Full        No user    Exportable  Defaulted
                         data
                         Confidenti
                         ality
    Class 1  DES/64      DES/64     RC4/128     separately
                                                agreed
                                                default
    Class 2  MD5         MD5        MD5         separately
                                                agreed
                                                default
    Class 3  RSA         RSA        RSA         separately
                                                agreed
                                                default
    Classes  RSA         RSA        RSA         separately
    4                                           agreed
    and 5                                       default
    Class 6  DES/64      None       RC4/40      separately
                                                agreed
                                                default
                    Table 6 - Algorithm profiles

   Where:

   -  Profile 1 provides full security, using standard cryptographic
       algorithms with commonly accepted key sizes.
   -  Profile 2 is the same but without supporting any
       confidentiality of user data.
   -  Profile 3 is exportable under many countries' legislations,
   -  Profile 5 uses algorithms identified by a separately specified
       default. It is intended for use by organisations who wish to
       use their own proprietary or government algorithms by separate
       agreement or negotiation.

   The next section shows how these algorithm profiles can be used
   to extend the architectural key distribution schemes to form
   negotiable SESAME mechanism choices.

6.  SESAME MECHANISM NEGOTIATION

   Preceding sections have separately defined the alternatives
   allowed by the generic SESAME mechanism in terms of key
   distribution schemes and the use of cryptographic and hash
   algorithms within the data elements.

   This section brings these together by defining the specific
   SESAME mechanism identifiers which correspond to each combination
   of the available options under these headings. These specific
   mechanism identifiers are intended to be negotiable using a

Baize, Farrell, Parker    Document Expiration: 21 May 1996   [Page 48]


internet-draft                                       November 21, 1995

   generic GSS-API negotiation scheme (like [SNEGO]).

   The approach is to use the  key distribution schemes to form
   broad architectural mechanism options, as follows (more options
   are defined by ECMA, hence the numbering):

   Architectural  Description of         Key Distribution
   Mechanism      Mechanism Option       Scheme(s)
   Number
   2              Symmetric key          symmIntradomain
                  distribution
   3              Symmetric initiator    symmIntradomain;
                  and target;            hybridInterdomain
                  Asymmetric KD-
                  Servers;
   6              Asymmetric Initiator   asymmetric
                  and Target

            Table 7 - Key Distribution Mechanism Options

   Each of the security mechanism options described above represents
   a key distribution scheme.

   Generic GSS-API mechanism negotiation will be carried out on the
   basis of the generic SESAME mechanism OBJECT IDENTIFIER
   concatenated with an architectural mechanism number from table 7,
   and an algorithm profile reference number from table 6. Thus the
   form of a negotiable SESAME mechanism is:

           SESAME Mechanism OID ,   Y    ,   Z
                               ^       ^
                               |       |
                               |       +-- algorithm
                               |           profile
                               |
                               +-- architectural option

   Thus a SESAME mechanism using a fully symmetric key distribution
   scheme and an exportable cryptographic algorithm profile would
   have an OBJECT IDENTIFIER of:

        { generic_sesame_mech  (2)  (3) }

   A SESAME mechanism using a fully asymmetric initiator and target
   architectural scheme, and an algorithm profile not supporting
   user data confidentiality would have an OBJECT IDENTIFIER of:

        { generic-sesame-mech  (6)  (2) }

   Not all combinations of key distribution scheme and algorithm
   profile are meaningful, however, but those that are, are intended

Baize, Farrell, Parker    Document Expiration: 21 May 1996   [Page 49]


internet-draft                                       November 21, 1995

   to be negotiable using a generic GSS-API negotiation scheme such
   as [SNEGO].

   Where information is returned from the target to the initiator as
   a result of negotiation then for the SESAME mechanism the
   information should contain the public key certificates required
   for the initiator to be able to use the selected KD-Scheme. For
   example, if the asymmetric KD-Scheme is to be used the target
   should return to the initiator the public key certificate of the
   targetAEF (containing the target's own name in the extensions
   field). The syntax of the mechanism specific information is the
   `Certificates' ASN.1 type defined in the AuthenticationFramework.
   (To allow multiple certificates to be passed to the initiator.)

7.  NAME TYPES

   Because [Kerberos] does not support Directory Names (DNs), SESAME
   uses two distinct naming conventions, Kerberos and X.500.

7.1 Kerberos naming

   SESAME uses the Kerberos V5 Authentication Server protocol for
   password based authentication, so SESAME principals are given
   Kerberos principal names. Moreover, the SESAME security domain is
   equivalent to a Kerberos realm, so Kerberos realm names are used
   to identify SESAME security domains. In SESAME, an entity that
   uses the normal Kerberos V5 authentication via a password is
   given a printable Kerberos principal name of the form :

                 <principal_name>@<realm_name>
   Notes:
   1. Components of a name can be separated by `/`.
   2. The separator `@` signifies that the remainder of the string
   following the `@` is to be interpreted as a realm identifier. If
   no `@` is encountered, the name is interpreted in the context of
   the local realm. Once an `@` is encountered, a non-null realm
   name, with no embedded `/` separators, must follow. The `\`
   character is used to quote the immediately-following character.

   SESAME reserves two specific Kerberos principal names for its own
   use:

   -  for the SESAME Security Server (containing the AS, PAS and
       KDS):

                 krbtgt/<realm_name>@<realm_name>

   -  for the SESAME PVF :

                 pvf/<host_name>/<realm_name>@<realm_name>


Baize, Farrell, Parker    Document Expiration: 21 May 1996   [Page 50]


internet-draft                                       November 21, 1995

   The realm_name in each of these constructs is repeated for
   compatibility with Kerberos.

   Note that a <host_name> or a <realm_name> might take the form of
   an Internet Protocol domain name, and so a name like:

                 pvf/mybox.bull.fr/sesame.bull.fr@sesame.bull.fr

   is a valid principal name for a SESAME PVF.

   When invoking gss_import_name, a Kerberos principal name type can
   be identified using either gss_ses_krb5_oid or
   GSS_KRB5_NT_PRINCIPAL_NAME symbolic names. A Kerberos service
   name type can be identified using either gss_ses_krb5_oid or
   GSS_KRB5_NT_HOSTBASED_ SERVICE_NAME symbolic names.

7.2 Directory Naming

   As described elsewhere, SESAME uses public key technology
   supported by Directory Certificates, so for this purpose SESAME
   entities are given DNs. Such names are built from components
   separated  by a semicolon. The standardised keywords supported by
   SESAME are :

                 CN (common-name).
                 S  (surname),
                 OU (organisational-unit),
                 O  (organisation),
                 C  (country),

   So an example of a DN supported at SESAME is:

                 CN=Martin;OU=sesame;O=bull;C=fr

   SESAME defines a set of reserved common-name parts for DNs for
   the core SESAME security components, as follows:

   the PAS:         CN=SesamePAS.<realm_name>[;...]
   the AS:          CN=SesameAS.<realm_name>[;...]
   the KDS:         CN=SesameKDS.<realm_name>[;...]
   the PVF:         CN=pvf.<host_name>[;...]
   the security domain:  CN=SesameDomain.<realm_name>[;...]
                    where <realm_name> is the name of the Kerberos
                     realm to which the entity belongs.

   Note that there is no generic rule for mapping the Directory Name
   of a SESAME entity to its Kerberos principal name, so SESAME
   provides an explicit mapping in a principal's Directory
   Certificate, using the extensions field of the extended Directory
   Certificate syntax (version 3) to carry the principal's Kerberos
   name.

Baize, Farrell, Parker    Document Expiration: 21 May 1996   [Page 51]


internet-draft                                       November 21, 1995


   Note also that in the case of a PVF's Directory Certificate, the
   names of the applications supported by the PVF are also held in
   this field, preceded by the Kerberos principal name of the PVF
   itself. In the absence of such a certificate (i.e. if the PVF
   does not have a key pair of its own) the list of application
   names can be held (e.g. in a file) in the KDS.

   In SESAME the syntax of the Login Name is imported from the
   Kerberos Version 5 GSS-API Mechanism. This form of name is
   referred to using the symbolic name: GSS_KRB5_NT_PRINCIPAL.
   Syntax details are given in [KRB5GSS].When a principal possesses
   a private key for authentication, the login name is also stored
   in an extension field of the principal's Directory Certificate so
   that it can be linked to the principal's Distinguished Name.

8.  ERROR CODES

   To be supplied.

9.  SECURITY CONSIDERATIONS

   Security issues are discussed throughout this memo.

10. REFERENCES

   ECMA-219       ECMA-219, Authentication and Privilege Attribute
                   Application with related key distribution
                   functions
   GSS-API        1.  Internet RFC 1508 Generic Security Service
                   API
                       (J. Linn, September 1993)
                  2.  X/Open P308 Generic Security Service API
                   (GSS-API)
                       Base
                  3.  Internet RFC 1509 "Generic Security Service
                   API:
                       C-Bindings"
   Kerberos       Internet RFC 1510 The Kerberos Network
                   Authentication Service (V5) (J. Kohl and C.
                   Neumann, September 1993)
   ISO/IEC 9594-8 ISO/IEC 9594-8, Information Processing Systems -
                   Open Systems Interconnection - The Directory -
                   Part 8: Authentication Framework (X.509)
   KERB5GSS       draft-ietf-cat-kerb5gss-03 The Kerberos Version 5
                   GSS-API Mechanism (J. Linn, September 1995)
   XGSSAPI        draft-ietf-cat-xgssapi-sesame-00: Extended
                   Generic Security Service APIs: XGSS-APIs (Denis
                   Pinkas and Piers McMahon, November 1995)
   SESOV          SESAME Overview, Version 4, (Tom Parker and Denis
                   Pinkas, December 1995)

Baize, Farrell, Parker    Document Expiration: 21 May 1996   [Page 52]


internet-draft                                       November 21, 1995

   SPKM           draft-ietf-cat-spkmgss-04: The Simple Public-Key
                   GSS-API Mechanism (C. Adams, May 1995)
   SNEGO          draft-ietf-cat-snego-00 Simple GSS-API
                   Negotiation Mechanism (Eric Baize and Denis
                   Pinkas, July 1995)


11. AUTHOR'S ADDRESSES

   Eric Baize,
   BULL S.A.,
   Rue Jean Jaures,
   78340 LES CLAYES SOUS BOIS,
   FRANCE.

   email: E.Baize@frcl.bull.fr

   Stephen Farrell
   Software and Systems Engineering Ltd.
   Fitzwilliam Court,
   Dublin 2,
   IRELAND.

   email: Stephen.Farrell@sse.ie

   Tom Parker, ICL,
   Eskdale Road,
   Winnersh, Wokingham,
   Berkshire, UK RG11 5TT

   email: t.a.parker@win0199.wins.icl.co.uk

APPENDIX A: ASN.1 MODULE DEFINITIONS

A.1 SESAME ASN.1 Definitions

   SESAME-gss-api-types  { tbs }

   DEFINITIONS ::=

   BEGIN

   -- exports everything

   IMPORTS

     Name
      FROM  InformationFramework
            {joint-iso-ccitt(2) ds(5) module(1)
            informationFramework(1) }


Baize, Farrell, Parker    Document Expiration: 21 May 1996   [Page 53]


internet-draft                                       November 21, 1995

     Certificate, AlgorithmIdentifier, Validity,
     CertificationPath
      FROM  AuthenticationFramework
            {joint-iso-ccitt(2) ds(5) module(1)
            authenticationFramework(7) }

     HostAddress, Ticket
      FROM SESAME-Kerberos-Definitions { tbs }

     SPKM-REQ
      FROM SESAME-SPKM-Definitions { tbs };

   -- OBJECT IDENTIFIERS

   access-identity-privilege ::= OBJECT IDENTIFIER
        { privilege-attribute 2 }

   audit-id-misc ::= OBJECT IDENTIFIER { misc-attribute 2 }

   generic-sesame-mech ::=OBJECT IDENTIFIER { tbs }

   generic-sesame-oids ::= OBJECT IDENTIFIER { tbs }
      -- top of the SESAME types arc

   group-privilege ::= OBJECT IDENTIFIER { privilege-attribute 4 }

   kd-schemes   OBJECT IDENTIFIER ::= { generic-sesame-oids tbs }
      -- arc for SESAME key distribution schemes
   symmIntradomain      OBJECT IDENTIFIER ::= {kd-schemes 1}
   hybridInterdomain    OBJECT IDENTIFIER ::= {kd-schemes 3}
   asymmetric             OBJECT IDENTIFIER ::= {kd-schemes 6}
      -- supported key distribution schemes

   misc-attribute   OBJECT IDENTIFIER ::=
      {   generic-sesame-oids   misc-attribute(3) }
     -- OID below which miscellaneous attributes are defined

   primary-group-privilege ::= OBJECT IDENTIFIER{privilege-attribute 3}

   privilege-attributeOBJECT IDENTIFIER ::=

      {   generic-sesame-oids     privilege-attribute(4) }
     -- OID below which privilege attributes are defined

   qualifier-attribute  OBJECT IDENTIFIER ::=
      {   generic-sesame-oids   qualifier-attribute (4) }
     -- OID below which qualifier attributes are defined

   role-privilege ::= OBJECT IDENTIFIER { privilege-attribute 1 }

   sesame-key-estb-alg AlgorithmIdentifier ::= {kd-schemes, NULL }

Baize, Farrell, Parker    Document Expiration: 21 May 1996   [Page 54]


internet-draft                                       November 21, 1995

      -- indicates a SESAME key establishment structure within
      -- an SPKM_REQ structure

   target-name-qualifier OBJECT IDENTIFIER ::= { qualifier-attribute 1 }

   trust-group-qualifier OBJECT IDENTIFIER ::= { qualifier-attribute 2 }

   -- Types in alphabetical order

   AccessPrivilegeValueSyntax ::= Identifier

   AuditIdVlaueSyntax ::= Identifier

   CDTContents ::= SEQUENCE {
     tokenType    [0]   OCTET STRING VALUE X'0301',
     SAId       [1]   OCTET STRING,
     utcTime      [2]   UTCTime OPTIONAL,
     usec       [3]   INTEGER OPTIONAL,
     seq-number   [4]   INTEGER OPTIONAL,
   }

   CertandECV ::=   SEQUENCE {
     certificate      [0]   GeneralisedCertificate,
     ecv              [1]   ECV,             OPTIONAL}
            -- ECV is defined in later

   CertificateBody ::= CHOICE{
     encryptedBody      [0]   BIT STRING,
     normalBody       [1]   SEQUENCE{
                              commonContents  [0] CommonContents,
                              specificContents[1] SpecificContents
                            }
   }

   CertificateId ::=SEQUENCE {
     issuerDomain   [0] Identifier                       OPTIONAL,
     issuerIdentity [1] Identifier,
     serialNumber   [2] INTEGER
   }
            -- serialNumber is the same as in [ISO/IEC 9594-8]

   CheckValue ::= CHOICE{
     signature      [0]   Signature
        -- only signature supported here
   }

   CommonContents ::= SEQUENCE{

     comConSyntaxVersion  [0]   INTEGER { version1 (1) }DEFAULT 1,
     issuerDomain       [1]   Identifier             OPTIONAL,
     issuerIdentity     [2]   Identifier,

Baize, Farrell, Parker    Document Expiration: 21 May 1996   [Page 55]


internet-draft                                       November 21, 1995

     serialNumber       [3]   INTEGER,
     creationTime       [4]   UTCTime                OPTIONAL,
     validity           [5]   Validity,
     algId              [6]   AlgorithmIdentifier,
     hashAlgId            [7]   AlgorithmIdentifier    OPTIONAL
   }

   ContextDeleteToken ::=  SEQUENCE {
     cdtContents    [0]   CDTContents,
     cdtSeal        [1]   Seal
                          -- seal over cdtContents, encrypted
                          -- under the Integrity Dialogue Key
                          -- contains only the sealValue field
   }

   CValues ::= SEQUENCE OF SEQUENCE {
     index          [0]   INTEGER,
     value          [1]   BIT STRING
   }

   DialogueKeyBlock   ::=   SEQUENCE {
      integKeySeed            [0]   SeedValue,
      confKeySeed             [1]   SeedValue,
      integKeyDerivationInfo  [2]   KeyDerivationInfo   OPTIONAL,
      confKeyDerivationInfo   [3]   KeyDerivationInfo   OPTIONAL,
      integDKuseInfo          [4]   DKuseInfo         OPTIONAL,
      confDKuseInfo           [5]   DKuseInfo         OPTIONAL
   }

   DKuseInfo    ::= SEQUENCE {
      useAlgId        [0]   AlgorithmIdentifier,
      useHashAlgId    [1]   AlgorithmIdentifier            OPTIONAL
   }

   ECV ::= SEQUENCE {
     crypAlgIdentifier  [0]   AlgorithmIdentifier      OPTIONAL,
     cValues            [1]   CHOICE {
                              encryptedCvalueList  [0] BIT STRING,
                              individualCvalues        [1] CValues
                            }
   }

   ErrorArgument ::= ENUMERATED {
     gss_ses_s_sg_server_sec_assoc_open              (1),
     gss_ses_s_sg_incomp_cert_syntax                 (2),
     gss_ses_s_sg_bad_cert_attributes                (3),
     gss_ses_s_sg_inval_time_for_attrib              (4),
     gss_ses_s_sg_pac_restrictions_prob              (5),
     gss_ses_s_sg_issuer_problem                     (6),
     gss_ses_s_sg_cert_time_too_early                (7),
     gss_ses_s_sg_cert_time_expired                  (8),

Baize, Farrell, Parker    Document Expiration: 21 May 1996   [Page 56]


internet-draft                                       November 21, 1995

     gss_ses_s_sg_invalid_cert_prot                  (9),
     gss_ses_s_sg_revoked_cert                       (10),

     gss_ses_s_sg_key_constr_not_supp                (11),
     gss_ses_s_sg_init_kd_server_ unknown            (12),
     gss_ses_s_sg_init_unknown                       (13),
     gss_ses_s_sg_alg_problem_in_dialogue_key_block    (14),
     gss_ses_s_sg_no_basic_key_for_dialogue_key_block   (15),
     gss_ses_s_sg_key_distrib_prob                   (16),
     gss_ses_s_sg_invalid_user_cert_in_key_block       (17),
     gss_ses_s_sg_unspecified                        (18),
     gss_ses_s_g_unavail_qop                         (19),
     gss_ses_s_sg_invalid_token_format               (20)
   }

   ErrorToken ::=   {
      tokenType     [0]   OCTET STRING VALUE X'0400',
      etContents    [1]   ErrorArgument,
   }

   GeneralisedCertificate ::= SEQUENCE{
     certificateBody    [0]   CertificateBody,
     checkValue       [1]   CheckValue}

   GroupPrivilegeValueSyntax ::= SEQUENCE OF Identifier

   HashedNameInput ::= SEQUENCE {
      hniPlainKey       [0]   BIT STRING,-- the same value as plainKey
      hniIssuingKDS     [1]   Identifier
   }

   ICTContents ::= SEQUENCE {
     tokenId              [0]   INTEGER, -- shall contain X'0100'
     SAId               [1]   OCTET STRING,
     targetAEFPart        [2]   TargetAEFPart,
     targetAEFPartSeal    [3]   Seal,
     contextFlags       [4]   BIT STRING {
                              delegation         (0),
                              mutual-auth        (1),
                              replay-detect       (2),
                              sequence           (3),
                              conf-avail         (4),
                              integ-avail        (5)
                              }
     utcTime              [5]   UTCTime      OPTIONAL,
     usec               [6]   INTEGER    OPTIONAL,
     seq-number           [7]   INTEGER      OPTIONAL,
     initiatorAddress     [8]   HostAddress   OPTIONAL,
     targetAddress        [9]   HostAddress   OPTIONAL
        -- imported from [Kerberos] and used as channel bindings
   }

Baize, Farrell, Parker    Document Expiration: 21 May 1996   [Page 57]


internet-draft                                       November 21, 1995


   Identifier ::= CHOICE{
     objectId         [0]   OBJECT IDENTIFIER,
     directoryName      [1]   Name,
            -- imported from the Directory Standard
     printableName      [2]   PrintableString,
     octets           [3]   OCTET STRING,
     intVal           [4]   INTEGER,

     bits             [5]   BIT STRING,
     pairedName       [6]   SEQUENCE{
                              printableName   [0] PrintableString,
                              uniqueName     [1] OCTET STRING
                            }
   }

   InitialContextToken ::=  SEQUENCE{
     ictContents    [0]   ICTContents,
     ictSeal        [1]   Seal
   }

   KeyDerivationInfo::= SEQUENCE {
      owfId         [0]   AlgorithmIdentifier,
      keySize       [1]   INTEGER
   }

   KeyEstablishmentData ::= SEQUENCE {
      encryptedPlainKey [0]   BIT STRING,-- encrypted PlainKey
      targetName        [1]   Identifier                 OPTIONAL,
      nameHashingAlg    [2]   AlgorithmIdentifier          OPTIONAL
   }

   Method ::= SEQUENCE{
     methodId         [0] MethodId,
     methodParams     [1] SEQUENCE OF Mparm               OPTIONAL
   }

   MethodGroup ::= SEQUENCE OF Method

   MethodId ::= CHOICE{
     predefinedMethod [0] ENUMERATED {
                                controlProtectionValues     (1),
                                ppQualification                (2),
                                targetQualification        (3),
                                delegateTargetQualification  (4)
                              }
   }

      MICToken  ::=   PMToken

   Mparm ::= CHOICE{

Baize, Farrell, Parker    Document Expiration: 21 May 1996   [Page 58]


internet-draft                                       November 21, 1995

     pValue               [0]   PValue,
     securityAttribute      [1]   SecurityAttribute
   }

   PACSpecificContents ::= SEQUENCE{
     pacSyntaxVersion [0]   INTEGER{  version1 (1)}        DEFAULT 1,
     protectionMethods  [2]   SEQUENCE OF MethodGroup      OPTIONAL,
     pacType            [4]   ENUMERATED{
                                  primaryPrincipal     (1),
                                  temperedSecPrincipal  (2),
                                  untemperedSecPrincipal(3)
                            }                            DEFAULT 3,
     privileges       [5]   SEQUENCE OF PrivilegeAttribute,
     restrictions     [6]   SEQUENCE OF Restriction        OPTIONAL,

     miscellaneousAtts  [7]   SEQUENCE OF SecurityAttribute OPTIONAL,
     timePeriods        [8]   TimePeriods                OPTIONAL
   }

   PlainKey ::= SEQUENCE {
     plainKey         [0]   BIT STRING,      -- The cleartext key
     hashedName       [1]   BIT STRING
   }

   PMTContents ::= SEQUENCE {
     tokenId              [0]   INTEGER, -- shall contain X'0101'
     SAId               [1]   OCTET STRING,
     seq-number           [2]   INTEGER                  OPTIONAL,
     userData           [3]   CHOICE {
                                plaintextBIT STRING,
                                ciphertext    OCTET STRING
                        }                            OPTIONAL,
     directionIndicator [4]   BOOLEAN                OPTIONAL
   }

   PMToken ::=  SEQUENCE{
     pmtContents    [0]   PMTContents,
     pmtSeal        [1]   Seal
        -- seal over the pmtContents being protected
   }

   PrimaryGroupValueSyntax ::= Identifier

   PrivilegeAttribute ::= SecurityAttribute

   PublicKeyBlock ::= SEQUENCE{
     signedPKBPart  [0]   SignedPKBPart,
     signature      [1]   Signature OPTIONAL,
     certificate    [2]   Certificate OPTIONAL
   }


Baize, Farrell, Parker    Document Expiration: 21 May 1996   [Page 59]


internet-draft                                       November 21, 1995

   PublicTicket ::= SEQUENCE{
     krb5Ticket     [0]   Ticket,
     publicKeyBlock [1]   PublicKeyBlock}

   PValue ::= SEQUENCE{
     pv                   [0]   BIT STRING,
     algorithmIdentifier    [1]   AlgorithmIdentifier           OPTIONAL
   }

   Restriction ::= SEQUENCE {
     howDefined [0] CHOICE {
                hashedExternal  [0] BIT STRING, -- the hash value
                signedExternal  [1] BIT STRING, -- the public key
                certExternal    [2] CertificateId, -- user certificate
                included        [3] BIT STRING
                },
                                -- the actual restriction in a form
                                -- undefined here
     algId      [1] AlgorithmIdentifier              OPTIONAL,
                          -- either identifies the hash algorithm

                          -- or the public key algorithm
                          -- for choices 1 or 2 above.
     type       [2] ENUMERATED  {
                      mandatory (1),
                      optional    (2)}       DEFAULT mandatory,
     targets      [3] SEQUENCE OF SecurityAttribute    OPTIONAL
   }
                  -- applies to all targets if this is omitted

   RolePrivilegeValueSyntax ::= Identifier

   Seal ::= SEQUENCE{
     sealValue          [0]   BIT STRING,
     symmetricAlgId   [1]   AlgorithmIdentifier        OPTIONAL,
     hashAlgId          [2]   AlgorithmIdentifier      OPTIONAL,
     targetName       [3]   Identifier           OPTIONAL,
     keyId            [4]   INTEGER                  OPTIONAL
   }

   SecurityAttribute ::= SEQUENCE{
     attributeType    Identifier,
     attributeValue SET OF SEQUENCE {
                      definingAuthority  [0] Identifier    OPTIONAL,
                      securityValue      [1] SecurityValue
                    }
   }
      --  NOTE: SecurityAttribute is not tagged, for compatibility
      -- with the Directory Standard.

   SecurityValue ::= CHOICE{

Baize, Farrell, Parker    Document Expiration: 21 May 1996   [Page 60]


internet-draft                                       November 21, 1995

     directoryName      [0]   Name,
     printableName      [1]   PrintableString,
     octets           [2]   OCTET STRING,
     intVal           [3]   INTEGER,
     bits             [4]   BIT STRING,
     any                [5]   ANY -- defined by attributeType
   }

   SeedValue  ::= SEQUENCE {
      timeStamp     [0]   UTCTime                    OPTIONAL,
      random        [1]   BIT STRING
   }

   SESAME-AUTHORISATION-DATA ::= SEQUENCE {
     sesame-ad-type   [0] ENUMERATED  {
                            ppidType  (0)
                          },
     sesame-ad-value    [1] CHOICE  {
                            ppidValue [0]SecurityAttribute
                          }
   }

   SESAME-AUTHORISATION-DATA-TYPE ::= INTEGER { SESAME-ADATA (65) }

   Signature ::= SEQUENCE{
     signatureValue       [0]   BIT STRING,

     asymmetricAlgId        [1]   AlgorithmIdentifier       OPTIONAL,
     hashAlgId              [2]   AlgorithmIdentifier       OPTIONAL,
     issuerCAName         [3]   Identifier                OPTIONAL,
     caCertInformation      [4]   CHOICE {
            caCertSerialNumber    [0]    INTEGER,
            certificationPath     [1]    CertificationPath
     }                                                       OPTIONAL
   }
   --CertificationPath    is imported from [ISO/IEC 9594-8]

   SignedPKBPart ::= SEQUENCE{
     keyEstablishmentData [0]   KeyEstablishmentData,
     encryptionMethod     [1]   AlgorithmIdentifier        OPTIONAL,
     issuingKDS           [2]   Identifier,
     uniqueNumber         [3]   UniqueNumber,
     validityTime         [4]   TimePeriods,
     creationTime         [5]   UTCTime
   }

   SpecificContents ::= CHOICE{
     pac                [1]   PACSpecificContents
      -- only the PAC is used here
   }


Baize, Farrell, Parker    Document Expiration: 21 May 1996   [Page 61]


internet-draft                                       November 21, 1995

   TargetAEFPart ::= SEQUENCE {
     pacAndCVs          [0]   SEQUENCE OF CertandECV OPTIONAL,
     targetKeyBlock   [1]   TargetKeyBlock,
     dialogueKeyBlock [2]   DialogueKeyBlock,
     targetIdentity   [3]   Identifier,
     flags            [4]   BIT STRING   {
                              delegation         (0)
                            }
   }

   TargetKeyBlock ::= SEQUENCE {
      kdSchemeOID       [2]   OBJECT IDENTIFIER,
      targetKDSpart     [3]   ANY                OPTIONAL,
                                    -- depending on kdSchemeOID
      targetPart        [4]   ANY                OPTIONAL
                                    -- depending on kdSchemeOID
   }

   TargetNameValueSyntax ::= Identifier

   TargetResultToken ::=  SEQUENCE{
     trtContents    [0] TRTContents,
     trtSeal        [1] Seal
   }

   Token ::=
     [APPLICATION 0] IMPLICIT SEQUENCE {
      thisMech      MechType, -- the OBJECT IDENTIFIER specified below
      innerContextToken ANY DEFINED BY thisMech
   }

   TRTContents ::= SEQUENCE {

     tokenId        [0]   INTEGER,    -- shall contain X'0200'
     SAId         [1]   OCTET STRING,
     utcTime        [5]   UTCTime     OPTIONAL,
     usec         [6]   INTEGER     OPTIONAL,
     seq-number     [7]   INTEGER     OPTIONAL,
   }

   TrustGroupValueSyntax ::= Identifier

   UniqueNumber ::= SEQUENCE{
     timeStamp      [0] UTCTime,
     random           [1] BIT STRING
   }

   Validity ::=SEQUENCE {
            notBefore     UTCTime,
            notAfter      UTCTime
   } -- as in [ISO/IEC 9594-8]

Baize, Farrell, Parker    Document Expiration: 21 May 1996   [Page 62]


internet-draft                                       November 21, 1995

   -- Note: Validity is not tagged, for compatibility with the
   -- Directory Standard.

   WrapToken  ::=   PMToken

   END


A.2  Kerberos ASN.1 Definitions

   The SESAME GSS-API mechanism re-uses the HostAddress and Ticket
   types from [Kerberos]. These are reproduced here for ease of
   reference.

   SESAME-Kerberos-Definitions   {tbs }

   DEFINITIONS ::=

   BEGIN

   -- exports everything

   IMPORTS

   -- imports nothing

   -- data types

   AuthorizationData ::= SEQUENCE OF SEQUENCE {
     ad-type    [0]   INTEGER,
     ad-data  [1]   OCTET STRING}

   EncryptedData ::= SEQUENCE {
     etype    [0]   INTEGER, -- EncryptionType
     kvno     [1]   INTEGER       OPTIONAL,
     cipher   [2]   OCTET STRING  _ciphertext}

   EncryptionKey ::= SEQUENCE {

     keytype  [0]   INTEGER,
     keyvalue [1]   OCTET STRING}

   EncTicketPart ::= [APPLICATION 3] SEQUENCE {
     flags            [0]   TicketFlags,
     key            [1]    EncryptionKey,
     crealm         [2]   Realm,
     cname          [3]   PrincipalName,
     transited        [4]   TransitedEncoding,
     authtime       [5]   KerberosTime,
     starttime        [6]   KerberosTime OPTIONAL,
     endtime        [7]   KerberosTime,

Baize, Farrell, Parker    Document Expiration: 21 May 1996   [Page 63]


internet-draft                                       November 21, 1995

     renew-till       [8]   KerberosTime OPTIONAL,
     caddr          [9]   HostAddresses OPTIONAL,
     authorization-data   [10]  AuthorizationData OPTIONAL}

   HostAddress ::= SEQUENCE {
     addr-type        [0]   INTEGER,
     address        [1]   OCTET STRING}

   HostAddresses ::= SEQUENCE OF SEQUENCE {
     addr-type        [0]   INTEGER,
     address        [1]   OCTET STRING}

   KerberosTime ::= GeneralizedTime
      -- Specifying UTC time zone (Z)

   PrincipalName ::= SEQUENCE {
     name-type        [0]   INTEGER,
     name-string        [1]   SEQUENCE OF GeneralString}

   Realm ::= GeneralString

   Ticket ::= [APPLICATION 1] SEQUENCE {
     tkt-vno          [0]   INTEGER,
     realm          [1]   Realm,
     sname          [2]   PrincipalName,
     enc-part       [3]   EncryptedData} -- decrypts to
   EncTicketPart

   TicketFlags ::= BIT STRING {
     reserved       (0),  -- not supported in the SESAME mechanism
     forwardable        (1),  -- not supported in the SESAME
   mechanism
     forwarded        (2),  -- not supported in the SESAME mechanism
     proxiable        (3),  -- not supported in the SESAME mechanism
     proxy          (4),  -- not supported in the SESAME mechanism
     may-postdate     (5),  -- not supported in the SESAME mechanism
     postdated        (6),
     invalid          (7),  -- not supported in the SESAME mechanism
     renewable        (8),  -- not supported in the SESAME mechanism
     initial          (9),  -- not supported in the SESAME mechanism
     pre-authent        (10),
     hw-authent       (11)}

   TransitedEncoding ::= SEQUENCE {

     tr-type          [0]   INTEGER, -- must be registered
     contents       [1]   OCTET STRING}
        -- the TransitedEncoding construct is not used in the SESAME
   mechanism.

   END

Baize, Farrell, Parker    Document Expiration: 21 May 1996   [Page 64]


internet-draft                                       November 21, 1995


A.3  SPKM ASN.1 Definitions

   The SESAME GSS-API mechanism re-uses the SPKM-REQ type from
   [SPKM]. These are reproduced here for ease of reference.

   SESAME-SPKM-Definitions   {tbs }

   DEFINITIONS ::=

   BEGIN

   -- exports everything

   IMPORTS

     AuthorizationData
      FROM SESAME-Kerberos-Defintions   { tbs }

     AlgorithmIdentifier, Certificate, CertificateList,
   CertificatePair, CertificatePath
      FROM AuthenticationFramework {
                joint-iso-ccitt ds(5) modules(1)
   authenticationFramework(7) }

     Name
      FROM InformationFramework {
                joint-iso-ccitt ds(5) modules(1)
   informationFramework(1) }

   -- data types

   CertificationData ::= SEQUENCE {
     certificationPath        [0] CertificationPath    OPTIONAL,
     certificateRevocationList    [1] CertificateList
   OPTIONAL
   } -- at least one of the above shall be present

   CertificationPath ::= SEQUENCE {
     userKeyId      [0]   OCTET STRING
   OPTIONAL,
                            -- identifier for user's public key
     userCertif       [1]   Certificate
   OPTIONAL,
                            -- certificate containing user's public
   key
     verifKeyId       [2]   OCTET STRING
   OPTIONAL,
                            -- identifier for user's public
   verification key


Baize, Farrell, Parker    Document Expiration: 21 May 1996   [Page 65]


internet-draft                                       November 21, 1995

     userVerifCertif    [3]   Certificate
   OPTIONAL,
                            -- certificate containing user's public
   verification key
     theCACertificates  [4]   SEQUENCE OF CertificatePair
   OPTIONAL
                            -- certification path from target to
   source
   }

   ChannelId ::= OCTET STRING

   Conf_Algs ::= CHOICE {
     SEQUENCE OF AlgorithmIdentifier,
     NULL                     -- used when conf. is not available
   over context
                  }           -- for C-ALG

   Context_Data ::= SEQUENCE {
     channelId      ChannelId,               -- channel bindings
     seq_number   INTEGER OPTIONAL,   -- sequence number
     options        Options,
     conf_alg     Conf_Algs,             -- confidentiality. algs.
     intg_alg     Intg_Algs              -- integrity algorithm
   }

   ENCRYPTED MACRO ::=
   BEGIN
   TYPE NOTATION  ::= type(ToBeEnciphered)
   VALUE NOTATION ::= value(VALUE BIT STRING)
   END     -- of ENCRYPTED

   HASHED MACRO ::=
   BEGIN
     TYPE  NOTATION ::= type    ( ToBeHashed )
     VALUE NOTATION ::= value   ( VALUE OCTET STRING )
   END -- hash used is the one specified for the MANDATORY I-ALG

   Intg_Algs ::= SEQUENCE OF AlgorithmIdentifier  -- for I-ALG

   Key_Estb_Algs ::= SEQUENCE OF AlgorithmIdentifier  -- to allow
   negotiation of K-ALG

   MAC MACRO ::=
   BEGIN
     TYPE  NOTATION ::= type  ( ToBeMACed )
     VALUE NOTATION ::= value ( VALUE
              SEQUENCE  {
                  algId   AlgorithmIdentifier,
                  mac   BIT STRING
                        }

Baize, Farrell, Parker    Document Expiration: 21 May 1996   [Page 66]


internet-draft                                       November 21, 1995

                        )
   END

   Options ::= BIT STRING {
     delegation_state         (0),

     mutual_state           (1),
     replay_det_state         (2),    -- used for replay det. during
   context
     sequence_state         (3),    -- used for sequencing during
   context
     conf_avail             (4),
     integ_avail              (5),
     target_certif_data_required    (6)          -- used to
   request targ's certif. data
                  }

   Random_Integer ::= BIT STRING

   Req_Integrity ::= CHOICE {
     sig_integ    [0] SIGNATURE REQ_TOKEN,
     mac_integ    [1] MAC REQ_TOKEN
                    }

   REQ_TOKEN ::= SEQUENCE {
     tok_id       INTEGER,          -- shall contain 0100 (hex)
     context_id     Random_Integer,
     pvno         BIT STRING,       -- protocol version number
     timestamp      UTCTime                  OPTIONAL,
                                -- mandatory for SPKM-2
     randSrc      Random_Integer,
     targ_name      Name,
     src_name     Name,           -- may be a value indicating
   "anonymous"
     req_data     Context_Data,
     validity     [0] Validity
   OPTIONAL,
                                -- validity interval for key (may be
   used in the
                                -- computation of security context
   lifetime)
     key_estb_set [1] Key_Estb_Algs,         -- specifies set of
   key establishment algorithms
     key_estb_req   BIT STRING                   OPTIONAL,
                      -- key estb. parameter corresponding to first
   K-ALG in set
                      -- (not used if initiator is unable or
   unwilling to
                      -- generate and securely transmit key material
   to target).
                      -- Established key must be sufficiently long

Baize, Farrell, Parker    Document Expiration: 21 May 1996   [Page 67]


internet-draft                                       November 21, 1995

   to be used
                      -- with any of the offered confidentiality
   algorithms.
     key_src_bind   HASHED SEQUENCE {
                  src_name    Name,
                  symm_key    BIT STRING}OPTIONAL
                      -- used to bind the source name to the
   symmetric key
                      -- (i.e., the unprotected version of what is
                      -- transmitted in key_estb_req).
     }

   SIGNATURE MACRO ::=
   BEGIN
   TYPE NOTATION   ::= type (OfSignature)
   VALUE NOTATION  ::= value(VALUE
     SEQUENCE {
        AlgorithmIdentifier,
        ENCRYPTED OCTET STRING
              }
                      )
   END

   SPKM_REQ ::= SEQUENCE {
     requestToken       REQ_TOKEN,
     req_integrity        Req_Integrity,
     certif_data      [2]   CertificationData OPTIONAL,
     auth_data      [3]   AuthorizationData OPTIONAL
      -- see [Kerberos] for a discussion of authorization data
   }

   Validity ::= SEQUENCE {
            notBefore   UTCTime,
            notAfter      UTCTime }

   END

APPENDIX B: ECMA BACKGROUND MATERIAL.

   ECMA's work was based on the OSI Architecture [ISO 7498-2], and
   the series of Security Frameworks developed in ISO/IEC JTC1 [ISO
   10181]. A Technical Report, [ECMA TR/46] published in 1988,
   concentrates on the application layer and describes a security
   framework in terms of application functions necessary to build
   secure open systems. The continuation of this report, [ECMA-138],
   defines the abstract security services for use in a distributed
   system. A parallel standard, [ECMA-206], describes a model for
   establishing secure relationships between applications in a
   distributed system. ECMA has recently completed work to define
   the functionality and the protocols for a distributed security
   service in charge of authenticating and distributing access

Baize, Farrell, Parker    Document Expiration: 21 May 1996   [Page 68]

internet-draft                                       November 21, 1995

   rights to human and application principals, along with supportive
   key distribution functions. The ECMA standard which is the result
   of that work is called ECMA-219 [ECMA-219]. It was approved by
   the ECMA General Assembly in December 1994 and released in
   January 1995.

   ECMA is currently developing a standard parallel to this draft
   which standardises the use of the ECMA security mechanism below
   the GSS-API. This draft is effectively a profile of that work.

APPENDIX C: SESAME IMPLEMENTATION STATUS

   The SESAME project has implemented the above protocols and source
   code for this will be made publicly available for non-commercial
   use at the end of 1995 as SESAME version 4.

   There are however, some minor differences between this
   specification and the SESAME version 4 implementation - mainly
   due to the fact that this specification assumes the use of a
   generic GSS-API negotiation scheme (like [SNEGO]) whereas SESAME
   version 4 implements negotiation within the tokens according to
   the standard ECMA-206 (Association Context Management).