Internet-Draft ERIC BAIZE, BULL IETF Common Authentication Technology WG STEPHEN FARRELL, SSE TOM PARKER, ICL November 21, 1995 The SESAME GSS-API Mechanism STATUS OF THIS MEMO This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." To learn the current status of any Internet Draft, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). Comments on this document should be sent to "cat-ietf@mit.edu", the IETF Common Authentication Technology WG discussion list. ABSTRACT This specification defines protocols, data elements, and conventions to be employed by peers implementing the Generic Security Service Application Program Interface (as specified in RFCs 1508 and 1509) when using the SESAME Mechanism. 1. BACKGROUND In most systems of today, protection of resources in a distributed computing environment is principally achieved by direct login to each end-system accessed, using passwords transmitted in clear and unprotected. This has a number of drawbacks: firstly it is not very secure; secondly it is not convenient to have to remember several passwords, and thirdly the user is not known as one single user to the distributed system as a whole - there is no co-ordination of his use of the distributed system across the different servers of the system. To find solutions to these and related problems, work has been underway for a number of years in Europe, under the aegis of ECMA, to develop security standards for open systems. The SESAME Baize, Farrell, Parker Document Expiration: 21 May 1996 [Page 1] internet-draft November 21, 1995 project, initiated in the wake of the ECMA work by the Commission of the European Communities (CEC), has implemented a profile of the ECMA standards. This draft specifies the use of the security protocols implemented in the SESAME project in a GSS-API [GSSAPI] environment. A more complete overview of SESAME is available in [SESOV]. 1.1 Table of Contents 1. BACKGROUND 1 1.1 TABLE OF CONTENTS 2 1.2 ACKNOWLEDGEMENTS 3 2. THE SESAME TECHNOLOGY 3 2.1 OVERVIEW 3 2.2 SESAME CONCEPTS 4 2.2.1 SESAME ACCESS CONTROL CONCEPTS 4 2.2.2 TARGET ACCESS ENFORCEMENT FUNCTION 7 2.2.3 SESAME KEY DISTRIBUTION 8 2.2.4 USE OF CRYPTOGRAPHY IN SESAME 10 3. GSS-API TOKEN FORMATS 10 3.1 TOKEN FRAMINGS 10 3.2 INITIALCONTEXTTOKEN FORMAT 12 3.3 TARGETRESULTTOKEN 15 3.4 ERRORTOKEN 16 3.5 PER MESSAGE TOKENS 17 3.5.1 MICTOKEN 18 3.5.2 WRAPTOKEN 19 3.6 CONTEXTDELETETOKEN 19 4. DATA ELEMENT DEFINITIONS 20 4.1 ACCESS CONTROL DATA ELEMENTS 20 4.1.1 GENERALISED CERTIFICATE 20 4.1.2 SECURITY ATTRIBUTES 25 4.1.3 PAC CONTENTS 26 4.1.4 PROTECTION METHODS 28 4.1.5 EXTERNAL CONTROL VALUES CONSTRUCT 33 4.2 BASIC KEY DISTRIBUTION 34 4.2.1 KEYING INFORMATION SYNTAX 34 4.2.2 OBJECT IDENTIFIERS 36 4.2.3 HYBRID INTER-DOMAIN KEY DISTRIBUTION SCHEME DATA ELEMENTS 37 4.2.4 KEY ESTABLISHMENT DATA ELEMENTS 38 4.2.5 KERBEROS DATA ELEMENTS 39 4.2.6 PROFILING OF KD-SCHEMES 39 4.3 DIALOGUE KEY BLOCK 42 4.4 ATTRIBUTE DEFINITIONS 43 4.4.1 PRIVILEGE ATTRIBUTES 44 4.4.2 MISCELLANEOUS ATTRIBUTES 45 4.4.3 QUALIFIER ATTRIBUTES 45 5. ALGORITHMS AND CIPHERTEXT FORMATS 46 Baize, Farrell, Parker Document Expiration: 21 May 1996 [Page 2] internet-draft November 21, 1995 6. SESAME MECHANISM NEGOTIATION 48 7. NAME TYPES 50 7.1 KERBEROS NAMING 50 7.2 DIRECTORY NAMING 51 8. ERROR CODES 52 9. SECURITY CONSIDERATIONS 52 10. REFERENCES 52 11. AUTHOR'S ADDRESSES 53 APPENDIX A: ASN.1 MODULE DEFINITIONS 53 A.1 SESAME ASN.1 DEFINITIONS 53 A.2 KERBEROS ASN.1 DEFINITIONS 62 A.3 SPKM ASN.1 DEFINITIONS 64 APPENDIX B: ECMA BACKGROUND MATERIAL. 68 APPENDIX C: SESAME IMPLEMENTATION STATUS 68 1.2 Acknowledgements The SESAME project has been carried out by Bull SA, ICL and Siemens (SNI, Siemens ZFE and SSE) under part funding from the CEC as RACE project R2051. The SESAME GSS-API protocols re-use data structures developed in Kerberos V5 [Kerberos] and SPKM [SPKM] for key management and authentication. SESAME has merged these into a wider framework supporting distributed access control and delegation features. With apologies to those omitted, the following are amongst the people who have made significant contributions to the ECMA and SESAME work: Helmut Baumgaertner, John Cosgrove, Hiep Doan, Belinda Fairthorne, Peter Hartmann, Keith Howker, Per Kaijser, Jacques Lebastard, Ronan Long, Piers McMahon, Frank O'Dwyer, Denis Pinkas, Mike Roe, Laurent Rouilhac, Don Salmon, Asmund Skomedal and Mark Van DenWauver. 2. THE SESAME TECHNOLOGY 2.1 Overview SESAME supports authentication, access control, communication integrity and communication confidentiality, and offers the means to ensure that access to services is policed to the appropriate level of security. The SESAME authentication service supports authentication using either the Kerberos V5 protocols or public key technology (based on X.511). In SESAME then, principals may authenticate using either a password or their private key. After successful authentication by an Authentication Server (AS), the initiator obtains a ticket (a "PAS Ticket") which he can Baize, Farrell, Parker Document Expiration: 21 May 1996 [Page 3] internet-draft November 21, 1995 present to a Privilege Attribute Server (PAS) to obtain proof of his access rights in the form of a Privilege Attribute Certificate (PAC) which is a specific form of the Access Control Certificate defined in [ISO 10181-3], the Access Control Framework. Having selected a target application, the initiator requires keying information which, in SESAME provides two functions: - PAC protection, in order to prevent anybody but the owner or authorised delegates making use of the PAC, and, - key distribution, to support integrity or confidentiality protection of application data. Depending on whether the initiator and/or target make use of asymmetric or symmetric key technology for key distribution, the keying information is either fully constructed by the initiator or constructed with the assistance of a Key Distribution Service (KDS). The PAC and the keying information are then presented by the initiator to the target application in an initial context token. An access control decision can then be made based on the initiator's security attributes and the access control information attached to the controlled resource. Some extensions to the base GSS-API are required in order for applications to take full advantage of the access control and delegation capabilities of SESAME. As these extensions are independent of the SESAME mechanism they are specified in a separate draft [XGSSAPI]. Having established a security context the initiator and target application can then use the per message protection services provided by GSS-API. This draft specifies the exchanges between initiator and target which take place in this environment. 2.2 SESAME Concepts The next sections contain very brief descriptions of the key concepts from the ECMA architecture which are implemented in SESAME. For full details refer to [SESOV]. 2.2.1 SESAME Access Control Concepts 2.2.1.1 Domains A `security domain' is a set of elements, a security authority Baize, Farrell, Parker Document Expiration: 21 May 1996 [Page 4] internet-draft November 21, 1995 and a set of security relevant activities in which the set of elements are subject to the security policy, administered by the security authority, for the specified activities [ISO 10181-1]. In the current SESAME UNIX implementation there is one authentication service (AS), privilege attribute service (PAS) and key distribution service (KDS) per domain. 2.2.1.2 Identity Identity is a real world attribute having multiple uses in computer systems. Amongst the uses to which identity may be put are: - as a means of claiming who you are, i.e. it is what you present when logging on to a system to help the system locate the authentication information that it will use to verify your claim. Call this use "Login", - as a means of making you accountable for your actions, i.e. it is the identity that appears in audit trails. Call this use "Audit", - as a means of obtaining access to protected objects, for example the identity that appears in an Access Control List. Call this use "Access", - as a means of locating and permitting the release of your Privilege Attributes within a Privilege Attribute Service. This is a special case of the "Access" use. Call this use "Access to Privilege Attributes". All of these uses could in theory be encompassed by implementing one single type of attribute called "Identity Attribute" used for everything, and this is commonly done; however this results in there being a number of security policies that are impossible to implement. The question now arises: In order to support a reasonable spectrum of real world security policies, how many separate types of identity attribute is it appropriate to support in a distributed security architecture? The SESAME answer is: potentially all of them, but the identity used for login (the "Login Name") need not appear other than as a parameter in authentication exchanges. Most of the others are optional. The names that have been chosen for the identity attribute types that are supported in SESAME are as follows: Authenticated Identity which in SESAME is the identity held in the PAS ticket obtained from Authentication Server. This is used for "Access to Privilege Attributes", Access Identity which is used in PACs for "Access" In SESAME this attribute reflects a value given by the PAS administrator, Baize, Farrell, Parker Document Expiration: 21 May 1996 [Page 5] internet-draft November 21, 1995 Audit Identity which is used in PACs for "Audit". In SESAME this is a separate field in the PAC, which reflects a value given by the PAS administrator. 2.2.1.3 Privilege Attributes SESAME is designed to cater for heterogeneous systems where users need to access UNIX applications as well as proprietary applications in the same session. The user's security manager does not have to manage separate sets of Privilege Attributes for each of end-system even if they handle the same global values in different ways. ECMA addressed this problem by defining standard Privilege Attribute types that are independent of specific end-system representations but which can be mapped as appropriate in the receiving system. When a SESAME user is granted membership of e.g. a group, this can be represented once as a Privilege Attribute in a global form. The privilege attributes which are supported in this draft are: access identity primary group group role SESAME also allows for domain defined attributes (i.e. defined by the PAS administrator) to be placed in the PAC. 2.2.1.4 Roles SESAME supports access control policies based on the concept of a user's organisational role or job. A user working in a particular role is likely to need particular privileges and controls which give the required access to particular applications and services. For example, he may need to be a member of a particular group and have access to particular target application groups. The administrator defines a set of Privilege Attributes which are associated with a role, and the controls (see later) which are to apply to their use. The administrator also defines which users can take which roles. Some of the advantages of role based access control are: - the user does not need to be aware of the Privilege Attributes he has. The most he needs to know are his different role names (e.g. quality controller, or pay clerk) and select one of these. However he does not necessarily even need to know these since he always has either an individual default role name or Baize, Farrell, Parker Document Expiration: 21 May 1996 [Page 6] internet-draft November 21, 1995 the system default role name, - if the user changes job, once the administrator has updated his roles, when he next uses the system, he automatically gets the privileges associated with the new job, - administration is significantly simplified if many users take the same role, as the set of Privilege Attributes for the role only need to be defined once, - if a specific "Role" Privilege Attribute is associated with the job role, access control in applications can be based on this, rather than on individual user identities, thus simplifying administration of the target system. 2.2.1.5 Access Paths and Delegation Distributed systems commonly contain application services that are themselves distributed over a number of servers. An initiator accessing such a service may not know which server can support its requests, and may simply make a request on a convenient server, expecting that server to act as its delegate with respect to another server if necessary. This delegation could be repeated until the server that can handle the request directly is found. An initiator may not wish to delegate all his rights, and may also want to restrict the area within which the PAC may be used. For that purpose, PACs can be arranged to be valid only for specific nominated targets. A PAC may contain many target names. Mechanisms are provided to prevent a PAC from being delegated where this is appropriate. In fact the same PAC can be sometimes delegatable, sometime not. 2.2.1.6 Application trust Groups A PAC may contain one or more target or delegate application or "Trust Group" names specifying which targets or delegate-targets the PAC is valid for. A Trust Group name is simply the name of a group of applications, defined by the security administrator, that mutually trust each other not to spoof each others' identities. In order to allow for a PAC which is usable at all targets a special trust group is defined - the "universal" trust group. A PAC targeted at the universal trust group can still be protected using target controls (as in delegation) which means that such a PAC still cannot be stolen. 2.2.2 Target Access Enforcement Function In SESAME the security processing functionality on the target is split between two different entities - the target application and the target access enforcement function (targetAEF). ISO [ISO/IEC Baize, Farrell, Parker Document Expiration: 21 May 1996 [Page 7] internet-draft November 21, 1995 10181-3] defines an Access Enforcement Function to be something collocated with a target application which controls access to that target application. This has a number of advantages: - the security critical code is isolated which makes security evaluation simpler, - administration is simplified as one targetAEF may "serve" many target applications, - the number of long-term keys in the system can be reduced since only the targetAEF need share a symmetric key with the security server or possess a key pair, - different administrators can be responsible for the target application and targetAEF, - as the initiator establishes a key with the targetAEF (see later) this keying information can be re-used whenever another target on the same machine is accessed. The functions for which the targetAEF is responsible are: - processing of keying information (resulting in the establishment of a shared symmetric key between initiator and target) - PAC validation; including e.g. checking that the PAS that produced the PAC is trusted, the timeliness of the PAC, and its cryptographic correctness - target access control; releasing the established keys to the appropriate target application In the UNIX SESAME implementation, the targetAEF is implemented as a separate daemon per machine which deals with all target applications on that machine. The SESAME GSS-API library linked to the target application communicates with this process. Of course, none of this precludes the targetAEF being linked to the target in other implementations (e.g. on Windows) - however, in such cases some of the above advantages are lost. 2.2.3 SESAME Key Distribution There are three different key distribution schemes in SESAME. Each depends upon the existence of long term cryptographic keys which held by targetsAEFs and KDSs. These keys may be either symmetric or asymmetric. In the case where the keys are symmetric they are always shared between the targetAEF and its KDS. In the case where the long term keys are asymmetric we speak of, for example, the KDS's private key. Initiators may also possess symmetric or asymmetric keys. In the case where an initiator possesses a symmetric key this will have been established as a result of an earlier authentication. SESAME can be extended to support other variants, e.g. where the Baize, Farrell, Parker Document Expiration: 21 May 1996 [Page 8] internet-draft November 21, 1995 initiator shares a symmetric key with a KDS and the targetAEF possesses a key pair. 2.2.3.1 Basic keys and dialogue keys In SESAME two separate keys which are established between the initiator and target for the purpose of application data protection. These are known as the integrity and confidentiality dialogue keys and are always symmetric. Another symmetric key, called the basic key, is established between the initiator and targetAEF which is used in PAC protection and to derive the dialogue keys. The basic key is transmitted from the initiator to the target in a structure called a TargetKeyBlock. The information required to derive the dialogue keys is transmitted in a structure called a DialogueKeyPackage. 2.2.3.2 Basic symmetric key distribution scheme (symmIntradomain) In this scheme, the initiator and the targetAEF each share different secret keys with the same KDS. To establish a basic key between an initiator and a targetAEF, the initiator KDS returns, as a result of an initiator request, a targetKeyBlock containing a basic key encrypted under the targetAEF's long term secret key. On receipt of the targetKeyBlock, the targetAEF can extract the basic key directly from it. An unmodified Kerberos TGS can be used as the KDS in this case. 2.2.3.3 Symmetric key distribution scheme with asymmetric KDSs (hybridInterdomain) In this scheme, the initiator shares a key with a KDS that is different from the KDS with which the targetAEF shares its long term key. In addition, each KDS possesses an asymmetric key pair. To establish a basic key between an initiator and a targetAEF, the initiator KDS returns, as a result of an initiator request, a TargetKeyBlock containing a basic key encrypted under a temporary key and the temporary key encrypted under the targetAEF KDS's public key. The TargetKeyBlock is signed using the initiator KDS's private key. On receipt of the TargetKeyBlock, the targetAEF transmits it to its own KDS, and gets back the basic key encrypted under the long term secret key it (the targetAEF) shares with its KDS. Baize, Farrell, Parker Document Expiration: 21 May 1996 [Page 9] internet-draft November 21, 1995 A modified Kerberos TGS can be used as the KDS in this case. 2.2.3.4 Full public key distribution scheme (asymmetric) In this scheme, neither the initiator nor the targetAEF uses a KDS. Both the initiator and the targetAEF possesses a private/public key pair. To establish a basic key with a targetAEF, the initiator constructs a TargetKeyBlock containing a basic key encrypted under the targetAEF's public key. The TargetKeyBlock is signed using the initiator's private key. On receipt of the TargetKeyBlock, the targetAEF directly establishes a basic key from it. Modified SPKM handling code can be used for this scheme. 2.2.3.5 Derivation of Dialogue Keys Once a basic key has been established between the initiator and targetAEF, the derivation of the dialogue keys can take place. The dialogue keys are derived using key offsetting - see the description of the dialogue key package below. 2.2.4 Use of Cryptography in SESAME In several countries of the world the use of cryptography is subject to government control, particularly in relation to the hiding of information by enciphering it. The SESAME architecture has been designed to address these problems. The use of confidentiality is kept to a minimum. It is provided only where it is an essential function (for example in the SESAME key distribution protocols it is necessary to encipher the basic key being distributed). PACs are cryptographically signed, not enciphered. When encipherment of user and system data is a requirement, SESAME allows the algorithms and keys used to be separately specified, permitting them to have characteristics acceptable to the prevailing political environment. 3. GSS-API TOKEN FORMATS This section describes protocol-visible characteristics of the GSS-API as implemented above the SESAME mechanism. 3.1 Token framings Following [GSS-API], tokens are enclosed within framing as follows: Baize, Farrell, Parker Document Expiration: 21 May 1996 [Page 10] internet-draft November 21, 1995 Token ::= [APPLICATION 0] IMPLICIT SEQUENCE { thisMech MechType, -- the OBJECT IDENTIFIER specified below innerContextToken ANY DEFINED BY thisMech } The SESAME mechanism type is identified by an OBJECT IDENTIFIER with value: { generic-sesame-mech (y) (z) } Where: generic-sesame-mech ::=OBJECT IDENTIFIER { tbs } The values of y and z represent architectural options and cryptographic algorithm profiles which are specified in section 5. These values are intended to be negotiated using a generic GSS- API mechanism negotiation scheme like that given in [SNEGO]. The above GSS-API framing is to be applied to all tokens emitted by the SESAME GSS-API mechanism, including context-establishment tokens, per-message tokens, and context-deletion token. The innerContextToken field of context establishment tokens for the SESAME GSS-API mechanism will consist of a SESAME token (InitialContextToken, TargetResultToken, ErrorToken) containing a token identifier (tokenId) field having the value 01 00 (hex) for InitialContextToken, 02 00 (hex) for TargetResultToken, and 03 00 (hex) for ErrorToken. These are defined to be: InitialContextToken sent by the initiator to a target, to start the process of establishing a Security Association. Returned by the GSS_Init_sec_context call. TargetResultToken sent to the initiator by the target following receipt of an Initial Context Token. Returned by the GSS_Accept_sec_context call. ErrorToken sent by target on detection of an error during Security Association establishment. Returned by either the GSS_Init_sec_context call or the GSS_Accept_sec_context call. The innerContextToken field of per-message tokens for the SESAME GSS-API mechanism will consist of a SESAME token (MICToken, WrapToken) containing a tokenId field having the value 01 01 (hex) for MICToken, and 02 01 (hex) for WrapToken. These are defined to be: Baize, Farrell, Parker Document Expiration: 21 May 1996 [Page 11] internet-draft November 21, 1995 MICToken sent either by the initiator or the target to verify the integrity of the user data sent separately. Returned by GSS_GetMIC. WrapToken sent either by the initiator or the target. Encapsulates the input user data (optionally encrypted) along with integrity check values. Returned by GSS_Wrap. The innerContextToken field of context-deletion token for the SESAME GSS-API mechanism will consist of a SESAME token (ContextDeleteToken) containing a tokenId field having the value 01 02 (hex). This is defined to be: ContextDeleteToken sent either by the initiator, or the target to release a Security Association. Returned by GSS_Delete_sec_context. 3.2 InitialContextToken format This construct provides for the carrying of the following Security Association information: - replay protection, - keying information for establishing both the key for protecting the exchange of context tokens, including this one, and keys for later use in protecting user data exchanges, - access control information (ACI) used to determine what access is to be granted by the target to the initiator of the Security Association, - information to control the applicability of the ACI (e.g. whether delegation is permissible, or identifying for which targets the access rights are valid), - information to protect the ACI from being tampered with or stolen, - accountability information for use in audit trails. InitialContextToken ::= SEQUENCE{ ictContents [0] ICTContents, ictSeal [1] Seal } ictContents Body of the initial context token ictSeal Seal of ictContents computed with the integrity dialogue key. Only the sealValue field of the Seal data structure is present. The cryptographic algorithms that apply are specified by integDKUseInfo in the dialogueKeyBlock field of the initial context token. Baize, Farrell, Parker Document Expiration: 21 May 1996 [Page 12] internet-draft November 21, 1995 ICTContents ::= SEQUENCE { tokenId [0] INTEGER, -- shall contain X'0100' SAId [1] OCTET STRING, targetAEFPart [2] TargetAEFPart, targetAEFPartSeal [3] Seal, contextFlags [4] BIT STRING { delegation (0), mutual-auth (1), replay-detect (2), sequence (3), conf-avail (4), integ-avail (5) } utcTime [5] UTCTime OPTIONAL, usec [6] INTEGER OPTIONAL, seq-number [7] INTEGER OPTIONAL, initiatorAddress [8] HostAddress OPTIONAL, targetAddress [9] HostAddress OPTIONAL -- imported from [Kerberos] and used as channel bindings } tokenId Identifies the initial-context token. Its value is 01 00 (hex) SAId A random number for identifying the Security Association being formed; it is one which (with high probability) has not been used previously. This random number is generated by the initiator GSS- API implementation and processed by the target GSS-API implementation as follows : - If no targetResultToken is expected, the SAId value is taken to be the identifier of the Security Association being established (if this is unacceptable to the target, then an error token with etContents value of gss_ses_s_sg_sa_already_established must be generated). - If a targetResultToken is expected, the target generates its random number and concatenates it to the end on the initiator's random number. The concatenated value is then taken to be the identifier of the Security Association being established. targetAEFPart Part of the initial-context token to be passed to the target access enforcement function. targetAEFPartSeal Seal of the targetAEFPart computed with the basic key. Only the sealValue field of the Seal data structure is present. The cryptographic algorithms that apply are specified by algorithm Baize, Farrell, Parker Document Expiration: 21 May 1996 [Page 13] internet-draft November 21, 1995 profile in the SESAME mechanism option (see section 6). contextFlags Combination of flags that indicates context-level functions requested by the GSS-API initiator implementation. delegation when set to 0, indicates that the initiator explicitly forbids delegation of the PAC in the targetAEFPart. mutual-auth indicates that mutual authentication is requested. replay-detect indicates that replay detection features are requested to be applied to messages transferred on the established Security Association. sequence indicates that sequencing features are requested to be enforced to messages transferred on the established Security Association. conf-avail indicates that a confidentiality service is available on the initiator side for the established Security Association. integ-avail indicates that an integrity service is available on the initiator side for the established Security Association. utcTime The initiator's UTC time. usec Micro second part of the initiator's time stamp. This field along with utcTime are used together to specify a reasonably accurate time stamp seq-number When present, specifies the initiator's initial sequence number. Otherwise, the default value of 0 is to be used as an initial sequence number. initiatorAddress Initiator's network address part of the channel bindings. This field is only present when channel bindings are transmitted by the GSS-API caller to the SESAME GSS-API implementation. targetAddress Target's network address part of the channel bindings. This field is only present when channel bindings are transmitted by the GSS- API caller to the SESAME GSS-API implementation. TargetAEFPart ::= SEQUENCE { pacAndCVs [0] SEQUENCE OF CertandECV OPTIONAL, targetKeyBlock [1] TargetKeyBlock, dialogueKeyBlock [2] DialogueKeyBlock, Baize, Farrell, Parker Document Expiration: 21 May 1996 [Page 14] internet-draft November 21, 1995 targetIdentity [3] Identifier, flags [4] BIT STRING { delegation (0) } } Note 1: SESAME Validity philosophy is that individual PACs have validity of their own, and that it is not sensible to have an overall separately specified validity period for the whole context. Note 2: SESAME does not permit the target to opt for a shorter validity time than that specified by the initiator. If it wants to cut off the context earlier it just does it, returning an appropriate error. pacAndCVs The initiator ACI to be used for this Security Association. This field is not present when the association does not require any ACI. This field contains the PAC together with associated PAC protection information. In this specification exactly one of these should be present. targetKeyBlock The targetKeyBlock carrying the basic key to be used for the Security Association being established. dialogueKeyBlock A dialogue key block used by the targetAEF along with the basic key to establish an integrity dialogue key and a confidentiality dialogue key for per-message protection over the Security Association being established. targetIdentity The identity of the intended target of the Security Association. Used by the targetAEF to validate the PAC. Can also be used by the targetAEF to help protect the delivery of dialogue keys. flags flags required by the Target AEF for its validation process. Only contains a delegation flag, the value of which is the same as the value of delegation flag in contextFlag field of ictContents. When the flag is set, all ECVs sent in pacAndCVs are made available to the target. Other bits are reserved for future use. 3.3 TargetResultToken This token is returned by the target if the mutual-req flag is set in the Initial Context Token. It serves to authenticate the target to the initiator, since only the genuine target could derive the integrity dialogue key needed to seal the TargetResultToken. Baize, Farrell, Parker Document Expiration: 21 May 1996 [Page 15] internet-draft November 21, 1995 TargetResultToken ::= SEQUENCE{ trtContents [0] TRTContents, trtSeal [1] Seal } TRTContents ::= SEQUENCE { tokenId [0] INTEGER, -- shall contain X'0200' SAId [1] OCTET STRING, utcTime [5] UTCTime OPTIONAL, usec [6] INTEGER OPTIONAL, seq-number [7] INTEGER OPTIONAL, } Note: There is no field for returning certification data here. This is because any such data that may be required is assumed to be returned at the conclusion of mechanism negotiation. trtContents This contains only administrative fields, identifying the token type, the context and providing exchange integrity. seq-number When present, specifies the target's initial sequence number, otherwise, the default value of 0 is to be used as an initial sequence number. The other administrative fields are as described in above. trtSeal Seal of trtContents computed with the integrity dialogue key. Only the sealValue field of the Seal data structure is present. The cryptographic algorithms that apply are specified by integDKUseInfo in the dialogueKeyBlock field of the initial context token. 3.4 ErrorToken ErrorToken ::= { tokenType [0] OCTET STRING VALUE X'0400', etContents [1] ErrorArgument, } etContents Contains the reason for the creation of the error token. The different reasons are given as minor status return values. ErrorArgument ::= ENUMERATED { gss_ses_s_sg_server_sec_assoc_open (1), gss_ses_s_sg_incomp_cert_syntax (2), Baize, Farrell, Parker Document Expiration: 21 May 1996 [Page 16] internet-draft November 21, 1995 gss_ses_s_sg_bad_cert_attributes (3), gss_ses_s_sg_inval_time_for_attrib (4), gss_ses_s_sg_pac_restrictions_prob (5), gss_ses_s_sg_issuer_problem (6), gss_ses_s_sg_cert_time_too_early (7), gss_ses_s_sg_cert_time_expired (8), gss_ses_s_sg_invalid_cert_prot (9), gss_ses_s_sg_revoked_cert (10), gss_ses_s_sg_key_constr_not_supp (11), gss_ses_s_sg_init_kd_server_ unknown (12), gss_ses_s_sg_init_unknown (13), gss_ses_s_sg_alg_problem_in_dialogue_key_block (14), gss_ses_s_sg_no_basic_key_for_dialogue_key_block (15), gss_ses_s_sg_key_distrib_prob (16), gss_ses_s_sg_invalid_user_cert_in_key_block (17), gss_ses_s_sg_unspecified (18), gss_ses_s_g_unavail_qop (19), gss_ses_s_sg_invalid_token_format (20) } 3.5 Per Message Tokens The syntax of the Per Message Token has the same general structure for both MIC and Wrap tokens: PMToken ::= SEQUENCE{ pmtContents [0] PMTContents, pmtSeal [1] Seal -- seal over the pmtContents being protected } PMTContents ::= SEQUENCE { tokenId [0] INTEGER, -- shall contain X'0101' SAId [1] OCTET STRING, seq-number [2] INTEGER OPTIONAL, userData [3] CHOICE { plaintextBIT STRING, ciphertext OCTET STRING } OPTIONAL, directionIndicator [4] BOOLEAN OPTIONAL } pmtContents tokenId SAId See above for a description of these fields seq-number This field must be present if replay detection or message Baize, Farrell, Parker Document Expiration: 21 May 1996 [Page 17] internet-draft November 21, 1995 sequencing have been specified as being required at Security Association initiation time. The field contains a message sequence number whose value is incremented by one for each message in a given direction, as specified by directionIndicator. The first message sent by the initiator following the InitialContextToken shall have the message sequence number specified in that token, or if this is missing, the value 0. The first message returned by the target shall have the message sequence number specified in the TargetReplyToken if present, or failing this, the value 0. The receiver of the token will verify the sequence number field by comparing the sequence number with the expected sequence number and the direction indicator with the expected direction indicator. If the sequence number in the token is higher than the expected number, then the expected sequence number is adjusted and GSS_S_GAP_TOKEN is returned. If the token sequence number is lower than the expected number, then the expected sequence number is not adjusted and GSS_S_DUPLICATE_TOKEN or GSS_S_OLD_TOKEN is returned, whichever is appropriate. If the direction indicator is wrong, then the expected sequence number is not adjusted and GSS_S_UNSEQ_TOKEN is returned userData See specific token type narratives below. directionIndicator FALSE indicates that the sender is the context initiator, TRUE that the sender is the target. pmtSeal See specific token type narratives below. 3.5.1 MICToken Use of the GSS_Get_MIC() call yields a per-message token, separate from the user data being protected, which can be used to verify the integrity of that data as received. The token and the data may be sent separately by the sending application and it is the receiving application's responsibility to associate the received data with the received token. The syntax of the token is: MICToken ::= PMToken The overall structure and field contents of the token are described above. Fields specific to the MICToken are: userData Not present for MIC Tokens. Baize, Farrell, Parker Document Expiration: 21 May 1996 [Page 18] internet-draft November 21, 1995 pmtSeal The Checksum is calculated over the DER encoding of the pmtContents field with the user data temporarily placed in the userData field. The userData field is not transmitted. 3.5.2 WrapToken Use of the GSS_Wrap() call yields a token which encapsulates the input user data (optionally encrypted) along with associated integrity check values. The token emitted by GSS_Wrap() consists of an integrity header followed by a body portion that contains either the plaintext data (if conf_alg = NULL) or encrypted data. The syntax of the token is: WrapToken ::= PMToken The overall structure and field contents of the token are described above. Fields specific to the WrapToken are: userData Present either in plain text form (the choice is plaintext), or encrypted (choice ciphertext). If the data is encrypted, it is performed using the Confidentiality Dialogue Key, and as in [Kerberos], an 8-byte random confounder is first prepended to the data to compensate for the fact that an IV of zero is used for encryption. wtSeal The Checksum is calculated over the pmtContents field, including the userData. However if the userData field is to be encrypted, the seal value is computed prior to the encryption. 3.6 ContextDeleteToken The ContextDeleteToken is issued by either the context initiator or the target to indicate to the other party that the context is to be deleted. ContextDeleteToken ::= SEQUENCE { cdtContents [0] CDTContents, cdtSeal [1] Seal -- seal over cdtContents, encrypted -- under the Integrity Dialogue Key -- contains only the sealValue field } CDTContents ::= SEQUENCE { tokenType [0] OCTET STRING VALUE X'0301', SAId [1] OCTET STRING, Baize, Farrell, Parker Document Expiration: 21 May 1996 [Page 19] internet-draft November 21, 1995 utcTime [2] UTCTime OPTIONAL, usec [3] INTEGER OPTIONAL, seq-number [4] INTEGER OPTIONAL, } cdtContents This contains only administrative fields, identifying the token type, the context and providing exchange integrity. seq-number When present, this field contains a value one greater than that of the seq-number field of the last token issued from this issuer. The other administrative fields are as described above. trtSeal See above for a general description of the use of this construct. 4. DATA ELEMENT DEFINITIONS In this section we give the details of the structures which are present in the tokens defined above. These ASN.1 definitions represent the profile of the ASN.1 types defined in [ECMA-219] which are implemented in the SESAME project. In some cases CHOICEs and OPTIONAL fields which are defined by ECMA have been omitted as they are not supported in this version of SESAME. In order to retain compatibility this leads to a non-obvious numbering for tags. In this specification all of the type specifying object identifiers are below the arc: generic-sesame-oids ::= OBJECT IDENTIFIER { tbs } -- top of the SESAME types arc 4.1 Access Control Data Elements The ASN.1 definitions for the PAC and related data structures. 4.1.1 Generalised certificate A Generalised Certificate (PAC) is composed of three main structural components : The "commonContents" fields collectively serve to provide generally required management and control over the use of the PAC. The "specificContents" fields are different for different types Baize, Farrell, Parker Document Expiration: 21 May 1996 [Page 20] internet-draft November 21, 1995 of certificate, and contain a type identifier to indicate the type. In this draft only one type is defined: the Privilege Attribute Certificate (PAC). The "checkValue" fields are used to guarantee the origin of the certificate. GeneralisedCertificate ::= SEQUENCE{ certificateBody [0] CertificateBody, checkValue [1] CheckValue} CertificateBody ::= CHOICE{ encryptedBody [0] BIT STRING, normalBody [1] SEQUENCE{ commonContents [0] CommonContents, specificContents[1] SpecificContents } } The next sections describe these three main structural components of the Generalised Certificate. 4.1.1.1 Common Contents fields CommonContents ::= SEQUENCE{ comConSyntaxVersion [0] INTEGER { version1 (1) }DEFAULT 1, issuerDomain [1] Identifier OPTIONAL, issuerIdentity [2] Identifier, serialNumber [3] INTEGER, creationTime [4] UTCTime OPTIONAL, validity [5] Validity, algId [6] AlgorithmIdentifier, hashAlgId [7] AlgorithmIdentifier OPTIONAL } Note: In the imported definition of AlgorithmIdentifier, ISO currently permits both a hash and a cryptographic algorithm to be specified. If this is done, they must appear in the algId field. The hashAlgId field is present for those cases where a separate hash algorithm specification is required. Identifier ::= CHOICE{ objectId [0] OBJECT IDENTIFIER, directoryName [1] Name, -- imported from the Directory Standard printableName [2] PrintableString, octets [3] OCTET STRING, intVal [4] INTEGER, bits [5] BIT STRING, Baize, Farrell, Parker Document Expiration: 21 May 1996 [Page 21] internet-draft November 21, 1995 pairedName [6] SEQUENCE{ printableName [0] PrintableString, uniqueName [1] OCTET STRING } } Validity ::= SEQUENCE { notBefore UTCTime, notAfter UTCTime } -- as in [ISO/IEC 9594-8] -- Note: Validity is not tagged, for compatibility with the -- Directory Standard. comConFieldsSyntaxVersion Identifies the version of the syntax of the combination of the commonContents and the checkValue fields parts of the certificate. issuerDomain The security domain of the issuing authority. Not required if the form of issuerIdentity is a full distinguished name, but required if other forms of naming are in use, such as proprietary identifiers. issuerIdentity The identity of the issuing authority for the certificate. Note Identifier is a general syntax which is used for all fields containing names or identifiers of various kinds. It can take any of the forms listed: object identifier, Directory DN or RDN, a printable name, an octet string, an integer value, a bit string or a paired value consisting of readable and unique components. serialNumber The serial number of the certificate (PAC) as allocated by the issuing authority. creationTime The UTC time that the certificate was created, according to the authority that created it. validity A pair of start and end times within which the certificate is deemed to be valid. algId The identifier of the symmetric or of the asymmetric cryptographic algorithm used to seal or to sign the certificate. If there is a single identifier for both the encryption algorithm Baize, Farrell, Parker Document Expiration: 21 May 1996 [Page 22] internet-draft November 21, 1995 and the hash function, it appears in this field. hashAlgId The identifier of the hash algorithm used in the seal or in the signature. 4.1.1.2 Specific Certificate Contents SpecificContents ::= CHOICE{ pac [1] PACSpecificContents -- only the PAC is used here } SpecificContents pac The PAC specific contents defined below. 4.1.1.3 Check value In this specification a PAC is protected using by being digitally signed by the issuer. A signature may be accompanied by information identifying the Certification Authority under which the signature can be verified, and with an optional convenient reference to or the actual value of the user certificate for the private key that the signing authority used to sign the certificate. CheckValue ::= CHOICE{ signature [0] Signature -- only signature supported here } Signature ::= SEQUENCE{ signatureValue [0] BIT STRING, asymmetricAlgId [1] AlgorithmIdentifier OPTIONAL, hashAlgId [2] AlgorithmIdentifier OPTIONAL, issuerCAName [3] Identifier OPTIONAL, caCertInformation [4] CHOICE { caCertSerialNumber [0] INTEGER, certificationPath [1] CertificationPath } OPTIONAL } --CertificationPath is imported from [ISO/IEC 9594-8] signatureValue The value of the signature. It is the result of an asymmetric encryption of a hash value of the certificateBody. Baize, Farrell, Parker Document Expiration: 21 May 1996 [Page 23] internet-draft November 21, 1995 asymmetricAlgId Only present if the certificate body is encrypted, then it is a duplication of the algId value in "commonContents". hashAlgId Only present if the certificate body is encrypted, then it is a duplication of the hashAlgId value in "commonContents". issuerCAName The identity of the Certification Authority that has signed the user certificate corresponding to the private key used to sign this certificate. caCertInformation Contains either just a certificate serial number which together with the issuerCAName uniquely identifies the user certificate corresponding to the private key used to sign this certificate, or a full specification of a certification path via which the validity of the signature can be verified. The latter option follows the approach used in [ISO/IEC 9594-8]. The Seal structure is used in the Tokens defined in section 3 above. Seal ::= SEQUENCE{ sealValue [0] BIT STRING, symmetricAlgId [1] AlgorithmIdentifier OPTIONAL, hashAlgId [2] AlgorithmIdentifier OPTIONAL, targetName [3] Identifier OPTIONAL, keyId [4] INTEGER OPTIONAL } sealValue The value of the seal. It is the result of a symmetric encryption of a hash value of a set of octets (which are the DER encoding of some ASN.1 type) symmetricAlgId An optional indicator of the sealing algorithm. hashAlgId Only present if the symmetricAlgId does not specify which hashing algorithm is used. targetName This field identifies the targetAEF or target with which the symmetric key used for the seal is shared. keyId This serial number together with the targetName uniquely Baize, Farrell, Parker Document Expiration: 21 May 1996 [Page 24] internet-draft November 21, 1995 identifies the symmetric key used in the seal. 4.1.1.4 Certificate Identity Certificate identity is a named concatenation of the three named field types defined in CommonContents which together uniquely identify a certificate. CertificateId ::= SEQUENCE { issuerDomain [0] Identifier OPTIONAL, issuerIdentity [1] Identifier, serialNumber [2] INTEGER } -- serialNumber is the same as in [ISO/IEC 9594-8] 4.1.2 Security Attributes The security attribute is a basic construct used in all certificate types defined in this specification. SecurityAttribute ::= SEQUENCE{ attributeType Identifier, attributeValue SET OF SEQUENCE { definingAuthority [0] Identifier OPTIONAL, securityValue [1] SecurityValue } } -- NOTE: SecurityAttribute is not tagged, for compatibility -- with the Directory Standard. SecurityValue ::= CHOICE{ directoryName [0] Name, printableName [1] PrintableString, octets [2] OCTET STRING, intVal [3] INTEGER, bits [4] BIT STRING, any [5] ANY -- defined by attributeType } Note: Only one set member is permitted in attributeValue. Multivalue attributes are effected in the securityValue field, where the "SEQUENCE OF" construct can be used. This restriction avoids any certificate hash value ambiguity that may occur with indeterminacy in the representation of the order of SET members. At the same time, by including "SET OF" in the syntax, we enable security attributes to be stored as normal in a Directory whenever the choice made within Identifier is OBJECT IDENTIFIER. If other choices are made, encapsulation in an outer Directory Baize, Farrell, Parker Document Expiration: 21 May 1996 [Page 25] internet-draft November 21, 1995 Attribute structure would first be necessary. attributeType Defines the type of the attribute. Attributes of the same type have the same semantics when used in Access Decision Functions, though they may have different defining authorities. definingAuthority The authority responsible for the definition of the semantics of the value of the security attribute. This optional field of the attributeValue can be used to resolve potential value clashes. Note: This is not to be confused with the Attribute Authority responsible for controlling which principals are permitted to use which attribute values in PACs - though under some security policies they may be the same. securityValue The value of the security attribute. Its syntax is can be either one of the basic syntaxes for attributes or a more complex one determined by the attribute type. 4.1.3 PAC Contents The syntax of the PAC contents is: PACSpecificContents ::= SEQUENCE{ pacSyntaxVersion [0] INTEGER{ version1 (1)} DEFAULT 1, protectionMethods [2] SEQUENCE OF MethodGroup OPTIONAL, pacType [4] ENUMERATED{ primaryPrincipal (1), temperedSecPrincipal (2), untemperedSecPrincipal(3) } DEFAULT 3, privileges [5] SEQUENCE OF PrivilegeAttribute, restrictions [6] SEQUENCE OF Restriction OPTIONAL, miscellaneousAtts [7] SEQUENCE OF SecurityAttribute OPTIONAL, timePeriods [8] TimePeriods OPTIONAL } PrivilegeAttribute ::= SecurityAttribute Restriction ::= SEQUENCE { howDefined [0] CHOICE { Baize, Farrell, Parker Document Expiration: 21 May 1996 [Page 26] internet-draft November 21, 1995 included [3] BIT STRING }, -- the actual restriction in a form -- undefined here type [2] ENUMERATED { mandatory (1), optional (2)} DEFAULT mandatory, targets [3] SEQUENCE OF SecurityAttribute OPTIONAL } -- applies to all targets if this is omitted pacSyntaxVersion Syntax version of the PAC. protectionMethods A sequence of optional groups of Method fields used to protect the certificate from being stolen or misused. For a full description see section 4.1.4. pacType Indicates whether the privileges contained in the PAC are those of a Primary Principal, of a Secondary Principal tempered by the privileges of a Primary Principal (the privileges of the Secondary Principal which appear in the PAC are a subset of the whole set of the privileges of the Secondary Principal, taking into consideration the privileges of the Primary Principal - or the lack of knowledge of them) or of a Secondary Principal (the privileges of the Secondary Principal have not been affected by any privileges of the Primary Principal). privileges Privilege Attributes of the principal. restrictions This field enables the original owner of the PAC to impose constraints on the operations for which it is valid. A restriction is a bit string which can be either included in the PAC or external to it. A restriction can be targeted to one or more application components. Two types of restriction are supported: - Mandatory: If a target application to which the restriction applies cannot understand the bit string defining the restriction, access should not be granted, - Optional: If a target application to which the restriction applies cannot understand the bit string, it is expected to ignore it. Only one way of expressing the restrictions is supported in this specification: Baize, Farrell, Parker Document Expiration: 21 May 1996 [Page 27] internet-draft November 21, 1995 included The restriction is directly included in "restrictions" field of the certificate. miscellaneousAtts Security attributes which are neither privileges attributes nor restrictions attributes. In a PAC, this may include identity attributes such as Audit Identity. Note: We do not preclude the authenticated identity to be one of the miscellaneous attributes. However, when it is present, it must not be used for access control purposes. Access identity security attributes, if present in the PAC, appear in the privileges field. timePeriods This field adds further time restrictions to the validity field of the commonContents. Either startTime or endTime can be optional. The TimePeriods control is passed if the time now is within any of the sequence periods, or if there is a period with a start before now and no endTime, or there is a period with an end after now and no startTime. 4.1.4 Protection Methods MethodGroup ::= SEQUENCE OF Method Method ::= SEQUENCE{ methodId [0] MethodId, methodParams [1] SEQUENCE OF Mparm OPTIONAL } MethodId ::= CHOICE{ predefinedMethod [0] ENUMERATED { controlProtectionValues (1), ppQualification (2), targetQualification (3), delegateTargetQualification (4) } } Mparm ::= CHOICE{ pValue [0] PValue, securityAttribute [1] SecurityAttribute } PValue ::= SEQUENCE{ pv [0] BIT STRING, Baize, Farrell, Parker Document Expiration: 21 May 1996 [Page 28] internet-draft November 21, 1995 algorithmIdentifier [1] AlgorithmIdentifier OPTIONAL } CertandECV ::= SEQUENCE { certificate [0] GeneralisedCertificate, ecv [1] ECV, OPTIONAL} -- ECV is defined in later methodId Identifies a protection method. Several methods are here. Methods can be used in any combination, and except where stated otherwise, multiple occurrences of the same method are permitted. The choice of methodId determines the permitted choices of method parameters in the methodParams construct as described below. methodParams Parameters for a protection method. The semantics of each protection method is described in following sections below. In each case, the syntax choice of the mParm field is defined. 4.1.4.1 "Control/Protection Values" protection method The MethodId for this is: controlProtectionValues This method protects the certificate from being stolen, at the same time controlling its acceptance for use by proxy to defined groups of target applications. The syntax choice of Mparm for this method is: pValue. This scheme uses a PAC Protection Value (PV) to provide a method of controlling the forwarding of a certificate for use by proxy, without the user of the certificate needing to know the precise identity of the final target application. It prevents a line- tapper from stealing the certificate for his own use, but does not demand that the certificate be encrypted. A maximum of one PV method is permitted in each method group. Security attributes can be associated with the PV by including appropriate protection methods in the PV's method group. More than one method group can be specified, each containing a PV. Also associated with each PV is a certificate Control Value (CV) external to the certificate. The PV is the result of a one-way function applied to the corresponding CV. When the PAC is offered to a targetAEF, it is proof of knowledge of this CV which causes the PAC to be accepted (subject to the other controls in the PV's Baize, Farrell, Parker Document Expiration: 21 May 1996 [Page 29] internet-draft November 21, 1995 method group). Unless otherwise specified, the one-way function that is used for this method is MD5. Either the CVs are generated and PVs calculated by the PAC issuer for the client on request for each occurrence of the method in the certificate, or the client itself generates the CVs and specifies the PVs to the PAC issuer. The PVs are returned in the certificate; the corresponding CVs, if they have been generated by PAC issuer, are returned along with the certificate, encrypted under the key used to protect the certificate request. They are returned in the ECV construct described below. When the client now sends the PAC to a targetAEF, one or more CVs are also sent encrypted under the basic key used to communicate with the target AEF. They are sent in the ECV construct. Not all of the CVs associated with the PAC need always be sent. The targetAEF knows the one-way function and therefore is able to verify that the client knows a CV which corresponds to a PV in the certificate. If the other controls in the PV's method group are passed, the PAC is acceptable under this method group. The targetAEF now knows the value of the CVs that have been sent to it, and can make available this value to the application or to the infrastructure supporting that application so that it can forward the certificate for use with target application. By including target qualification controls in the method group, proxy can be confined to groups of target applications, for example all of the servers in a distributed service. 4.1.4.2 "Primary Principal Qualification" protection method The MethodId for this is: ppQualification This method protects the certificate from being stolen, by confining its use to be from one or more nominated Primary Principals. In its most restrictive form it permits a certificate to be used only from the Primary Principal of the client entity to which it was originally issued. It can also be used to permit proxy, when the required attributes of the proxy application Primary Principals are precisely known. The method does not limit the number of target applications at which a PAC might be accepted. The syntax choice of Mparm for this method is : securityAttribute A sequence of Mparm constructs is permissible, resulting in multiple security attributes being present. The attributes are inserted in the certificate by the PAC issuer according to security policy. They may be requested by the client. They are attributes that must be possessed by any Primary Baize, Farrell, Parker Document Expiration: 21 May 1996 [Page 30] internet-draft November 21, 1995 Principal from which this certificate is to be validly used. When a targetAEF receives such a certificate, it is responsible for comparing the attributes found in the PAC with the attributes that it knows (by other means described below) are associated with the initiating Primary Principal. Only if the initiator has all of the ppQualification attributes in the certificate, is the PAC accepted under this method. There way in which a target AEF can know the attributes associated with a Primary Principal is by the use of Security Associations or Contexts established via a target key block as defined here. Whenever an initiator sends a PAC to a target AEF, it does so under the protection of a key established by use of the targetKeyBlock constructs defined in below. The targetPart of the targetKeyBlock defined there contains a construct which includes a sequence of Primary Principal security attributes. The attribute values are placed in the target key block by the trusted server (the KDS) which created it or by the initiator (with the asymmetric key distribution scheme). The attribute value used here is termed the primary principal identifier (PPID) and takes one of two forms depending on the key distribution scheme used by the initiator. For the symmetric intradomain and hybrid interdomain schemes the PPID takes the form of a random bit string which is also sent in the authorization data field of the Kerberos ticket. For the asymmetric scheme the PPID contains the certificate serial number and CA name for the initiator's X.509 public key certificate. Further details are given in the profiling of the target key block below. 4.1.4.3 "Target Qualification" protection method The MethodId for this is: targetQualification. This method protects the PAC from misuse by allowing its use only by a nominated set of target applications and at the same time preventing it from being forwarded by them. The syntax choice of Mparm for this method is : securityAttribute A sequence of Mparm constructs is permissible, resulting in multiple security attributes being present. The attributes are inserted in the PAC by the PAC issuer according to security policy. They may be requested by the client. Baize, Farrell, Parker Document Expiration: 21 May 1996 [Page 31] internet-draft November 21, 1995 Target AEFs receiving such PACs will compare the values found in the PAC with the attributes of the target application. If the target application possesses one of the attributes in one of the occurrences of this method that is present in a method group, the Certificate is deemed to be acceptable under this method in this group but the target AEF is expected not to allow the use of the certificate for access to further target applications. 4.1.4.4 "Delegate/Target Qualification" protection method The MethodId for this is: delegateTargetQualification This method protects the certificate from misuse by confining its validity to a set of target applications. The syntax choice of Mparm for this method is: securityAttribute A sequence of Mparm constructs is permissible, resulting in multiple security attributes being present. The attributes are inserted in the certificate by the PAC issuer according to security policy. They may be requested by the client. The target AEF makes the comparisons described in section 4.1.4.5, but if the checks are passed, the nominated target application is acceptable as both an accessible target and as a delegate. The attributes carried by the certificate are valid at the target application for authentication or access control purposes and the target AEF will allow the use of the certificate for access to further target applications. 4.1.4.5 Combining the methods PACs are unlikely to contain complex combinations of many method types with multiple occurrences of each type. It is expected that one occurrence of each of one or two method types in one method group would be normal. However the general rule for validating a certificate when received by a target AEF is as follows: If the PAC is properly signed by an authority recognised by this targetAEF and is within the valid time periods then the protection methods in each group are tested in turn as described below until one of the groups is passed or the PAC is declared invalid. A method group is passed if it is empty, or if: the PAC is for the nominated target application under any Baize, Farrell, Parker Document Expiration: 21 May 1996 [Page 32] internet-draft November 21, 1995 target or delegateTarget qualification method in this group and tests on any ppQualification or controlProtectionValues method in the group succeeds. If more than one of these is present, at least one must be passed. If only one is present it must be passed. If none of them is present this last check is not required. If the group that has been passed only validates the certificate for its recipient being a target, then further groups are checked to see if the recipient is also valid as a delegate/target. If, following these additional checks, a recipient is still valid only as a target, the targetAEF is responsible for preventing its use for access to further target applications. 4.1.5 External Control Values Construct Whenever the protection controlProtectionValues method is in place, when a PAC protected under that method is being presented as authorisation for an operation, it may be accompanied by one or more control values and indices to the method occurrences in the certificate to which they apply. Also, when such a certificate is being issued to a requesting client, the CV values it will need in order to use that certificate may need to be returned with it. ECV ::= SEQUENCE { crypAlgIdentifier [0] AlgorithmIdentifier OPTIONAL, cValues [1] CHOICE { encryptedCvalueList [0] BIT STRING, individualCvalues [1] CValues } } CValues ::= SEQUENCE OF SEQUENCE { index [0] INTEGER, value [1] BIT STRING } crypAlgIdentifier This specifies the encryption algorithm of the control values. cValues An ECV construct can contain either an encrypted list of control values in the encryptedCvalueList field, or a list of individually control values in individualCvalues. If the encryptedCvalueList choice is made, the whole list is encrypted in bulk, but the in-clear contents of this field are Baize, Farrell, Parker Document Expiration: 21 May 1996 [Page 33] internet-draft November 21, 1995 expected to have the syntax CValues. If the individualCvalues choice is made, values are individually encrypted in the value fields of the list. Encryption is always done under the basic key protecting the operation. In the case of the controlProtectionValues method, value is a CV, and index is then the index of the method occurrence in the certificate, starting at 1. 4.2 Basic Key Distribution The TargetKeyBlock is structured as follows: - an identifier (kdSchemeOID) for the key distribution scheme being used, which takes the form of an OBJECT IDENTIFIER, - a part which, if present, the target AEF needs to pass on to its KDS (targetKDSPart - will be present only when the target AEF's KDS is different from the initiator's), - a part which, if present, can be used directly by the target AEF (targetPart). When a targetAEF using a separate KDS receives the targetKeyBlock, it first checks whether it supports the key distribution scheme indicated in kdsSchemeOID. Two different cases need to be considered: 1) Only the targetPart is present. The target AEF computes the basic key directly, using the information present in the TargetPart. The syntax of targetPart is scheme dependent. Expiry information can optionally be present in targetPart. If supported by the scheme, the Primary Principal attributes of the initiator will also be present for PAC protection under the Primary Principal Qualification method (see above). 2) Only the targetKDSPart is present. The targetAEF forwards TargetKeyBlock to its KDS. In return it receives a scheme dependent data structure which by itself allows the target AEF to determine the basic key and, if supported by the scheme, the Primary Principal attributes of the initiator for PAC protection purposes. Expiry information can optionally be present in the targetKDSPart. The form of this information depends on the key distribution configuration in place. 4.2.1 Keying Information Syntax TargetKeyBlock ::= SEQUENCE { kdSchemeOID [2] OBJECT IDENTIFIER, targetKDSpart [3] ANY OPTIONAL, -- depending on kdSchemeOID Baize, Farrell, Parker Document Expiration: 21 May 1996 [Page 34] internet-draft November 21, 1995 targetPart [4] ANY OPTIONAL -- depending on kdSchemeOID } kdSchemeOID Identifies the key distribution scheme used. Allows the targetAEF to determine rapidly whether or not the scheme is supported. It also allows for the easy addition of future schemes. targetKDSpart Part of the Target Key Block which is processable only by the KDS of the target AEF. This part is sent by the target AEF to its local KDS, in order to get the basic key which is in it. It must always contain the name of a target "served" by the targetAEF in question. The mapping between the name of the application and the name of the target AEF is known to the target AEF's KDS which is able to authenticate which target AEF is issuing the request for translating the targetKDSpart. It can then verify that the AEF is one which is responsible for the application name contained in the targetKDSpart. If it is, the key is released and is sent protected back to the requesting AEF. targetKDSpart should include data that enables the KDS of the target AEF to authenticate the KDS of the initiator. When the "Primary Principal Qualification" protection method needs to be used for the PAC, unless there is an accompanying targetPart, targetKDSpart must contain the appropriate primary principal security attributes (which is always true in this specification). targetPart Part of the Target Key Block which is processed only by the target AEF. When there is no targetKDSpart it is processable directly; otherwise it can only be processed after the target KDSpart has been processed by the KDS of the target AEF, and the appropriate Keying Information has been returned to the AEF. The targetPart construct should include data that enables the target AEF to authenticate the KDS of the initiator. When the "Primary Principal Qualification" protection method needs to be used for the PAC, targetPart must contain the primary principal security attributes. The following table shows the different syntaxes used for targetKDSpart and targetPart for the defined KD-schemes. "Missing" in the tables means that the relevant construct is not supplied. KD-Scheme name kdSchemeOID targetKDSpart targetPart symmIntradomain {kd-schemes 1} Missing Ticket hybridInterdomain {kd-schemes 3} PublicTicket Missing asymmetric {kd-schemes 6} Missing SPKM_REQ Baize, Farrell, Parker Document Expiration: 21 May 1996 [Page 35] internet-draft November 21, 1995 Table 1 - Key Distribution Scheme OBJECT IDENTIFIERs The syntax of PublicTicket is given below, and the syntax of Ticket (copied from [Kerberos]) is given in appendix A.2. The syntax of SPKM_REQ (copied from [SPKM])is given in appendix A.3. We now define the new ASN.1 OBJECT IDENTIFIERs and token construct data types required for these KD-schemes. 4.2.2 Object Identifiers The OBJECT IDENTIFIERs that are for use in the kdSchemeOID field of TargetKeyBlock are formally derived from the kd-schemes OBJECT IDENTIFIER which is defined as follows: kd-schemes OBJECT IDENTIFIER ::= { generic-sesame-oids tbs } -- arc for SESAME key distribution schemes symmIntradomain OBJECT IDENTIFIER ::= {kd-schemes 1} hybridInterdomain OBJECT IDENTIFIER ::= {kd-schemes 3} asymmetric OBJECT IDENTIFIER ::= {kd-schemes 6} -- supported key distribution schemes The SPKM_REQ construct used in scheme 6 requires a sequence of key establishment algorithm identifier values to be inserted into the key_estb_set field. The OBJECT IDENTIFIER below is defined as the (single) key establishment "algorithm" for the SESAME mechanism: sesame-key-estb-alg AlgorithmIdentifier ::= {kd-schemes, NULL } -- indicates a SESAME key establishment structure within -- an SPKM_REQ structure kd-schemes This OBJECT IDENTIFIER is the top of the arc of key distribution scheme OBJECT IDENTIFIERs defined in this specification. symmIntradomain This OBJECT IDENTIFIER indicates the basic symmetric key distribution scheme described in section 2.2.3. As indicated in the third column of Table 1, the targetKDSpart of the TargetKeyBlock is not supplied and the targetPart contains a Kerberos Ticket (see [Kerberos] and appendix A.2). The profile of the ticket that is supported this scheme can be found in Table 2. hybridInterdomain This OBJECT IDENTIFIER indicates the hybrid scheme described in section 2.2.3. The targetKDSpart contains a PublicTicket (defined in section 4.2.3). The targetPart field is not supplied. The PublicTicket contains a Kerberos Ticket. The profile supported in this scheme can be found in Table 3. Baize, Farrell, Parker Document Expiration: 21 May 1996 [Page 36] internet-draft November 21, 1995 asymmetric This OBJECT IDENTIFIER indicates the scheme described in section 2.2.3. The targetKDSpart is not supplied and the targetPart contains an SPKM_REQ. The syntax of SPKM_REQ is given in appendix A.3. The profile of SPKM_REQ that is supported in this scheme is given in Table 4. sesame-key-estb-alg This AlgorithmIdentifier identifies the key establishment algorithm value to be used within the key_estb_set field of an SPKM_REQ data element as the one defined by SESAME. This algorithm is used to establish a symmetric key for use by both the initiator and the target AEF as part of the context establishment. The corresponding key_estb_req field of the SPKM_REQ will be a BIT STRING the content of which is a DER encoding of the KeyEstablishmentData element defined later. 4.2.3 Hybrid inter-domain key distribution scheme data elements PublicTicket ::= SEQUENCE{ krb5Ticket [0] Ticket, publicKeyBlock [1] PublicKeyBlock} PublicKeyBlock ::= SEQUENCE{ signedPKBPart [0] SignedPKBPart, signature [1] Signature OPTIONAL, certificate [2] Certificate OPTIONAL } SignedPKBPart ::= SEQUENCE{ keyEstablishmentData [0] KeyEstablishmentData, encryptionMethod [1] AlgorithmIdentifier OPTIONAL, issuingKDS [2] Identifier, uniqueNumber [3] UniqueNumber, validityTime [4] TimePeriods, creationTime [5] UTCTime } UniqueNumber ::= SEQUENCE{ timeStamp [0] UTCTime, random [1] BIT STRING } krb5Ticket The Kerberos Ticket which contains the basic key. The encrypted part of this ticket is encrypted using the key found within the encryptedPlainKey field of the KeyEstablishmentData in the PublicKeyBlock. Baize, Farrell, Parker Document Expiration: 21 May 1996 [Page 37] internet-draft November 21, 1995 publicKeyBlock Contains the key used to protect the krb5Ticket encrypted using the public key of the recipient and signed by the encryptor (i.e. the context initiator's KD-Server). signedPKBPart The part of the publicKeyBlock which is signed. The keyEstablishmentData field contains the KeyEstablishementData (defined in section 4.2.4), i.e. the actual encrypted temporary key (see section 2.2.3). The encryptionMethod indicates the algorithm used to encrypt the encryptedKey. The issuingKDS is the name of the KD- Server who produced the PublicTicket. The uniqueNumber is a value (containing a timestamp and a random number) which prevents replay of the PublicTicket. validityTime specifies the times for which the PublicTicket is valid. creationTime contains the time at which the PublicTicket was created. signature Contains the signature calculated by the issuingKDS on the signedPKBPart field. certificate If present, contains the public key certificate of the issuing KDS. 4.2.4 Key establishment data elements KeyEstablishmentData ::= SEQUENCE { encryptedPlainKey [0] BIT STRING,-- encrypted PlainKey targetName [1] Identifier OPTIONAL, nameHashingAlg [2] AlgorithmIdentifier OPTIONAL } HashedNameInput ::= SEQUENCE { hniPlainKey [0] BIT STRING,-- same as plainKey hniIssuingKDS [1] Identifier } PlainKey ::= SEQUENCE { plainKey [0] BIT STRING, -- The cleartext key hashedName [1] BIT STRING } encryptedPlainKey Contains the encrypted key. The BIT STRING contains the result of encrypting a PlainKey structure. targetName Baize, Farrell, Parker Document Expiration: 21 May 1996 [Page 38] internet-draft November 21, 1995 If present, contains the name of the target application. This is necessary for some of the SESAME KD-schemes. nameHashingAlg Specifies the algorithm which is used to calculate the hashedName field of the PlainKey. hniPlainKey hniIssuingKDS Used as input to a hashing algorithm as a general means to prevent ciphertext stealing attacks. plainKey Contains the actual bits of the plaintext key which is to be established. hashedName A hash of the name of the encrypting KDS calculated using the plainkey and KDS name as input (within the HashedNameInput structure). The algorithm identified in nameHashingAlg is used to calculate this value. targetName If present, contains the name of the target for which the PublicTicket was originally produced. This may be different from the targetIdentity field of the initialContextToken if caching of PublicTickets has been implemented. 4.2.5 Kerberos Data elements The full ASN.1 for the Kerberos elements used by the SESAME GSS- API mechanism is given in appendix A.2. This section specifies the specific contents of the Kerberos Ticket's authorization_data field required by the SESAME GSS-API mechanism. Essentially this construct contains the PPID of the context initiator, as formally defined below. SESAME-AUTHORISATION-DATA-TYPE ::= INTEGER { SESAME-ADATA (65) } SESAME-AUTHORISATION-DATA ::= SEQUENCE { sesame-ad-type [0] ENUMERATED { ppidType (0) }, sesame-ad-value [1] CHOICE { ppidValue [0]SecurityAttribute } } ppidType Indicates the type of the SESAME authorisation data which is Baize, Farrell, Parker Document Expiration: 21 May 1996 [Page 39] internet-draft November 21, 1995 included in the Ticket ppidValue This value is used in the ppQualification PAC protection method as defined above 4.2.6 Profiling of KD-schemes The following tables provide profiling information for the data elements defined above and in appendices A.1 and A.2. The tables indicate which optional fields must be present for each of the KD- Schemes and indicate the values which are required to be present in all fields. 4.2.6.1 Profile of Ticket as used in symmIntradomain scheme Field Value/Constraint ----- ---------------- tkt-vno 5 realm ticket issuer's domain name in Kerberos realm name form sname target application name including the realm of the target - EncTicketPart encrypted with long term key of target AEF -- flags only bits 6, 10 and 11 can be meaningful in the context of the SESAME mechanism, the rest are ignored -- key the basic key -- crealm initiator domain name in Kerberos realm name form -- cname principal name of the initiator (in the case of delegation the cname will be that of the delegate) -- transited not used -- authtime the time at which the initiator was authenticated -- starttime not used -- endtime the time at which the ticket becomes invalid -- renew-till not used -- caddr not used -- authorization- contains the PPID corresponding to cname data Table 2 - Kerberos ticket fields supported 4.2.6.2 Profile of PublicTicket as used in hybridInterdomain scheme Field Value/Constraint ----- ---------------- krb5Ticket - tkt-vno 5 Baize, Farrell, Parker Document Expiration: 21 May 1996 [Page 40] internet-draft November 21, 1995 - realm initiator domain name in Kerberos realm name form - sname target application name including the realm of the target -- EncTicketPart encrypted with temporary key (which is in turn encrypted within the keyEstablishmentData field) --- flags only bits 6, 10 and 11 can be meaningful in the context of the SESAME mechanism, the rest are ignored --- key the basic key --- crealm initiator domain name in Kerberos realm name form --- cname principal name of the initiator (in the case of delegation the cname will be that of the delegate) --- transited not used --- authtime the time at which the initiator was authenticated --- starttime not used --- endtime the time at which the ticket becomes invalid --- renew-till not used --- caddr not used --- authorization- contains the PPID corresponding to cname data publicKeyBlock - signedPKBPart -- encryptedKey KeyEstablishmentData structure -- encryptionMethod sesame-key-estb-alg -- issuingKDS X.500 name of initiator's KDS (the signer) -- uniqueNumber creation time of publicKeyBlock plus a random bit string -- validityTime only one period allowed -- creationTime creation time of publicKeyBlock - signature contains all the signing information as well as the actual signature bits - certificate optional Table 3 - PublicTicket fields supported 4.2.6.3 Profile of SPKM_REQ as used in asymmetric scheme Field Value/Constraint ----- ---------------- requestToken - tok_id not used - fixed value of `0' - context_id not used - fixed value of bit string containing one zero bit - pvno not used - fixed value of bit string containing one zero bit Baize, Farrell, Parker Document Expiration: 21 May 1996 [Page 41] internet-draft November 21, 1995 - timestamp creation time of SPKM_REQ - required - randSrc random bit string - targ_name X.500 Name of target AEF - src_name X.500 Name of initiator - req_data -- channelId not used - octet string of length one value `00'H -- seq_number missing -- options not used - all bits set to zero -- conf_alg not used - use NULL CHOICE -- intg_alg not used - use a SEQUENCE OF with zero elements - validity mandatory - key_estb_set only one element supplied containing sesame- -key-estb-alg - key_estb_req contains KeyEstablishmentData with targetApplication field missing - key_src_bind missing req_integrity sig_integ mandatory certif_data only userCertificate field supported auth_data missing Table 4 - SPKM_REQ fields supported 4.3 Dialogue Key Block Dialogue Key Block constructs are used to specify how the integrity dialogue key and confidentiality dialogue key should be derived from the basic key, and specify the cryptographic algorithms with which the keys should be used. Dialogue keys are explained in Part 1. The syntax is as follows: DialogueKeyBlock ::= SEQUENCE { integKeySeed [0] SeedValue, confKeySeed [1] SeedValue, integKeyDerivationInfo [2] KeyDerivationInfo OPTIONAL, confKeyDerivationInfo [3] KeyDerivationInfo OPTIONAL, integDKuseInfo [4] DKuseInfo OPTIONAL, confDKuseInfo [5] DKuseInfo OPTIONAL } SeedValue ::= SEQUENCE { timeStamp [0] UTCTime OPTIONAL, random [1] BIT STRING } KeyDerivationInfo::= SEQUENCE { owfId [0] AlgorithmIdentifier, keySize [1] INTEGER } Baize, Farrell, Parker Document Expiration: 21 May 1996 [Page 42] internet-draft November 21, 1995 DKuseInfo ::= SEQUENCE { useAlgId [0] AlgorithmIdentifier, useHashAlgId [1] AlgorithmIdentifier OPTIONAL } integKeySeed A random number, optionally concatenated with a time value to ensure uniqueness, used as input to the one way function specified in integKeyDerivationInfo. confKeySeed A random number, optionally concatenated with a time value to ensure uniqueness, used as input to the one way function specified in confKeyDerivationInfo. integKeyDerivationInfo Key derivation information for the integrity dialogue key, as follows: owfId The one way algorithm which takes the basic key XOR the seed as input, resulting in the integrity dialogue key. keySize The size of the key in bits. If the algorithm identified by owfId produces a larger key, it is reduced by masking to this length, losing its most significant end. confKeyDerivationInfo Key derivation information for the confidentiality dialogue key. The fields in this construct have the same meanings as defined above for the integrity dialogue key. Note: It may be insecure to specify the same derivation algorithms and seeds for both integrity and confidentiality dialogue keys, particularly if they are to be of different lengths. integDKuseInfo Information describing how the integrity dialogue key is to be used, as follows: useAlgId The symmetric or asymmetric reversible encryption algorithm with which the integrity dialogue key is to be used. useHashAlgId The one way function with which the integrity dialogue key is to be used. It is the hash produced by this algorithm on the data to be protected which is encrypted using useAlgId. Baize, Farrell, Parker Document Expiration: 21 May 1996 [Page 43] internet-draft November 21, 1995 confDKuseInfo Information describing how the confidentiality key is to be used. The useHashAlgId construct is not used here. 4.4 Attribute Definitions Note: the types given for the attributes below use the type Identifier whereas the SecurityAttribute type is actually used in the PAC. The mapping from Identifier to SecurityAttribute is TBS (due to time constraints on the production of this I-D). 4.4.1 Privilege attributes Privileges are defined under the OBJECT IDENTIFIER: privilege-attributeOBJECT IDENTIFIER ::= { generic-sesame-oids privilege-attribute(4) } -- OID below which privilege attributes are defined 4.4.1.1 Access Identity The access identity represents the principal's identity to be used for access control purposes. The type of this attribute is : access-identity-privilege ::= OBJECT IDENTIFIER { privilege-attribute 2 } Its syntax in the PAC is: AccessPrivilegeValueSyntax ::= Identifier 4.4.1.2 Group The group represents a characteristic common to several principals. A security context may contain more than one group for a given principal. The type of this attribute is: group-privilege ::= OBJECT IDENTIFIER { privilege-attribute 4 } Its syntax in the PAC is: GroupPrivilegeValueSyntax ::= SEQUENCE OF Identifier 4.4.1.3 Primary group The primary group represents a unique group to which a principal Baize, Farrell, Parker Document Expiration: 21 May 1996 [Page 44] internet-draft November 21, 1995 belongs. A security context must not contain more than one primary group for a given principal. The type of this attribute is: primary-group-privilege ::= OBJECT IDENTIFIER { privilege- attribute 3 } Its syntax in the PAC is: PrimaryGroupValueSyntax ::= Identifier 4.4.1.4 Role attribute The role attribute represents the principal's role. There may be a one to one mapping between a role name and a role attribute. The type of this attribute is: role-privilege ::= OBJECT IDENTIFIER { privilege-attribute 1 } Its syntax in the PAC is: RolePrivilegeValueSyntax ::= Identifier 4.4.2 Miscellaneous attributes Miscellaneous attributes are defined under the OBJECT IDENTIFIER: misc-attribute OBJECT IDENTIFIER ::= { generic-sesame-oids misc-attribute(3) } -- OID below which miscellaneous attributes are defined 4.4.2.1 Audit Identity The access identity represents the principal's identity to be used for audit purposes. The type of this attribute is: audit-id-misc ::= OBJECT IDENTIFIER { misc-attribute 2 } Its syntax in the PAC is: AuditIdValueSyntax ::= Identifier 4.4.3 Qualifier Attributes When a targetQualifiication or delegateTargetQualification method is present in the PAC, the syntax used for the method parameters is securityAttribute. In this section we define the OIDs and Baize, Farrell, Parker Document Expiration: 21 May 1996 [Page 45] internet-draft November 21, 1995 attribute value syntaxes for these methods. qualifier-attribute OBJECT IDENTIFIER ::= { generic-sesame-oids qualifier-attribute (4) } -- OID below which qualifier attributes are defined 4.4.3.1 Target Names Within a PAC protection method a target name is indicated using the OID: target-name-qualifier OBJECT IDENTIFIER ::= { qualifier-attribute 1 } It's syntax in the PAC is: TargetNameValueSyntax ::= Identifier 4.4.3.2 Application Trust Groups Within a PAC protection method an application trust group name is indicated using the OID: trust-group-qualifier OBJECT IDENTIFIER ::= { qualifier-attribute 2 } It's syntax in the PAC is: TrustGroupValueSyntax ::= Identifier The universal application trust group (see section 2) is specified by using the printableName field of the Identifier where the value is an empty string. 5. ALGORITHMS AND CIPHERTEXT FORMATS Cryptographic and hashing algorithms are used for various purposes within the SESAME GSS-API mechanism. This section categorises these algorithms according to usage so that context initiators and acceptors can more easily determine if they have the cryptographic support required to allow inter-operation. The categorisation is then refined into cryptographic profiles that can be incorporated into specific mechanism identifiers for the purpose of mechanism negotiation. The table below summarises the different uses to which algorithms are put within the SESAME GSS-API mechanism. Use Description of use Type of Algorithm Reference 2 PAC protection OWF + asymmetric Baize, Farrell, Parker Document Expiration: 21 May 1996 [Page 46] internet-draft November 21, 1995 using signature signature 3 basic key usage symmetric confidentiality and integrity 4 integrity dialogue OWF key derivation 5 integrity dialogue symmetric integrity key usage 6 CA public keys OWF + asymmetric signature 7 encryption using symmetric shared long term confidentiality. symmetric key 8 name hash to OWF prevent ciphertext stealing 9 asymmetric basic asymmetric encryption key distribution and OWF + signature 10 key estab. within (fixed value) SPKM_REQ 11 confidentiality OWF dialogue key derivation 12 confidentiality symmetric dialogue key use confidentiality Table 5 - Summary of algorithm uses: The algorithms can now be further categorised into broader classes as follows: Class 1: symmetric for security of mechanism: Uses 3, 5, 7 Class 2: all OWFs: Uses 2, 4, 6, 8, 11 Class 3: internal mechanism asymmetric, encrypting: Use 9 Class 4: internal mechanism asymmetric, non-encrypting: Use 2 Class 5: CA's asymmetric non-encrypting: Use 6 Class 6: Data confidentiality, symmetric: Use 12 Use 10 is a fixed value, and does not contribute to mechanism use options. The fixed value for this has already been defined above. Based on these classes, the following cryptographic algorithm usage profiles are defined. Other profiles are possible and can be defined as required. Note that symmetric algorithm key sizes are included in this profiling, thus DES/64 indicates DES with a Baize, Farrell, Parker Document Expiration: 21 May 1996 [Page 47] internet-draft November 21, 1995 64 bit key. Profile 1: Profile 2: Profile 3: Profile 5: Full No user Exportable Defaulted data Confidenti ality Class 1 DES/64 DES/64 RC4/128 separately agreed default Class 2 MD5 MD5 MD5 separately agreed default Class 3 RSA RSA RSA separately agreed default Classes RSA RSA RSA separately 4 agreed and 5 default Class 6 DES/64 None RC4/40 separately agreed default Table 6 - Algorithm profiles Where: - Profile 1 provides full security, using standard cryptographic algorithms with commonly accepted key sizes. - Profile 2 is the same but without supporting any confidentiality of user data. - Profile 3 is exportable under many countries' legislations, - Profile 5 uses algorithms identified by a separately specified default. It is intended for use by organisations who wish to use their own proprietary or government algorithms by separate agreement or negotiation. The next section shows how these algorithm profiles can be used to extend the architectural key distribution schemes to form negotiable SESAME mechanism choices. 6. SESAME MECHANISM NEGOTIATION Preceding sections have separately defined the alternatives allowed by the generic SESAME mechanism in terms of key distribution schemes and the use of cryptographic and hash algorithms within the data elements. This section brings these together by defining the specific SESAME mechanism identifiers which correspond to each combination of the available options under these headings. These specific mechanism identifiers are intended to be negotiable using a Baize, Farrell, Parker Document Expiration: 21 May 1996 [Page 48] internet-draft November 21, 1995 generic GSS-API negotiation scheme (like [SNEGO]). The approach is to use the key distribution schemes to form broad architectural mechanism options, as follows (more options are defined by ECMA, hence the numbering): Architectural Description of Key Distribution Mechanism Mechanism Option Scheme(s) Number 2 Symmetric key symmIntradomain distribution 3 Symmetric initiator symmIntradomain; and target; hybridInterdomain Asymmetric KD- Servers; 6 Asymmetric Initiator asymmetric and Target Table 7 - Key Distribution Mechanism Options Each of the security mechanism options described above represents a key distribution scheme. Generic GSS-API mechanism negotiation will be carried out on the basis of the generic SESAME mechanism OBJECT IDENTIFIER concatenated with an architectural mechanism number from table 7, and an algorithm profile reference number from table 6. Thus the form of a negotiable SESAME mechanism is: SESAME Mechanism OID , Y , Z ^ ^ | | | +-- algorithm | profile | +-- architectural option Thus a SESAME mechanism using a fully symmetric key distribution scheme and an exportable cryptographic algorithm profile would have an OBJECT IDENTIFIER of: { generic_sesame_mech (2) (3) } A SESAME mechanism using a fully asymmetric initiator and target architectural scheme, and an algorithm profile not supporting user data confidentiality would have an OBJECT IDENTIFIER of: { generic-sesame-mech (6) (2) } Not all combinations of key distribution scheme and algorithm profile are meaningful, however, but those that are, are intended Baize, Farrell, Parker Document Expiration: 21 May 1996 [Page 49] internet-draft November 21, 1995 to be negotiable using a generic GSS-API negotiation scheme such as [SNEGO]. Where information is returned from the target to the initiator as a result of negotiation then for the SESAME mechanism the information should contain the public key certificates required for the initiator to be able to use the selected KD-Scheme. For example, if the asymmetric KD-Scheme is to be used the target should return to the initiator the public key certificate of the targetAEF (containing the target's own name in the extensions field). The syntax of the mechanism specific information is the `Certificates' ASN.1 type defined in the AuthenticationFramework. (To allow multiple certificates to be passed to the initiator.) 7. NAME TYPES Because [Kerberos] does not support Directory Names (DNs), SESAME uses two distinct naming conventions, Kerberos and X.500. 7.1 Kerberos naming SESAME uses the Kerberos V5 Authentication Server protocol for password based authentication, so SESAME principals are given Kerberos principal names. Moreover, the SESAME security domain is equivalent to a Kerberos realm, so Kerberos realm names are used to identify SESAME security domains. In SESAME, an entity that uses the normal Kerberos V5 authentication via a password is given a printable Kerberos principal name of the form : @ Notes: 1. Components of a name can be separated by `/`. 2. The separator `@` signifies that the remainder of the string following the `@` is to be interpreted as a realm identifier. If no `@` is encountered, the name is interpreted in the context of the local realm. Once an `@` is encountered, a non-null realm name, with no embedded `/` separators, must follow. The `\` character is used to quote the immediately-following character. SESAME reserves two specific Kerberos principal names for its own use: - for the SESAME Security Server (containing the AS, PAS and KDS): krbtgt/@ - for the SESAME PVF : pvf//@ Baize, Farrell, Parker Document Expiration: 21 May 1996 [Page 50] internet-draft November 21, 1995 The realm_name in each of these constructs is repeated for compatibility with Kerberos. Note that a or a might take the form of an Internet Protocol domain name, and so a name like: pvf/mybox.bull.fr/sesame.bull.fr@sesame.bull.fr is a valid principal name for a SESAME PVF. When invoking gss_import_name, a Kerberos principal name type can be identified using either gss_ses_krb5_oid or GSS_KRB5_NT_PRINCIPAL_NAME symbolic names. A Kerberos service name type can be identified using either gss_ses_krb5_oid or GSS_KRB5_NT_HOSTBASED_ SERVICE_NAME symbolic names. 7.2 Directory Naming As described elsewhere, SESAME uses public key technology supported by Directory Certificates, so for this purpose SESAME entities are given DNs. Such names are built from components separated by a semicolon. The standardised keywords supported by SESAME are : CN (common-name). S (surname), OU (organisational-unit), O (organisation), C (country), So an example of a DN supported at SESAME is: CN=Martin;OU=sesame;O=bull;C=fr SESAME defines a set of reserved common-name parts for DNs for the core SESAME security components, as follows: the PAS: CN=SesamePAS.[;...] the AS: CN=SesameAS.[;...] the KDS: CN=SesameKDS.[;...] the PVF: CN=pvf.[;...] the security domain: CN=SesameDomain.[;...] where is the name of the Kerberos realm to which the entity belongs. Note that there is no generic rule for mapping the Directory Name of a SESAME entity to its Kerberos principal name, so SESAME provides an explicit mapping in a principal's Directory Certificate, using the extensions field of the extended Directory Certificate syntax (version 3) to carry the principal's Kerberos name. Baize, Farrell, Parker Document Expiration: 21 May 1996 [Page 51] internet-draft November 21, 1995 Note also that in the case of a PVF's Directory Certificate, the names of the applications supported by the PVF are also held in this field, preceded by the Kerberos principal name of the PVF itself. In the absence of such a certificate (i.e. if the PVF does not have a key pair of its own) the list of application names can be held (e.g. in a file) in the KDS. In SESAME the syntax of the Login Name is imported from the Kerberos Version 5 GSS-API Mechanism. This form of name is referred to using the symbolic name: GSS_KRB5_NT_PRINCIPAL. Syntax details are given in [KRB5GSS].When a principal possesses a private key for authentication, the login name is also stored in an extension field of the principal's Directory Certificate so that it can be linked to the principal's Distinguished Name. 8. ERROR CODES To be supplied. 9. SECURITY CONSIDERATIONS Security issues are discussed throughout this memo. 10. REFERENCES ECMA-219 ECMA-219, Authentication and Privilege Attribute Application with related key distribution functions GSS-API 1. Internet RFC 1508 Generic Security Service API (J. Linn, September 1993) 2. X/Open P308 Generic Security Service API (GSS-API) Base 3. Internet RFC 1509 "Generic Security Service API: C-Bindings" Kerberos Internet RFC 1510 The Kerberos Network Authentication Service (V5) (J. Kohl and C. Neumann, September 1993) ISO/IEC 9594-8 ISO/IEC 9594-8, Information Processing Systems - Open Systems Interconnection - The Directory - Part 8: Authentication Framework (X.509) KERB5GSS draft-ietf-cat-kerb5gss-03 The Kerberos Version 5 GSS-API Mechanism (J. Linn, September 1995) XGSSAPI draft-ietf-cat-xgssapi-sesame-00: Extended Generic Security Service APIs: XGSS-APIs (Denis Pinkas and Piers McMahon, November 1995) SESOV SESAME Overview, Version 4, (Tom Parker and Denis Pinkas, December 1995) Baize, Farrell, Parker Document Expiration: 21 May 1996 [Page 52] internet-draft November 21, 1995 SPKM draft-ietf-cat-spkmgss-04: The Simple Public-Key GSS-API Mechanism (C. Adams, May 1995) SNEGO draft-ietf-cat-snego-00 Simple GSS-API Negotiation Mechanism (Eric Baize and Denis Pinkas, July 1995) 11. AUTHOR'S ADDRESSES Eric Baize, BULL S.A., Rue Jean Jaures, 78340 LES CLAYES SOUS BOIS, FRANCE. email: E.Baize@frcl.bull.fr Stephen Farrell Software and Systems Engineering Ltd. Fitzwilliam Court, Dublin 2, IRELAND. email: Stephen.Farrell@sse.ie Tom Parker, ICL, Eskdale Road, Winnersh, Wokingham, Berkshire, UK RG11 5TT email: t.a.parker@win0199.wins.icl.co.uk APPENDIX A: ASN.1 MODULE DEFINITIONS A.1 SESAME ASN.1 Definitions SESAME-gss-api-types { tbs } DEFINITIONS ::= BEGIN -- exports everything IMPORTS Name FROM InformationFramework {joint-iso-ccitt(2) ds(5) module(1) informationFramework(1) } Baize, Farrell, Parker Document Expiration: 21 May 1996 [Page 53] internet-draft November 21, 1995 Certificate, AlgorithmIdentifier, Validity, CertificationPath FROM AuthenticationFramework {joint-iso-ccitt(2) ds(5) module(1) authenticationFramework(7) } HostAddress, Ticket FROM SESAME-Kerberos-Definitions { tbs } SPKM-REQ FROM SESAME-SPKM-Definitions { tbs }; -- OBJECT IDENTIFIERS access-identity-privilege ::= OBJECT IDENTIFIER { privilege-attribute 2 } audit-id-misc ::= OBJECT IDENTIFIER { misc-attribute 2 } generic-sesame-mech ::=OBJECT IDENTIFIER { tbs } generic-sesame-oids ::= OBJECT IDENTIFIER { tbs } -- top of the SESAME types arc group-privilege ::= OBJECT IDENTIFIER { privilege-attribute 4 } kd-schemes OBJECT IDENTIFIER ::= { generic-sesame-oids tbs } -- arc for SESAME key distribution schemes symmIntradomain OBJECT IDENTIFIER ::= {kd-schemes 1} hybridInterdomain OBJECT IDENTIFIER ::= {kd-schemes 3} asymmetric OBJECT IDENTIFIER ::= {kd-schemes 6} -- supported key distribution schemes misc-attribute OBJECT IDENTIFIER ::= { generic-sesame-oids misc-attribute(3) } -- OID below which miscellaneous attributes are defined primary-group-privilege ::= OBJECT IDENTIFIER{privilege-attribute 3} privilege-attributeOBJECT IDENTIFIER ::= { generic-sesame-oids privilege-attribute(4) } -- OID below which privilege attributes are defined qualifier-attribute OBJECT IDENTIFIER ::= { generic-sesame-oids qualifier-attribute (4) } -- OID below which qualifier attributes are defined role-privilege ::= OBJECT IDENTIFIER { privilege-attribute 1 } sesame-key-estb-alg AlgorithmIdentifier ::= {kd-schemes, NULL } Baize, Farrell, Parker Document Expiration: 21 May 1996 [Page 54] internet-draft November 21, 1995 -- indicates a SESAME key establishment structure within -- an SPKM_REQ structure target-name-qualifier OBJECT IDENTIFIER ::= { qualifier-attribute 1 } trust-group-qualifier OBJECT IDENTIFIER ::= { qualifier-attribute 2 } -- Types in alphabetical order AccessPrivilegeValueSyntax ::= Identifier AuditIdVlaueSyntax ::= Identifier CDTContents ::= SEQUENCE { tokenType [0] OCTET STRING VALUE X'0301', SAId [1] OCTET STRING, utcTime [2] UTCTime OPTIONAL, usec [3] INTEGER OPTIONAL, seq-number [4] INTEGER OPTIONAL, } CertandECV ::= SEQUENCE { certificate [0] GeneralisedCertificate, ecv [1] ECV, OPTIONAL} -- ECV is defined in later CertificateBody ::= CHOICE{ encryptedBody [0] BIT STRING, normalBody [1] SEQUENCE{ commonContents [0] CommonContents, specificContents[1] SpecificContents } } CertificateId ::=SEQUENCE { issuerDomain [0] Identifier OPTIONAL, issuerIdentity [1] Identifier, serialNumber [2] INTEGER } -- serialNumber is the same as in [ISO/IEC 9594-8] CheckValue ::= CHOICE{ signature [0] Signature -- only signature supported here } CommonContents ::= SEQUENCE{ comConSyntaxVersion [0] INTEGER { version1 (1) }DEFAULT 1, issuerDomain [1] Identifier OPTIONAL, issuerIdentity [2] Identifier, Baize, Farrell, Parker Document Expiration: 21 May 1996 [Page 55] internet-draft November 21, 1995 serialNumber [3] INTEGER, creationTime [4] UTCTime OPTIONAL, validity [5] Validity, algId [6] AlgorithmIdentifier, hashAlgId [7] AlgorithmIdentifier OPTIONAL } ContextDeleteToken ::= SEQUENCE { cdtContents [0] CDTContents, cdtSeal [1] Seal -- seal over cdtContents, encrypted -- under the Integrity Dialogue Key -- contains only the sealValue field } CValues ::= SEQUENCE OF SEQUENCE { index [0] INTEGER, value [1] BIT STRING } DialogueKeyBlock ::= SEQUENCE { integKeySeed [0] SeedValue, confKeySeed [1] SeedValue, integKeyDerivationInfo [2] KeyDerivationInfo OPTIONAL, confKeyDerivationInfo [3] KeyDerivationInfo OPTIONAL, integDKuseInfo [4] DKuseInfo OPTIONAL, confDKuseInfo [5] DKuseInfo OPTIONAL } DKuseInfo ::= SEQUENCE { useAlgId [0] AlgorithmIdentifier, useHashAlgId [1] AlgorithmIdentifier OPTIONAL } ECV ::= SEQUENCE { crypAlgIdentifier [0] AlgorithmIdentifier OPTIONAL, cValues [1] CHOICE { encryptedCvalueList [0] BIT STRING, individualCvalues [1] CValues } } ErrorArgument ::= ENUMERATED { gss_ses_s_sg_server_sec_assoc_open (1), gss_ses_s_sg_incomp_cert_syntax (2), gss_ses_s_sg_bad_cert_attributes (3), gss_ses_s_sg_inval_time_for_attrib (4), gss_ses_s_sg_pac_restrictions_prob (5), gss_ses_s_sg_issuer_problem (6), gss_ses_s_sg_cert_time_too_early (7), gss_ses_s_sg_cert_time_expired (8), Baize, Farrell, Parker Document Expiration: 21 May 1996 [Page 56] internet-draft November 21, 1995 gss_ses_s_sg_invalid_cert_prot (9), gss_ses_s_sg_revoked_cert (10), gss_ses_s_sg_key_constr_not_supp (11), gss_ses_s_sg_init_kd_server_ unknown (12), gss_ses_s_sg_init_unknown (13), gss_ses_s_sg_alg_problem_in_dialogue_key_block (14), gss_ses_s_sg_no_basic_key_for_dialogue_key_block (15), gss_ses_s_sg_key_distrib_prob (16), gss_ses_s_sg_invalid_user_cert_in_key_block (17), gss_ses_s_sg_unspecified (18), gss_ses_s_g_unavail_qop (19), gss_ses_s_sg_invalid_token_format (20) } ErrorToken ::= { tokenType [0] OCTET STRING VALUE X'0400', etContents [1] ErrorArgument, } GeneralisedCertificate ::= SEQUENCE{ certificateBody [0] CertificateBody, checkValue [1] CheckValue} GroupPrivilegeValueSyntax ::= SEQUENCE OF Identifier HashedNameInput ::= SEQUENCE { hniPlainKey [0] BIT STRING,-- the same value as plainKey hniIssuingKDS [1] Identifier } ICTContents ::= SEQUENCE { tokenId [0] INTEGER, -- shall contain X'0100' SAId [1] OCTET STRING, targetAEFPart [2] TargetAEFPart, targetAEFPartSeal [3] Seal, contextFlags [4] BIT STRING { delegation (0), mutual-auth (1), replay-detect (2), sequence (3), conf-avail (4), integ-avail (5) } utcTime [5] UTCTime OPTIONAL, usec [6] INTEGER OPTIONAL, seq-number [7] INTEGER OPTIONAL, initiatorAddress [8] HostAddress OPTIONAL, targetAddress [9] HostAddress OPTIONAL -- imported from [Kerberos] and used as channel bindings } Baize, Farrell, Parker Document Expiration: 21 May 1996 [Page 57] internet-draft November 21, 1995 Identifier ::= CHOICE{ objectId [0] OBJECT IDENTIFIER, directoryName [1] Name, -- imported from the Directory Standard printableName [2] PrintableString, octets [3] OCTET STRING, intVal [4] INTEGER, bits [5] BIT STRING, pairedName [6] SEQUENCE{ printableName [0] PrintableString, uniqueName [1] OCTET STRING } } InitialContextToken ::= SEQUENCE{ ictContents [0] ICTContents, ictSeal [1] Seal } KeyDerivationInfo::= SEQUENCE { owfId [0] AlgorithmIdentifier, keySize [1] INTEGER } KeyEstablishmentData ::= SEQUENCE { encryptedPlainKey [0] BIT STRING,-- encrypted PlainKey targetName [1] Identifier OPTIONAL, nameHashingAlg [2] AlgorithmIdentifier OPTIONAL } Method ::= SEQUENCE{ methodId [0] MethodId, methodParams [1] SEQUENCE OF Mparm OPTIONAL } MethodGroup ::= SEQUENCE OF Method MethodId ::= CHOICE{ predefinedMethod [0] ENUMERATED { controlProtectionValues (1), ppQualification (2), targetQualification (3), delegateTargetQualification (4) } } MICToken ::= PMToken Mparm ::= CHOICE{ Baize, Farrell, Parker Document Expiration: 21 May 1996 [Page 58] internet-draft November 21, 1995 pValue [0] PValue, securityAttribute [1] SecurityAttribute } PACSpecificContents ::= SEQUENCE{ pacSyntaxVersion [0] INTEGER{ version1 (1)} DEFAULT 1, protectionMethods [2] SEQUENCE OF MethodGroup OPTIONAL, pacType [4] ENUMERATED{ primaryPrincipal (1), temperedSecPrincipal (2), untemperedSecPrincipal(3) } DEFAULT 3, privileges [5] SEQUENCE OF PrivilegeAttribute, restrictions [6] SEQUENCE OF Restriction OPTIONAL, miscellaneousAtts [7] SEQUENCE OF SecurityAttribute OPTIONAL, timePeriods [8] TimePeriods OPTIONAL } PlainKey ::= SEQUENCE { plainKey [0] BIT STRING, -- The cleartext key hashedName [1] BIT STRING } PMTContents ::= SEQUENCE { tokenId [0] INTEGER, -- shall contain X'0101' SAId [1] OCTET STRING, seq-number [2] INTEGER OPTIONAL, userData [3] CHOICE { plaintextBIT STRING, ciphertext OCTET STRING } OPTIONAL, directionIndicator [4] BOOLEAN OPTIONAL } PMToken ::= SEQUENCE{ pmtContents [0] PMTContents, pmtSeal [1] Seal -- seal over the pmtContents being protected } PrimaryGroupValueSyntax ::= Identifier PrivilegeAttribute ::= SecurityAttribute PublicKeyBlock ::= SEQUENCE{ signedPKBPart [0] SignedPKBPart, signature [1] Signature OPTIONAL, certificate [2] Certificate OPTIONAL } Baize, Farrell, Parker Document Expiration: 21 May 1996 [Page 59] internet-draft November 21, 1995 PublicTicket ::= SEQUENCE{ krb5Ticket [0] Ticket, publicKeyBlock [1] PublicKeyBlock} PValue ::= SEQUENCE{ pv [0] BIT STRING, algorithmIdentifier [1] AlgorithmIdentifier OPTIONAL } Restriction ::= SEQUENCE { howDefined [0] CHOICE { hashedExternal [0] BIT STRING, -- the hash value signedExternal [1] BIT STRING, -- the public key certExternal [2] CertificateId, -- user certificate included [3] BIT STRING }, -- the actual restriction in a form -- undefined here algId [1] AlgorithmIdentifier OPTIONAL, -- either identifies the hash algorithm -- or the public key algorithm -- for choices 1 or 2 above. type [2] ENUMERATED { mandatory (1), optional (2)} DEFAULT mandatory, targets [3] SEQUENCE OF SecurityAttribute OPTIONAL } -- applies to all targets if this is omitted RolePrivilegeValueSyntax ::= Identifier Seal ::= SEQUENCE{ sealValue [0] BIT STRING, symmetricAlgId [1] AlgorithmIdentifier OPTIONAL, hashAlgId [2] AlgorithmIdentifier OPTIONAL, targetName [3] Identifier OPTIONAL, keyId [4] INTEGER OPTIONAL } SecurityAttribute ::= SEQUENCE{ attributeType Identifier, attributeValue SET OF SEQUENCE { definingAuthority [0] Identifier OPTIONAL, securityValue [1] SecurityValue } } -- NOTE: SecurityAttribute is not tagged, for compatibility -- with the Directory Standard. SecurityValue ::= CHOICE{ Baize, Farrell, Parker Document Expiration: 21 May 1996 [Page 60] internet-draft November 21, 1995 directoryName [0] Name, printableName [1] PrintableString, octets [2] OCTET STRING, intVal [3] INTEGER, bits [4] BIT STRING, any [5] ANY -- defined by attributeType } SeedValue ::= SEQUENCE { timeStamp [0] UTCTime OPTIONAL, random [1] BIT STRING } SESAME-AUTHORISATION-DATA ::= SEQUENCE { sesame-ad-type [0] ENUMERATED { ppidType (0) }, sesame-ad-value [1] CHOICE { ppidValue [0]SecurityAttribute } } SESAME-AUTHORISATION-DATA-TYPE ::= INTEGER { SESAME-ADATA (65) } Signature ::= SEQUENCE{ signatureValue [0] BIT STRING, asymmetricAlgId [1] AlgorithmIdentifier OPTIONAL, hashAlgId [2] AlgorithmIdentifier OPTIONAL, issuerCAName [3] Identifier OPTIONAL, caCertInformation [4] CHOICE { caCertSerialNumber [0] INTEGER, certificationPath [1] CertificationPath } OPTIONAL } --CertificationPath is imported from [ISO/IEC 9594-8] SignedPKBPart ::= SEQUENCE{ keyEstablishmentData [0] KeyEstablishmentData, encryptionMethod [1] AlgorithmIdentifier OPTIONAL, issuingKDS [2] Identifier, uniqueNumber [3] UniqueNumber, validityTime [4] TimePeriods, creationTime [5] UTCTime } SpecificContents ::= CHOICE{ pac [1] PACSpecificContents -- only the PAC is used here } Baize, Farrell, Parker Document Expiration: 21 May 1996 [Page 61] internet-draft November 21, 1995 TargetAEFPart ::= SEQUENCE { pacAndCVs [0] SEQUENCE OF CertandECV OPTIONAL, targetKeyBlock [1] TargetKeyBlock, dialogueKeyBlock [2] DialogueKeyBlock, targetIdentity [3] Identifier, flags [4] BIT STRING { delegation (0) } } TargetKeyBlock ::= SEQUENCE { kdSchemeOID [2] OBJECT IDENTIFIER, targetKDSpart [3] ANY OPTIONAL, -- depending on kdSchemeOID targetPart [4] ANY OPTIONAL -- depending on kdSchemeOID } TargetNameValueSyntax ::= Identifier TargetResultToken ::= SEQUENCE{ trtContents [0] TRTContents, trtSeal [1] Seal } Token ::= [APPLICATION 0] IMPLICIT SEQUENCE { thisMech MechType, -- the OBJECT IDENTIFIER specified below innerContextToken ANY DEFINED BY thisMech } TRTContents ::= SEQUENCE { tokenId [0] INTEGER, -- shall contain X'0200' SAId [1] OCTET STRING, utcTime [5] UTCTime OPTIONAL, usec [6] INTEGER OPTIONAL, seq-number [7] INTEGER OPTIONAL, } TrustGroupValueSyntax ::= Identifier UniqueNumber ::= SEQUENCE{ timeStamp [0] UTCTime, random [1] BIT STRING } Validity ::=SEQUENCE { notBefore UTCTime, notAfter UTCTime } -- as in [ISO/IEC 9594-8] Baize, Farrell, Parker Document Expiration: 21 May 1996 [Page 62] internet-draft November 21, 1995 -- Note: Validity is not tagged, for compatibility with the -- Directory Standard. WrapToken ::= PMToken END A.2 Kerberos ASN.1 Definitions The SESAME GSS-API mechanism re-uses the HostAddress and Ticket types from [Kerberos]. These are reproduced here for ease of reference. SESAME-Kerberos-Definitions {tbs } DEFINITIONS ::= BEGIN -- exports everything IMPORTS -- imports nothing -- data types AuthorizationData ::= SEQUENCE OF SEQUENCE { ad-type [0] INTEGER, ad-data [1] OCTET STRING} EncryptedData ::= SEQUENCE { etype [0] INTEGER, -- EncryptionType kvno [1] INTEGER OPTIONAL, cipher [2] OCTET STRING _ciphertext} EncryptionKey ::= SEQUENCE { keytype [0] INTEGER, keyvalue [1] OCTET STRING} EncTicketPart ::= [APPLICATION 3] SEQUENCE { flags [0] TicketFlags, key [1] EncryptionKey, crealm [2] Realm, cname [3] PrincipalName, transited [4] TransitedEncoding, authtime [5] KerberosTime, starttime [6] KerberosTime OPTIONAL, endtime [7] KerberosTime, Baize, Farrell, Parker Document Expiration: 21 May 1996 [Page 63] internet-draft November 21, 1995 renew-till [8] KerberosTime OPTIONAL, caddr [9] HostAddresses OPTIONAL, authorization-data [10] AuthorizationData OPTIONAL} HostAddress ::= SEQUENCE { addr-type [0] INTEGER, address [1] OCTET STRING} HostAddresses ::= SEQUENCE OF SEQUENCE { addr-type [0] INTEGER, address [1] OCTET STRING} KerberosTime ::= GeneralizedTime -- Specifying UTC time zone (Z) PrincipalName ::= SEQUENCE { name-type [0] INTEGER, name-string [1] SEQUENCE OF GeneralString} Realm ::= GeneralString Ticket ::= [APPLICATION 1] SEQUENCE { tkt-vno [0] INTEGER, realm [1] Realm, sname [2] PrincipalName, enc-part [3] EncryptedData} -- decrypts to EncTicketPart TicketFlags ::= BIT STRING { reserved (0), -- not supported in the SESAME mechanism forwardable (1), -- not supported in the SESAME mechanism forwarded (2), -- not supported in the SESAME mechanism proxiable (3), -- not supported in the SESAME mechanism proxy (4), -- not supported in the SESAME mechanism may-postdate (5), -- not supported in the SESAME mechanism postdated (6), invalid (7), -- not supported in the SESAME mechanism renewable (8), -- not supported in the SESAME mechanism initial (9), -- not supported in the SESAME mechanism pre-authent (10), hw-authent (11)} TransitedEncoding ::= SEQUENCE { tr-type [0] INTEGER, -- must be registered contents [1] OCTET STRING} -- the TransitedEncoding construct is not used in the SESAME mechanism. END Baize, Farrell, Parker Document Expiration: 21 May 1996 [Page 64] internet-draft November 21, 1995 A.3 SPKM ASN.1 Definitions The SESAME GSS-API mechanism re-uses the SPKM-REQ type from [SPKM]. These are reproduced here for ease of reference. SESAME-SPKM-Definitions {tbs } DEFINITIONS ::= BEGIN -- exports everything IMPORTS AuthorizationData FROM SESAME-Kerberos-Defintions { tbs } AlgorithmIdentifier, Certificate, CertificateList, CertificatePair, CertificatePath FROM AuthenticationFramework { joint-iso-ccitt ds(5) modules(1) authenticationFramework(7) } Name FROM InformationFramework { joint-iso-ccitt ds(5) modules(1) informationFramework(1) } -- data types CertificationData ::= SEQUENCE { certificationPath [0] CertificationPath OPTIONAL, certificateRevocationList [1] CertificateList OPTIONAL } -- at least one of the above shall be present CertificationPath ::= SEQUENCE { userKeyId [0] OCTET STRING OPTIONAL, -- identifier for user's public key userCertif [1] Certificate OPTIONAL, -- certificate containing user's public key verifKeyId [2] OCTET STRING OPTIONAL, -- identifier for user's public verification key Baize, Farrell, Parker Document Expiration: 21 May 1996 [Page 65] internet-draft November 21, 1995 userVerifCertif [3] Certificate OPTIONAL, -- certificate containing user's public verification key theCACertificates [4] SEQUENCE OF CertificatePair OPTIONAL -- certification path from target to source } ChannelId ::= OCTET STRING Conf_Algs ::= CHOICE { SEQUENCE OF AlgorithmIdentifier, NULL -- used when conf. is not available over context } -- for C-ALG Context_Data ::= SEQUENCE { channelId ChannelId, -- channel bindings seq_number INTEGER OPTIONAL, -- sequence number options Options, conf_alg Conf_Algs, -- confidentiality. algs. intg_alg Intg_Algs -- integrity algorithm } ENCRYPTED MACRO ::= BEGIN TYPE NOTATION ::= type(ToBeEnciphered) VALUE NOTATION ::= value(VALUE BIT STRING) END -- of ENCRYPTED HASHED MACRO ::= BEGIN TYPE NOTATION ::= type ( ToBeHashed ) VALUE NOTATION ::= value ( VALUE OCTET STRING ) END -- hash used is the one specified for the MANDATORY I-ALG Intg_Algs ::= SEQUENCE OF AlgorithmIdentifier -- for I-ALG Key_Estb_Algs ::= SEQUENCE OF AlgorithmIdentifier -- to allow negotiation of K-ALG MAC MACRO ::= BEGIN TYPE NOTATION ::= type ( ToBeMACed ) VALUE NOTATION ::= value ( VALUE SEQUENCE { algId AlgorithmIdentifier, mac BIT STRING } Baize, Farrell, Parker Document Expiration: 21 May 1996 [Page 66] internet-draft November 21, 1995 ) END Options ::= BIT STRING { delegation_state (0), mutual_state (1), replay_det_state (2), -- used for replay det. during context sequence_state (3), -- used for sequencing during context conf_avail (4), integ_avail (5), target_certif_data_required (6) -- used to request targ's certif. data } Random_Integer ::= BIT STRING Req_Integrity ::= CHOICE { sig_integ [0] SIGNATURE REQ_TOKEN, mac_integ [1] MAC REQ_TOKEN } REQ_TOKEN ::= SEQUENCE { tok_id INTEGER, -- shall contain 0100 (hex) context_id Random_Integer, pvno BIT STRING, -- protocol version number timestamp UTCTime OPTIONAL, -- mandatory for SPKM-2 randSrc Random_Integer, targ_name Name, src_name Name, -- may be a value indicating "anonymous" req_data Context_Data, validity [0] Validity OPTIONAL, -- validity interval for key (may be used in the -- computation of security context lifetime) key_estb_set [1] Key_Estb_Algs, -- specifies set of key establishment algorithms key_estb_req BIT STRING OPTIONAL, -- key estb. parameter corresponding to first K-ALG in set -- (not used if initiator is unable or unwilling to -- generate and securely transmit key material to target). -- Established key must be sufficiently long Baize, Farrell, Parker Document Expiration: 21 May 1996 [Page 67] internet-draft November 21, 1995 to be used -- with any of the offered confidentiality algorithms. key_src_bind HASHED SEQUENCE { src_name Name, symm_key BIT STRING}OPTIONAL -- used to bind the source name to the symmetric key -- (i.e., the unprotected version of what is -- transmitted in key_estb_req). } SIGNATURE MACRO ::= BEGIN TYPE NOTATION ::= type (OfSignature) VALUE NOTATION ::= value(VALUE SEQUENCE { AlgorithmIdentifier, ENCRYPTED OCTET STRING } ) END SPKM_REQ ::= SEQUENCE { requestToken REQ_TOKEN, req_integrity Req_Integrity, certif_data [2] CertificationData OPTIONAL, auth_data [3] AuthorizationData OPTIONAL -- see [Kerberos] for a discussion of authorization data } Validity ::= SEQUENCE { notBefore UTCTime, notAfter UTCTime } END APPENDIX B: ECMA BACKGROUND MATERIAL. ECMA's work was based on the OSI Architecture [ISO 7498-2], and the series of Security Frameworks developed in ISO/IEC JTC1 [ISO 10181]. A Technical Report, [ECMA TR/46] published in 1988, concentrates on the application layer and describes a security framework in terms of application functions necessary to build secure open systems. The continuation of this report, [ECMA-138], defines the abstract security services for use in a distributed system. A parallel standard, [ECMA-206], describes a model for establishing secure relationships between applications in a distributed system. ECMA has recently completed work to define the functionality and the protocols for a distributed security service in charge of authenticating and distributing access Baize, Farrell, Parker Document Expiration: 21 May 1996 [Page 68] internet-draft November 21, 1995 rights to human and application principals, along with supportive key distribution functions. The ECMA standard which is the result of that work is called ECMA-219 [ECMA-219]. It was approved by the ECMA General Assembly in December 1994 and released in January 1995. ECMA is currently developing a standard parallel to this draft which standardises the use of the ECMA security mechanism below the GSS-API. This draft is effectively a profile of that work. APPENDIX C: SESAME IMPLEMENTATION STATUS The SESAME project has implemented the above protocols and source code for this will be made publicly available for non-commercial use at the end of 1995 as SESAME version 4. There are however, some minor differences between this specification and the SESAME version 4 implementation - mainly due to the fact that this specification assumes the use of a generic GSS-API negotiation scheme (like [SNEGO]) whereas SESAME version 4 implements negotiation within the tokens according to the standard ECMA-206 (Association Context Management).