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

Text File | 1996-11-26 | 134KB | 3,771 lines

Internet-Draft                                       ERIC BAIZE, BULL
IETF Common Authentication Technology WG         STEPHEN FARRELL, SSE
                                                      TOM PARKER, ICL
<draft-ietf-cat-sesamemech-02.txt>                  November 22, 1996


                    The SESAME V5 GSS-API Mechanism


STATUS OF THIS MEMO

This specification 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 specification should be sent to "[e-mail]", 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 Version 5 Mechanism.

1.  BACKGROUND

   Although the Kerberos Version 5 GSS-API mechanism [KRB5] is becoming
   well-established in many environments, it is important in some
   applications to have a GSS-API mechanism, which is able to support
   privileges rather than only a single identity, which is scalable
   because it supports public key technology and which is flexible
   in a distributed environment due to its fine granularity delegation
   properties.

   The mechanism described in this specification has been designed
   to provide the following features.


Baize, Farrell, Parker     Document Expiration: 22 May 1997    [Page 1]







internet-draft                                        November 22, 1996

      1)  SESAME allows both unilateral and mutual authentication
          to be accomplished using loosely synchronous clocks. One key
          advantage of this feature is that, when unilateral
          authentication is used, no additional message (as in a
          challenge-response mechanism) is needed and thus it is
          possible to concatenate in a single message, for example,
          an "init-sec token", a "wrapped token" and a "close token".

      2)  In addition to authentication, SESAME supports the
          transmission of the access control privileges of a user.
          These privileges are carried in a data structure called the
          PAC (Privileges Attribute Certificate). Privileges supported
          in SESAME V5 are group-memberships, roles and administration
          defined local types. In the future support for clearances or
          capabilities is envisaged. SESAME supports the "push model"
          where the privileges are pushed towards the target. This
          allows the principle of least privilege to be supported,
          where only the privileges that are necessary for performing
          an operation are presented and disclosed to the target.

      3)  Privileges are always directly guaranteed by the
          authority which originally vouched for them. This allows
          the concept of "direct trust" to be supported because no
          intermediate security domain is needed to translate the
          original guaranteed privileges when they are delegated, even
          across security domains. In practice, this is made possible
          because the privileges are placed in a data structure that is
          signed by the issuing domain authority, and thus is directly
          verifiable.

      4)  The scheme used to transmit privileges is
          independent of the scheme used for key management. This
          allows several key management schemes and their extensions
          to be supported. In practice, SESAME allows each security
          domain manager to chose its own key management scheme.
          Cross-domain relationships can either be based on public
          key technology or on secret key technology.

      5)  The control of delegation is a key feature of SESAME. This
          allows privileges to be transmitted and their use to be
          restricted to nominated targets or groups of targets.

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

   A more complete overview of SESAME is available in [SESOV].


Baize, Farrell, Parker     Document Expiration: 22 May 1997    [Page 2]







internet-draft                                        November 22, 1996

1.1 Table of Contents

1.  BACKGROUND                                                        1
2.  THE SESAME TECHNOLOGY                                             4
2.1.  Overview                                                        4
2.2.  SESAME Concepts                                                 5
2.2.1.  Access Control Concepts                                       5
2.2.1.1.  Domains                                                     5
2.2.1.2.  Identities                                                  5
2.2.1.3.  Privilege Attributes                                        5
2.2.1.4.  Delegation                                                  6
2.2.1.5.  Application Trust Groups (ATGs)                             6
2.2.2.  Target Access Enforcement Function (targetAEF)                6
2.2.3.  SESAME Key Distribution                                       7
2.2.3.1.  Basic keys and dialogue keys                                7
2.2.3.2.  Basic symmetric key distribution scheme (symmIntradomain)   7
2.2.3.3.  Hybrid key distribution scheme (hybridInterdomain)          8
2.2.3.4.  Full public key distribution scheme (asymmetric)            8
2.2.3.5.  Derivation of Dialogue Keys                                 8
2.2.4.  Use of Cryptography in SESAME                                 8
3.  GSS-API TOKEN FORMATS                                             9
3.1.  Token framings                                                  9
3.2.  InitialContextToken format                                     10
3.3.  TargetResultToken                                              14
3.4.  ErrorToken                                                     15
3.5.  Per Message Token formats                                      15
3.5.1.  MICToken                                                     17
3.5.2.  WrapToken                                                    17
3.6  ContextDeleteToken format                                       18
4.  DATA ELEMENT DEFINITIONS                                         18
4.1.  Access Control Data Elements                                   19
4.1.1.  Generalised certificate (GeneralisedCertificate)             19
4.1.1.1.  Common Contents fields (CommonContents)                    19
4.1.1.2.  PAC Specific Certificate Contents (PACSpecificContents)    20
4.1.1.3.  Check value (CheckValue)                                   21
4.1.2.  Security Attributes (SecurityAttribute)                      21
4.1.3.  Protection Methods                                           22
4.1.3.1.  "Control/Protection Values" protection method              22
4.1.3.2.  "Primary Principal Qualification" protection method        23
4.1.3.3.  "Target Qualification" protection method                   24
4.1.3.4.  "Delegate/Target Qualification" protection method          24
4.1.3.5.  Combining the methods                                      25
4.1.4.  External Control Values Construct (ECV)                      25
4.2. Basic Key Distribution                                          26
4.2.1.  Data elements for the Symmetric Intradomain kd-scheme        28
4.2.2.  Data elements for the Hybrid interdomain kd-scheme.          29
4.2.3.  Data elements for the asymmetric kd-scheme                   30
4.3.  Dialogue Key Block                                             30
4.4.  Attribute Definitions                                          31
4.4.1.  Privilege attributes                                         31
4.4.1.1.  Access Identity                                            31
4.4.1.2.  Group                                                      31

Baize, Farrell, Parker     Document Expiration: 22 May 1997    [Page 3]







internet-draft                                        November 22, 1996

4.4.1.3.  Primary group                                              32
4.4.1.4.  Role attribute                                             32
4.4.2.  Miscellaneous attributes                                     32
4.4.2.1.  Audit Identity                                             32
4.4.3.  Qualifier Attributes                                         32
4.4.3.1.  Target Attributes                                          32
4.4.3.2.  Application Trust Groups                                   32
5.  ALGORITHMS AND CIPHERTEXT FORMATS                                32
6.  SESAME MECHANISM NEGOTIATION                                     35
7.  NAME TYPES                                                       36
7.1.  Kerberos naming                                                36
7.2.  Directory Naming                                               37
8.  SECURITY CONSIDERATIONS                                          38
9.  PATENTS                                                          38
9.1.  BULL PATENT                                                    38
9.2.  ICL PATENTS                                                    39
9.2.1. PAC USE MONITOR (C1167 )                                      39
9.2.2. PROXY CONTROL (C1179)                                         39
10.  ACKNOWLEDGEMENTS                                                39
11.  REFERENCES                                                      40
12.  AUTHOR'S ADDRESSES                                              41
APPENDIX A: ASN.1 MODULE DEFINITIONS                                 42
A.1.  SESAME ASN.1 Definitions                                       42
A.2.  Kerberos ASN.1 Definitions                                     51
A.3.  SPKM ASN.1 Definitions                                         53
APPENDIX B: Profiling of KD-schemes                                  57
B.1.  Profile of Ticket as used in symmIntradomain scheme            57
B.2.  Profile of PublicTicket as used in hybridInterdomain scheme    57
B.3.  Profile of SPKM_REQ as used in asymmetric scheme               58
APPENDIX C: ECMA BACKGROUND MATERIAL.                                60



2.  THE SESAME TECHNOLOGY

2.1.  Overview

   The tokens defined in SESAME are intended to be used by application
   programs according to the GSS API "operational paradigm" (see
   [RFC-1508] for further details):

      The operational paradigm in which GSS-API operates is as follows.
      A typical GSS-API caller is itself a communications protocol [or
      is an application program which uses a communications protocol],
      calling on GSS-API in order to protect its communications with
      authentication, integrity, and/or confidentiality security
      services.  A GSS-API caller accepts tokens provided to it by its
      local GSS-API implementation [i.e., its GSS-API mechanism] and
      transfers the tokens to a peer on a remote system; that peer
      passes the received tokens to its local GSS-API implementation for
      processing.


Baize, Farrell, Parker     Document Expiration: 22 May 1997    [Page 4]







internet-draft                                        November 22, 1996

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

2.2.  SESAME Concepts

2.2.1.  Access Control Concepts

2.2.1.1.  Domains

   A `security domain' is a set of elements, a security authority
   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].
   A security domain must support at least, one authentication server
   (AS), one privilege attribute server (PAS) and may need a key
   distribution server (KDS).

2.2.1.2.  Identities

SESAME supports the three following types of identity:

   Authenticated Identity   which is the identity held in the PAS
                            ticket obtained from Authentication
                            Server. This is used to permit the
                            release of Privilege Attributes for use in
                            access control decisions.

   Access Identity          which is used in PACs as a Privilege
                            Attribute. This attribute reflects a value
                            given by the PAS administrator. Note that
                            the access identity does not need to be
                            always present within a PAC, because access
                            can be granted using, for example, group-
                            memberships or roles rather than
                            individual identities.

   Audit Identity           a value unique to an individual which is
                            used in PACs only for accountability
                            purposes. This is a separate field in the
                            PAC, which reflects a value given by the
                            PAS administrator.


2.2.1.3.  Privilege Attributes

   Standard Privilege Attribute types are defined so they can be
   independent of specific end-system representations but which can
   be mapped as appropriate in the receiving system.


Baize, Farrell, Parker     Document Expiration: 22 May 1997    [Page 5]







internet-draft                                        November 22, 1996

   The privilege attributes which are supported in this specification are :

                 access identity
                 primary group
                 group
                 role attribute
                 Domain defined attributes (i.e. defined by the PAS
                                            administrator)

   Together these provide for the support of a variety of formulations
   of access control policy, for example Role Based Access Control.

2.2.1.4.  Delegation

   An initiator may not wish to delegate all his rights, and may 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 or other
   target attributes (though in SESAME V5 the only attribute type
   supported is the Application Trust Group - see next).

   Mechanisms are also provided to prevent a PAC from being delegated
   where this is appropriate.

2.2.1.5.  Application Trust Groups (ATGs)

   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 (targetAEF)

   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)(see ISO IEC
   10181-3). This has a number of advantages:

    -  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 an asymmetric key pair,

    -  the security critical code is isolated which makes security
       evaluation simpler,

Baize, Farrell, Parker     Document Expiration: 22 May 1997    [Page 6]







internet-draft                                        November 22, 1996

    -  administration is simplified as one targetAEF may "serve" many
       target applications,

    -  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 served by the same AEF is accessed.

A patent from ICL applies to this method (see section 9).

2.2.3.  SESAME Key Distribution

   There are different key distribution schemes in SESAME.
   Each depends upon the existence of long term cryptographic keys
   which held by targets AEFs 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.

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

2.2.3.1.  Basic keys and dialogue keys

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

   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 shares a temporary secret key with
   the KDS and the target AEF shares a long term secret key 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.


Baize, Farrell, Parker     Document Expiration: 22 May 1997    [Page 7]







internet-draft                                       November 22, 1996

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

2.2.3.3.  Hybrid key distribution scheme (hybridInterdomain)

   In this scheme, the initiator shares a temporary secret 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.

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


Baize, Farrell, Parker     Document Expiration: 22 May 1997    [Page 8]







internet-draft                                       November 22, 1996

   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

3.1.  Token framings

   All tokens including context-establishment tokens, per-message
   tokens, and context-deletion token are enclosed within framing as
   follows:

   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 (v) (y) (z) }

   Where:

   generic-sesame-mech ::= OBJECT IDENTIFIER

   iso.org.icd-ecma.technical-report.security-in-open-systems.
   authentication-machanism {1.3.12.1.46.1}

   The value v represents the version of the mechanism. The current
   version is version 5. The current oid is therefore:
   {1.3.12.1.46.1.5}

   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 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:


Baize, Farrell, Parker     Document Expiration: 22 May 1997    [Page 9]







internet-draft                                       November 22, 1996

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

   The innerContextToken field of per-message tokens for the SESAME
   GSS-API mechanism will consist of a 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:

   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.

3.2.  InitialContextToken format

   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

Baize, Farrell, Parker     Document Expiration: 22 May 1997   [Page 10]







internet-draft                                       November 22, 1996

   integDKUseInfo in the dialogueKeyBlock field of the targetAEFPart
   from the initial context token.

   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

Baize, Farrell, Parker     Document Expiration: 22 May 1997   [Page 11]







internet-draft                                       November 22, 1996

   sealValue field of the Seal data structure is present. The
   cryptographic algorithms that apply are specified by algorithm
   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
   Microsecond part of the initiator's time stamp. This field along
   with utcTime are used together to avoid collision between tokens
   generated by two initiators at the same time. This field enables a
   simple scheme for replay detection of initial tokens to be
   supported.

   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.

Baize, Farrell, Parker     Document Expiration: 22 May 1997   [Page 12]







internet-draft                                       November 22, 1996


   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,
     targetIdentity     [3]   SecurityAttribute,
     flags              [4]   BIT STRING   {
                                delegation         (0)
                            }
   }

         Note 1:  Individual PACs have validity of their own, thus
                  it is not sensible to have an overall separately
                  specified validity period for the whole context.

   pacAndCVs
   The initiator's privileges and security attributes to be used for
   this Security Association. This field is not present when the
   association does not require initiator privileges or security
   attributes. 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.


   The Seal structure is used in this Token and other tokens.

Baize, Farrell, Parker     Document Expiration: 22 May 1997   [Page 13]







internet-draft                                       November 22, 1996

   Seal ::=  SEQUENCE{
     sealValue          [0]   BIT STRING,
     symmetricAlgId     [1]   AlgorithmIdentifier        OPTIONAL,
     hashAlgId          [2]   AlgorithmIdentifier        OPTIONAL,
     targetName         [3]   SecurityAttribute          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
   identifies the symmetric key used in the seal.


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.

   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,
   }

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

Baize, Farrell, Parker     Document Expiration: 22 May 1997   [Page 14]







internet-draft                                       November 22, 1996

         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 targetAEFPart
   from the initial context token.

3.4.  ErrorToken

   ErrorToken ::= SEQUENCE {
      tokenType     [0]   OCTET STRING VALUE X'0300',
      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),
     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 Token formats

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

Baize, Farrell, Parker     Document Expiration: 22 May 1997   [Page 15]







internet-draft                                       November 22, 1996

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

   PMTContents ::=  SEQUENCE {
     tokenId              [0]   INTEGER, -- shall contain X'0101'
                                         -- for a MIC token and
                                         -- X'0201' for a Wrap token.

     SAId                 [1]   OCTET STRING,
     seq-number           [2]   INTEGER
   OPTIONAL,
     userData             [3]   CHOICE {
                                plaintext      OCTET 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
         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

Baize, Farrell, Parker     Document Expiration: 22 May 1997   [Page 16]







internet-draft                                       November 22, 1996


         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.

   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

Baize, Farrell, Parker     Document Expiration: 22 May 1997   [Page 17]







internet-draft                                       November 22, 1996

   performed using the Confidentiality Dialogue Key, and as in
   [Kerberos], an 8-byte random confounder is first prepended to the
   data to be encrypted.

   pmtSeal
   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 format

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

   cdtSeal
   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

Baize, Farrell, Parker     Document Expiration: 22 May 1997   [Page 18]







internet-draft                                       November 22, 1996

   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-mech ::=  OBJECT IDENTIFIER {1.3.12.1.46}
      -- top of the SESAME types arc


4.1.  Access Control Data Elements

   The ASN.1 definitions for the PAC and related data structures. The full
   ASN.1 specification can be found in [ECMA-219] and in Annex A.

4.1.1.  Generalised certificate (GeneralisedCertificate)

   A Generalised Certificate (PAC) consists of a certificateBody and
   checkValue, the latter containing a digital signature applied to
   the former. The CertificateBody is formed of two parts:
   a commonContents and a specificContents part.

   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
   of certificate, and contain a type identifier to indicate the
   type. In this specification only one type is defined: the Privilege
   Attribute Certificate (PAC).

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

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

4.1.1.1.  Common Contents fields (CommonContents)

The common contents field of the PAC is made of the following fields:

   comConSyntaxVersion
   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

Baize, Farrell, Parker     Document Expiration: 22 May 1997   [Page 19]







internet-draft                                       November 22, 1996

   if other forms of naming are in use, such as proprietary
   identifiers.

   issuerIdentity
   The identity of the issuing authority for the certificate.

   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
   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.  PAC Specific Certificate Contents (PACSpecificContents)

The specific contents field of the PAC is made of the following fields:

   The pacSyntaxVersion is defaulted.

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

      The pacType is defaulted.

   privileges
   Privilege Attributes of the principal in the form of security
   attributes. For a full description ofsecurity attributes see
   section 4.1.2.

   restrictions
   not supported in SESAME V5 - see [ECMA-219] for a full description.

   miscellaneousAtts
   Attributes that are neither privilege attributes nor restrictions.
   Audit identity is one such attribute.

Baize, Farrell, Parker     Document Expiration: 22 May 1997   [Page 20]







internet-draft                                       November 22, 1996

   TimePeriods
   further time period restriction over and above that specified in
   commonContents.

4.1.1.3.  Check value (CheckValue)

   In this specification a PAC is protected 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.

A signature is composed of the following fields:

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

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

4.1.2.  Security Attributes (SecurityAttribute)

   The security attribute is a basic construct made up of :

   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
   Indicates the authority responsible for defining the value
   within the attribute type. Some policies demand that multiple
   sources of values for a given attribute type be supported (e.g. a
   policy accepting attribute values defined outside the security
   domain), These policies give rise to a risk of value clashes. The
   definingAuthority field is used to separate these values. When not
   present, the value defaults to the name of the authority that
   issued the certificate containing the attribute.

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







internet-draft                                       November 22, 1996


   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.  Protection Methods

   Protection methods are grouped in methodGroups. See section 4.1.3.5
   for the significance of these groups. Protection methods are formed
   as a combination of methodId and methodParams. The methodParams are
   formed as a sequence of Mparm constructs. Each methodId determines
   a syntax for Mparm.

   methodId
   Identifies a protection method. 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 .

   methodParams
   Parameters for a protection method formed as a sequence of
   individual method parameter constructs (Mparm).

There are four basic protection methods, as described below.

4.1.3.1.  "Control/Protection Values" protection method

   This is known as the CV/PV method. A patent from Bull applies to
   this method (see section 9).

   This method allows a PAC to be used by proxy while at the same time
   preventing it from being stolen by an eavesdropper. The PAC can be
   forwarded to any target or group of targets. The owner of the PAC
   need not know in advance. But if this information is known, use of
   the PAC can be confined to any nominated target or group of targets.
   Ownership of a PAC can be proven by presenting a CV value which
   matches a public value contained in the PAC. The two values must
   relate through the relationship: PV = OWF (CV), where OWF is a one
   way collision resistant hash function. Unless otherwise specified,
   the one-way function that is used for this method is MD5.

   The MethodId for this is: controlProtectionValues

   The syntax choice of Mparm for this method is: pValue.

   A maximum of one PV method is permitted in each method group. More
   than one method group can be specified, each containing a PV.

   Associated with each PV is a certificate Control Value (CV)


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







internet-draft                                       November 22, 1996

   external to the certificate. The CVs are carried encrypted in the
   ECV construct.

   When the client sends a PAC to a targetAEF, one or more CVs
   are also sent encrypted under the basic key used to communicate
   with the target AEF. 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 one or more of the values to the
   infrastructure supporting that application for forwarding with the
   certificate to other applications. By including target qualification
   controls in the method group, proxy can be confined to nominated
   target applications. One use for this might be, for example, all of
   the application servers in a distributed service.

4.1.3.2.  "Primary Principal Qualification" protection method

   This is known as the PPID (Primary Principal IDentifier) method.
   A patent from ICL applies to this 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" as
   defined in [ECMA-219]. 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, preventing delegation of
   the certificate. However it can also be used to permit delegation,
   when the required attributes of the proxy application are precisely
   known in advance. The method by itself does not limit the number of
   target applications at which a PAC might be accepted. However, by
   including separate target qualification controls in the method
   group, delegation can be confined to nominated target applications.

   The syntax choice of Mparm for this method is : securityAttribute

   A sequence of Mparm constructs is permissible, resulting in multiple
   nominated Primary Principals being capable of being permitted.

   At least one of these attributes must be possessed by any Primary
   Principal from which this certificate is to be validly used if the
   PAC is to be accepted under this method. When a targetAEF receives
   such a certificate, it is responsible for comparing these attributes
   with attributes placed within the targetKeyBlock construct and
   associated with the initiating Primary Principal.

   When a symmetric key distribution scheme is in use the attribute
   values are placed in the target key block by the trusted server

Baize, Farrell, Parker     Document Expiration: 22 May 1997   [Page 23]







internet-draft                                       November 22, 1996

   (the KDS) which created it. If there is no KDS, as in the case of
   pure asymmetric key distribution, they are present in the public key
   certificate of the initiator that is sent with the PAC.

   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 is constructed from the certificate serial number and the CA
   name for the initiator's X.509 public key certificate.

4.1.3.3.  "Target Qualification" protection method

   The MethodId for this is: targetQualification.

   This method protects the PAC from misuse by allowing its use only
   by one or more nominated target applications and at the same time
   instructing the target AEF to prevent it from being forwarded.

   The syntax choice of Mparm for this method is : securityAttribute

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

   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.3.4.  "Delegate/Target Qualification" protection method

   The MethodId for this is: delegateTargetQualification

   This method protects the PAC from misuse by confining its validity
   to one or more nominated target applications and at the same time
   instructing the target AEF to allow the PAC to be forwarded.

   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 target AEF makes the comparisons described in the previous
   section, but if the checks are passed, the nominated target
   application(s) is/are acceptable as both an accessible target and
   as a delegate. The attributes carried by the certificate are valid
   at the target application(s) for authentication or access control

Baize, Farrell, Parker     Document Expiration: 22 May 1997   [Page 24]







internet-draft                                       November 22, 1996

   purposes and the target AEF will allow the PAC to be forwarded to
   further target applications.

4.1.3.5.  Combining the methods

   The general rule for validating a PAC 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
         target or delegateTarget qualification method in this group

         and

         tests on any ppQualification or controlProtectionValues
         method in the group succeed. 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.4.  External Control Values Construct (ECV)

   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.

   crypAlgIdentifier
   This specifies the encryption algorithm of the control values.

   cValues
   An ECV construct contains in the encryptedCvalueList field a list
   of control values encrypted under the basic key protecting the
   operation. The whole list is encrypted in bulk, but the in-clear
   contents of this field are expected to have the syntax CValues.

   The CValues is composed of a sequence of tuples, each one being

Baize, Farrell, Parker     Document Expiration: 22 May 1997   [Page 25]







internet-draft                                       November 22, 1996

   composed of an index of the method occurrence in the certificate,
   starting at 1, and the value of the CV.


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.

   The TargetKeyBlock is composed of the following fields:

   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

Baize, Farrell, Parker     Document Expiration: 22 May 1997   [Page 26]







internet-draft                                       November 22, 1996

   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. The targetKDSpart
   includes 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 contains the appropriate primary principal
   security attributes.

   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 targetKDSpart 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

        Table 1 - Key Distribution Scheme OBJECT IDENTIFIERs

   The syntax of PublicTicket is given in appendix A.1, 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.

   The OBJECT IDENTIFIERs that are for use in the kdSchemeOID field
   of TargetKeyBlock are formally derived from the kd-schemes OBJECT
   IDENTIFIER

   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 sesame-key-estb-alg is
   defined as the (single) key establishment "algorithm" for the
   SESAME mechanism.

Baize, Farrell, Parker     Document Expiration: 22 May 1997   [Page 27]







internet-draft                                       November 22, 1996

   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.2. 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.3. The targetKDSpart contains a PublicTicket (defined
   in section 4.2.2). The targetPart field is not supplied. The
   PublicTicket contains a Kerberos Ticket. The profile supported in
   this scheme can be found in Table 3.

   asymmetric
   This OBJECT IDENTIFIER indicates the scheme described in section
   2.2.3.4. 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.1.  Data elements for the Symmetric Intradomain kd-scheme

   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 (SESAME-AUTHORIZATION-DATA) contains the
   PPID of the context initiator.

   ppidType
   Indicates the type of authorisation data as being SESAME
   authorisation data.



Baize, Farrell, Parker     Document Expiration: 22 May 1997   [Page 28]







internet-draft                                       November 22, 1996

   ppidValue
   This value is used in the ppQualification PAC protection method
   as defined in section 4.1.3.2.

4.2.2.  Data elements for the Hybrid interdomain kd-scheme.

   The PublicTicket contains the following fields:

   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.

   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.

The KeyEstablishmentData contains the following fields :

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

   targetName
   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

Baize, Farrell, Parker     Document Expiration: 22 May 1997   [Page 29]







internet-draft                                       November 22, 1996

   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.3.  Data elements for the asymmetric kd-scheme

   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.

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.

   The DialogueKeyBlock is composed of the following fields:

   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:


Baize, Farrell, Parker     Document Expiration: 22 May 1997   [Page 30]







internet-draft                                       November 22, 1996

         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.

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

4.4.  Attribute Definitions

4.4.1.  Privilege attributes

4.4.1.1.  Access Identity

   The access identity represents an identity that the principal is
   permitted to use for access control purposes.

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.



Baize, Farrell, Parker     Document Expiration: 22 May 1997   [Page 31]







internet-draft                                       November 22, 1996

4.4.1.3.  Primary group

   The primary group represents a unique group to which a principal
   belongs. A security context must not contain more than one
   primary group for a given principal.

4.4.1.4.  Role attribute

   The role attribute represents a principal's role as might be used
   in a role based access control policy. For example it can represent
   a job position an individual may have within a company.

4.4.2.  Miscellaneous attributes

4.4.2.1.  Audit Identity

   Audit identity represents an identity unique to principal to be
   used for accountability purposes.
4.4.2.2 Other

Other miscellaneous attributes are
defined in ECMA-219 but are not currently supported in SESAME V5.

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.

4.4.3.1.  Target Attributes

   Within a PAC protection method, targets can be identified by name
   or other attributes to indicate whether they are allowed to accept
   or both accept and forward that PAC.

Other than name, the only target attribute supported in SESAME V5 is the
Application Trust Group (see below)..

4.4.3.2.  Application Trust Groups

   Within a PAC protection method, an application trust group name
   specifies the name of a set of targets allowed to accept or both
   accept and forward that PAC.

   The universal application trust group (see section 2) is specified
   by using an empty string value. See also section 2.2.1.5.

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

Baize, Farrell, Parker     Document Expiration: 22 May 1997   [Page 32]







internet-draft                                       November 22, 1996

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

Baize, Farrell, Parker     Document Expiration: 22 May 1997   [Page 33]







internet-draft                                       November 22, 1996

   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
   64 bit key.

                       Profile 1:  Profile 2: Profile 3:  Profile 5:
                       Full        No user    Exportable  Defaulted
                                   data
                                   Confiden
                                   tiality
    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 4 and 5    RSA         RSA        RSA         separately
                                                          agreed
                                                          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

Baize, Farrell, Parker     Document Expiration: 22 May 1997   [Page 34]







internet-draft                                       November 22, 1996

   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
   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 ,   V   ,   Y    ,   Z
                            ^       ^       ^
                            |       |       |
                            |       |       +-- algorithm
                            |       |           profile
                            |       |
                            |       +---------- architectural option
                            |
                            +------------------ version

Baize, Farrell, Parker     Document Expiration: 22 May 1997   [Page 35]







internet-draft                                       November 22, 1996


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

        { generic-sesame-mech  (5)  (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  (5)  (6)  (2) }

   Not all combinations of key distribution scheme and algorithm
   profile are meaningful, however, but those that are, are intended
   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 `\`

Baize, Farrell, Parker     Document Expiration: 22 May 1997   [Page 36]







internet-draft                                       November 22, 1996

   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>

   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/[e-mail]

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

Baize, Farrell, Parker     Document Expiration: 22 May 1997   [Page 37]







internet-draft                                       November 22, 1996

   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.

   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.  SECURITY CONSIDERATIONS

   Security issues are discussed throughout this memo.

9.  PATENTS

   Three patents apply. One from Bull and two from ICL.

9.1.  BULL PATENT

   A patent with the French number 2,662,007 and the French title
   "Procedure d'obtention d'une attestation en clair securisee dans
   un environnement de systeme informatique distribue " ( Method for
   obtaining a securitized clear text attestation in a distributed
   data processing system environment ) has been filed on May 10, 1990
   under the number 90.05829 and is also registered in the following
   countries under the following numbers :

      - European Patent No 91401138.2 (designated states: Germany,
        France, GB, Italy, Netherlands, and Sweden),
      - Canadian Patent No 2,041,761,
      - US Patent No 5,214,700.

   The inventors are : Philippe Caille and Denis Pinkas.

Baize, Farrell, Parker     Document Expiration: 22 May 1997   [Page 38]







internet-draft                                       November 22, 1996

9.2.  ICL PATENTS

9.2.1. PAC USE MONITOR (C1167 )

   A patent based on GB 9010603.0 with the title "Access Control in
   a Distributed Computer System" has been filed on May 11, 1990 and
   has also be registered in the following countries under the
   following numbers :

     - Australia Patent No: 634653 granted: 25/02/93
     - European Application No: 91303752.9 filed: 25/04/91
       (Designated states: Germany, France, GB, Italy, Netherlands.)
     - United States Patent No: 5339403 granted: 16/08/94
     - South Africa Patent No: 91/3322 granted: 12/12/91

The inventor is : Parker T A.

   It uses the term "PAC use monitor" which corresponds to what is
   called in this specification the "targetAEF".

9.2.2. PROXY CONTROL (C1179)

   A patent based on GB 9104909.8 with the title "Access Control in
   a Distributed Computer System" has been filed on August 3, 1991 and
   has also be registered in the following countries under the
   following numbers :

     - Australia Patent No: 655960 granted: 19/01/95
     - European Application No:92301081.3 filed: 19/02/92
       (Designated states: Belgium, Germany, France, GB, Italy)
     - Japan Application No 48618/1992 filed: 05/03/92
     - United States Patent No: 5220603 granted: 15/06/93
     - South Africa Patent No: 92/1425 granted: 15/09/92

The inventor is : Parker T A.

   It uses the term "Proxy control" which  corresponds to what is
   called in this specification the PPID method.

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

   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, Philippe Caille,
   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, Jean Louis
   Roule, Don Salmon, Asmund Skomedal and Mark Van DenWauver.

Baize, Farrell, Parker     Document Expiration: 22 May 1997   [Page 39]







internet-draft                                       November 22, 1996



11.  REFERENCES

   ECMA-219      ECMA-219 Second Edition, March 1996, Authentication
                 and Privilege Attribute Application with related key
                 distribution functions. This standard is available
                 free of charge from: ECMA 114 Rue du Rhone
                 CH-1204 Geneva (Switzerland).
                 Internet : [e-mail]
                 This standard can also be downloaded using one of the
                 following URLs:
                    ftp://ftp.ecma.ch/ecma-st/e219-doc.exe ;
                    ftp://ftp.ecma.ch/ecma-st/e219-exp.txt ;
                    ftp://ftp.ecma.ch/ecma-st/e219-pdf.pdf ;
                    ftp://ftp.ecma.ch/ecma-st/e219-psc.exe .

   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       Internet RFC 1964, The Kerberos Version 5
                  GSS-API Mechanism (J. Linn, June 1996)

   XGSSAPI        draft-ietf-cat-xgssapi-acc-cntrl-01.txt: Extended
                  Generic Security Service APIs: XGSS-APIs (Denis
                  Pinkas and Piers McMahon, July 1996)

   SESOV          SESAME Overview, Version 4, (Tom Parker and Denis
                  Pinkas, December 1995)

   SPKM           RFC 2025 The Simple Public-Key GSS-API Mechanism
                  (C. Adams, OCtober 1996)

   SNEGO          draft-ietf-cat-snego-01 Simple GSS-API
                  Negotiation Mechanism (Eric Baize and Denis
                  Pinkas, October 1996)





Baize, Farrell, Parker     Document Expiration: 22 May 1997   [Page 40]







internet-draft                                       November 22, 1996



12.  AUTHOR'S ADDRESSES

   Eric Baize,
   Bull HN - MA02/211S
   Technology Park
   Billerica, MA 01821,
   USA.

   email: [e-mail]

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

   email: [e-mail]

   Tom Parker,
   The Solution Centre,
   ICL,
   Lovelace Road,
   Bracknell,
   Berkshire   RG12 8SN
   UK


   email: [e-mail]























Baize, Farrell, Parker     Document Expiration: 22 May 1997   [Page 41]







internet-draft                                       November 22, 1996

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

     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 {1.3.12.1.46.1}

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

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

   kd-schemes   OBJECT IDENTIFIER ::=  { generic-sesame-oids 9}
      -- ECMA-defined 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


Baize, Farrell, Parker     Document Expiration: 22 May 1997   [Page 42]







internet-draft                                       November 22, 1996


   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-attribute OBJECT 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 }
      -- 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

   AuditIdValueSyntax ::=  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
                            }
   }

Baize, Farrell, Parker     Document Expiration: 22 May 1997   [Page 43]







internet-draft                                       November 22, 1996

   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,
     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
   }



Baize, Farrell, Parker     Document Expiration: 22 May 1997   [Page 44]







internet-draft                                       November 22, 1996

   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),
     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'0300',
      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,

Baize, Farrell, Parker     Document Expiration: 22 May 1997   [Page 45]







internet-draft                                       November 22, 1996

     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
   }

   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]   SecurityAttribute            OPTIONAL,
      nameHashingAlg    [2]   AlgorithmIdentifier          OPTIONAL
   }

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


Baize, Farrell, Parker     Document Expiration: 22 May 1997   [Page 46]







internet-draft                                       November 22, 1996

   MethodGroup ::=  SEQUENCE OF Method

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

      MICToken  ::=    PMToken

   Mparm ::=  CHOICE{
     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' for a MIC
                                         -- token and X'0201' for a Wrap
                                         -- token.

     SAId                 [1]   OCTET STRING,
     seq-number           [2]   INTEGER                  OPTIONAL,
     userData             [3]   CHOICE {
                                plaintextBIT STRING,
                                ciphertext    OCTET STRING
                    }                            OPTIONAL,
     directionIndicator   [4]   BOOLEAN                OPTIONAL
   }


Baize, Farrell, Parker     Document Expiration: 22 May 1997   [Page 47]







internet-draft                                       November 22, 1996

   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
   }

   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]   SecurityAttribute        OPTIONAL,

Baize, Farrell, Parker     Document Expiration: 22 May 1997   [Page 48]







internet-draft                                       November 22, 1996

     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{
     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]



Baize, Farrell, Parker     Document Expiration: 22 May 1997   [Page 49]







internet-draft                                       November 22, 1996

   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
   }

   TargetAEFPart ::=  SEQUENCE {
     pacAndCVs          [0]   SEQUENCE OF CertandECV OPTIONAL,
     targetKeyBlock     [1]   TargetKeyBlock,
     dialogueKeyBlock   [2]   DialogueKeyBlock,
     targetIdentity     [3]   SecurityAttribute,
     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
   }


   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,
   }

Baize, Farrell, Parker     Document Expiration: 22 May 1997   [Page 50]







internet-draft                                       November 22, 1996

   TrustGroupValueSyntax ::=  Identifier

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

   Validity ::= SEQUENCE {
            notBefore     UTCTime,
            notAfter      UTCTime
   } -- as in [ISO/IEC 9594-8]
   -- 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}

Baize, Farrell, Parker     Document Expiration: 22 May 1997   [Page 51]







internet-draft                                       November 22, 1996

   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,
     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)}



Baize, Farrell, Parker     Document Expiration: 22 May 1997   [Page 52]







internet-draft                                       November 22, 1996

   TransitedEncoding ::=  SEQUENCE {

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

   END

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

Baize, Farrell, Parker     Document Expiration: 22 May 1997   [Page 53]







internet-draft                                       November 22, 1996

                            -- verification key

     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
                        }
                        )
   END

Baize, Farrell, Parker     Document Expiration: 22 May 1997   [Page 54]







internet-draft                                       November 22, 1996

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

Baize, Farrell, Parker     Document Expiration: 22 May 1997   [Page 55]







internet-draft                                       November 22, 1996


   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




























Baize, Farrell, Parker     Document Expiration: 22 May 1997   [Page 56]







internet-draft                                       November 22, 1996

APPENDIX B: 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.

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

B.2.  Profile of PublicTicket as used in hybridInterdomain scheme

     Field                  Value/Constraint
     -----                  ----------------
     krb5Ticket
     - tkt-vno              5
     - 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)

Baize, Farrell, Parker     Document Expiration: 22 May 1997   [Page 57]







internet-draft                                       November 22, 1996

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

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



Baize, Farrell, Parker     Document Expiration: 22 May 1997   [Page 58]







internet-draft                                       November 22, 1996

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





































Baize, Farrell, Parker     Document Expiration: 22 May 1997   [Page 59]







internet-draft                                       November 22, 1996


APPENDIX C: 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
   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.

































Baize, Farrell, Parker     Document Expiration: 22 May 1997   [Page 60]