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