ISO/IEC 10181-1:1996

Information technology - Open Systems Interconnection - Security frameworks for open systems: Overview

Technologies de l'information — Interconnexion de systèmes ouverts (OSI) — Cadres de sécurité pour les systèmes ouverts: Aperçu

General Information

• Status: Published
• Publication Date: 24-Jul-1996
• ICS: 35.100.01 - Open systems interconnection in general
• Technical Committee: ISO/IEC JTC 1 - Information technology
• Drafting Committee: ISO/IEC JTC 1 - Information technology
• Current Stage: 9093 - International Standard confirmed
• Start Date: 20-Sep-2006
• Completion Date: 30-Oct-2025

Overview

ISO/IEC 10181-1:1996 - Information technology - Open Systems Interconnection - Security frameworks for open systems: Overview - defines the conceptual framework and common terminology for security services in open systems (OSI, distributed applications, databases, ODP). Published as the first part of a multi-part Security Framework (Parts 1–7), this standard establishes the organization, definitions and inter-relationships among security services and mechanisms without prescribing implementation details or construction methodologies. It is identical to ITU‑T Recommendation X.810.

Key topics and technical scope

• Security framework organization: structure of the multi-part framework and how individual parts (Authentication, Access Control, Non‑repudiation, Confidentiality, Integrity, Security Audit and Alarms, Key Management) fit together.
• Common concepts and definitions: consistent terminology for security policy, security domain, trusted entities, trust relationships, and security information.
• Generic security information: security labels, cryptographic checkvalues, security certificates (structure, verification/chaining, revocation, reuse), and security tokens.
• Management and operational facilities: lifecycle operations for security information-install, deinstall, change, validate/invalidate, enable/disable, enrol/un-enrol, distribute, list, generate, acquire, verify.
• Interactions and dependencies: how one security service may rely on others (e.g., authentication underpinning access control or non‑repudiation).
• Availability and denial-of-service considerations: treatment of availability risks and DoS in an open systems environment.
• Guidance & examples: annexes giving example protection mechanisms for certificates and a bibliography for further reading.

Practical applications

ISO/IEC 10181-1 provides the conceptual backbone for:

• Designing security architectures for distributed systems and OSI-based environments.
• Specifying interoperable, abstract security service interfaces for products and protocols.
• Defining policy and trust models (security domains, certification authorities) for multi‑domain interactions.
• Framing requirements for certificate management, lifecycle, and cross-domain verification.

Use cases include secure distributed databases, enterprise middleware, federated identity and certificate-based authentication, and security requirement definitions in procurement or standards development.

Who should use this standard

• Security architects and system designers creating OSI/distributed system security architectures.
• Product and protocol designers who need consistent terminology and abstract service definitions.
• Standards developers, auditors, and organizations defining cross‑domain trust and certificate management.
• Project leads specifying security policy and service dependencies.

Related standards

• ISO/IEC 7498-1 (Basic Reference Model)
• ISO/IEC 7498-2 / CCITT X.800 (Security Architecture)
• ITU‑T X.810 (identical text)

Keywords: ISO/IEC 10181-1, security frameworks, open systems, OSI security, security certificates, authentication, access control, confidentiality, integrity, non-repudiation, key management, security policy.

Standards Content (Sample)

INTERNATIONAL lSO/IEC
STANDARD
10181~1
First edition
1996-08-o 1
Information technology - Open Systems
Interconnection - Security frameworks for
open systems: Overview
Technologies de I ‘in formation -
In terconnexion de sys t&mes ouverts
(09) - Cadre pour la s&wit6 dans les systemes ouverts: PGsentation
Reference number
lSO/IEC 10181-1 :I 996(E)
CONTENTS
Page
1 Scope .
.....................................................................................................................................
2 Normative references
........................................................................
2.1 Identical Recommendations I International Standards
.......................... 1
2.2 Paired Recommendations I International Standards equivalent in technical content
3 Definitions .
.....................................................................................................
31 Basic Reference Model definitions
.........................................................................................................
3:2 Security architecture definitions
.........................................................................................................................
3.3 Additional definitions
.................................................................................................................................................
4 Abbreviations
..........................................................................................................................................................
5 Notation
...................................................................................................................................................
6 Organization
Part 1 - Overview .
61 .
6.2 Part 2 - Authentication .
.......................................................................................................................
6.3 Part 3 - Access control
.....................................................................................................................
6.4 Part 4 - Non-repudiation
.......................................................................................................................
65 Part 5 - Confidentiality
.................................................................................................................................
616 Part 6 - Integrity
......................................................................................................
67 . Part 7 - Security audit and alarms
................................................................................................................................
68 . Key management
..........................................................................................................................................
7 Common concepts
7.1 Security information .
..................................................................................................................................
7.2 Security domain
..........................................................................
Security policy and security policy rules
7.2.1
.................................................................................................
7.2.2 Security domain authority
.....................................................................
Inter-relationships among security domains
7.2.3
..........................................................................
7.2.4 Establishment of secure interaction rules
.......................................................................
Inter-domain security information transfer
7.2.5
..............................................................
Security policy considerations for specific security services
7.3
....................................................................................................................................
7.4 Trusted entities
....................................................................................................................................................
7.5 Trust
Trusted third parties .
7.6
..........................................................................................................................
8 Generic security information
81 Security labels .
.................................................................................................................
812 Cryptographic checkvalues
.............................................................................................................................
8.3 Security certificates
...................................................................................
Introduction to security certificates
8.3.1
............................................................. 12
Verification and chaining of security certificates
8.3.2
....................................................................................
8.3.3 Revocation of security certificates
Re-use of security certificates .
8.3.4
.............................................................................................
8.3.5 Security certificate structure
84 . Security tokens .
@ ISO/IEC 1996
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or
utilized in any form or by any means, electronic or mechanical, including photocopying and micro-
film, without permission in writing from the publisher.
ISO/IEC Copyright Office l Case postale 56 l CH-1211 Geneve 20 l Switzerland
Printed in Switzerland
ii
ISO/IEC 101814:1996(E)
0 ISO/IEC
9 Generic security facilities . 13
Management related facilities . 13
9.1
9.1.1 Install SI . 13
Deinstall SI . 13
9.1.2
9.1.3 Change SI .
........................................................................................................................ 14
9.1.4 Validate SI
Invalidate SI . 14
9.1.5
Disable/Be-enable security service . 14
9.1.6
Enrol . 14
9.1.7
9.1.8 Un-enrol .
...................................................................................................................... 14
9.1.9 Distribute SI
9.1.10 List SI . 14
9.2 Operational related facilities . 14
Identify trusted security authorities . 14
9.2.1
9.2.2 Identify secure interaction rules . 14
......................................................................................................................... 14
9.2.3 Acquire SI
Generate SI . 14
9.2.4
9.2.5 Verify SI . 15
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .*.*.
10 Interactions between security mechanisms 15
. . . . . . . . . . . .*. 15
11 Denial of service and availability
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .*. 16
12 Other requirements
.....................................................
Annex A - Some examples of protection mechanisms for security certificates 17
Protection using an OS1 communications security service . 17
A.1
............................................................... 17
A.2 Protection using a parameter within the security certificate
A.2.1 The authentication method . 17
...................................................................................................... 17
A.2.2 The secret key method
A.2.3 The public key method . 18
A.2.4 The one-way function method . 18
..................................................... 18
A.3 Protection of the internal and external parameters while in transit
A.3.1 Transfer of internal parameters to the issuing security authority . 18
Transfer of external parameters among entities . 18
A.3.2
................................................
A.4 Use of security certificates by single entities or by groups of entities 19
........................................................................................
A.5 Linking a security certificate with accesses 19
Annex B - Bibliography . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . .
0 ISO/IEC
ISO/IEC 10181=1:1996(E)
Foreword
IS0 (the International Organization for Standardization) and IEC (the Inter-
national Electrotechnical Commission) form the specialized system for worldwide
standardization. National bodies that are members of IS0 or IEC participate in the
development of International Standards through technical committees established
by the respective organization to deal with particular fields of technical activity.
IS0 and IEC technical committees collaborate in fields of mutual interest. Other
international organizations, governmental and non-governmental, in liaison with
IS0 and IEC, also take part in the work.
In the field of information technology, IS0 and IEC have established a joint
technical committee, ISO/IEC JTC 1. Draft International Standards adopted by the
joint technical committee are circulated to national bodies for voting. Publication
as an International Standard requires approval by at least 75 % of the national
bodies casting a vote.
International Standard ISO/IEC 1018 l-l was prepared by Joint Technical Com-
mittee ISO/IEC JTC 1, Information technology, Subcommittee SC 21, Open
data management and open distributed processing,
systems interconnection,
in collaboration with ITU-T. The identical text is published as ITU-T Recommen-
dation X.810.
Part I: Overview
Part 2: Authentication framework
Part 3: Access control framework
Part 4: Non-repudiation framework
- Part 5: Confidentiality framework
Part 6: Integrity framework
Part 7: Security audit and alarms framework
Annexes A and B of this part of ISO/IEC 1018 1 are for information only.
1v
@ ISOIIEC
Introduction
Many applications have requirements for security to protect against threats to the communication of information. Some
commonly known threats, together with the security services and mechanisms that can be used to protect against them
are described in CCITT Rec. X.800 I IS0 7498-2.
This Recommendation I International Standard defines the framework within which security services for open systems
are specified.
This page intentionally left blank

HSO/IEC 10181-l : 1996 (E)
INTERNATIONAL STANDARD
IT&T RECOMMENDATION
INFORMATION TECHNOLOGY - OPEN SYSTEMS INTERCONNECTION -
SECURITY FRAMEWORKS FOR OPEN SYSTEMS: OVERVIEW
1 Scope
The security frameworks address the application of security services in an Open Systems environment, where the term
Open Systems is taken to include areas such as Database, Distributed Applications, ODP and OSI. The security
frameworks are concerned with defining the means of providing protection for systems and objects within systems, and
with the interactions between systems. The security frameworks are not concerned with the methodology for
constructing systems or mechanisms.
The security frameworks address both data elements and sequences of operations (but not protocol elements) which are
used to obtain specific security services. These security services may apply to the communicating entities of systems as
well as to data exchanged between systems, and to data managed by systems.
The security frameworks provide the basis for further standardization, providing consistent terminology and definitions
of generic abstract service interfaces for specific security requirements. They also categorize the mechanisms that can be
used to achieve those requirements.
One security service frequently depends on other security services, making it difficult to isolate one part of security from
the others. The security frameworks address particular security services, describe the range of mechanisms that can be
used to provide the security services, and identify interdependancies between the services and the mechanisms. The
description of these mechanisms may involve a reliance on a different security service, and it is in this way that the
security frameworks describe the reliance of one security service on another.
frameworks:
This part of the security
-
describes the organization of the security frameworks;
-
defines security concepts which are required in more than one part of the security frameworks;
-
describes the inter-relationship of the services and mechanisms identified in other parts of the
frameworks.
2 Normative references
The following Recommendations and International Standards contain provisions, which through reference in this text,
constitute provisions of this Recommendation I International Standard. At the time of publication, the editions indicated
were valid. All Recommendations and Standards are subject to revision, and parties to agreements based on this
Recommendation I International Standard are encouraged to investigate the possibility of applying the most recent
edition of the Recommendations and Standards indicated below. Members of IEC and IS0 maintain registers of
currently valid International Standards. The Telecommunication Standardization Bureau of the ITU maintains a list of
currently valid ITU Recommendations.
21 0 Identical Recommendations I International Standards
-
ITU-T Recommendation X.200 (1994) I ISO/IEC 7498-l: 1994, Information technology - Open Systems
Interconnection - Basic Reference Model: The Basic Model.
22 . Paired Recommendations I International Standards equivalent in technical content
-
CCITT Recommendation X.800 (1991), Security architecture for Open Systems Interconnection for
CCITT applications.
IS0 7498-2: 1989, Znformation processing systems - Open Systems Interconnection - Basic Reference
Model - Part 2: Security Architecture.
IT&T Rec. X.810 (1995 E)
ISO/IEC! 101814 : 1996 (E)
3 Definitions
in the overview or are common to two or more of the
The following definitions are used subsequent parts of the
security frameworks.
I International Standard, the following definitions apply.
For the purposes of this Recommendation
Basic Reference Model definitions
31 .
This Recommendation I International Standard makes use of the following terms defined in ITU-T Rec. X.200 I
ISO/IEC 7498- 1:
- (N)-layer;
- (N)-entity;
-
(N)-protocol-data-unit;
-
application process;
-
real open system;
-
real system.
32 0 Security architecture definitions
This Recommendation I International Standard makes use of the following terms defined in CCITT Rec. X.800 I
IS0 7498-2:
-
access control;
-
availability;
cipher-text;
-
cryptographic checkvalue;
-
decipherment;
-
denial of service;
-
digital signature;
-
encipherment;
-
insider threat;
-
key;
-
key management;
-
plaintext;
-
outsider threat;
-
security audit;
-
security label;
-
security policy;
sensitivity;
-
threat.
33 . Additional definitions
For the purposes of this Recommendation I International Standard, the following definitions apply:
3.3.1 asymmetric cryptographic algorithm: An algorithm for performing encipherment or the corresponding
decipherment in which the keys used for encipherment and decipherment differ.
NOTE - With some asymmetric cryptographic algorithms, decipherment of ciphertext or the generation of a digital
signature requires the use of more than one private key.
An entity that is trusted (in the context of a security
3.3.2 certification authority: policy) to create security
certificates containing one or more classes of security-relevant data.
3.3.3 An entity that is trusted in the context of a security policy, but which
conditionally trusted entity: cannot
violate the security policy without being detected.
2 IT&T Rec. X.810 (1995 E)
ISO/IEC 10181-l : 1996 (E)
cryptographic chaining: A mode of use of a cryptographic algorithm in which the transformation performed
3.3.4
by the algorithm depends on the values of previous inputs or outputs.
3.3.5 digital fingerprint: A characteristic of a data item, such as a cryptographic checkvalue or the result of
performing a one-way hash function on the data, that is sufficiently peculiar to the data item that it is computationally
infeasible to find another data item that will possess the same characteristics.
distinguishing identifier: Data that uniquely identifies an entity.
3.3.6
(mathematical) function that maps values from a (possibly very) large set of values into a
3.3.7 hash function: A
smaller range of values.
3.3.8 one-way function: A (mathematical) function that is easy to compute but, when knowing a result, it is
computationally infeasible to find any of the values that may have been supplied to obtain it.
one-way hash function: A (mathematical) function that is both a one-way function and a hash function.
3.3.9
cryptographic algorithm and whose possession is restricted
3.3.10 private key: A key that is used with an asymmetric
(usually to only one en .tity).
3.3.11 public key: A key that is used with an asymmetric cryptographic algorithm and that can be made publicly
available.
3.3.12 revocation certificate: A security certificate issued by a security authority to indicate that a particular security
certificate has been revoked.
3.3.13 revocation list certificate: A security certificate that identifies a list of security certificates that have been
revoked.
3.3.14 seal: A cryptographic checkvalue that supports integrity but does not protect against forgery by the recipient
(i.e. it does not provide non-repudiation). When a seal is associated with a data element, that data element is said to be
sealed.
NOTE - Although a seal does not by itself provide non-repudiation, some non-repudiation mechanisms make use of the
integrity service provided by seals, e.g. to protect communications with trusted third parties.
3.3.15 secret key: A key that is used with a symmetric cryptographic algorithm. Possession of a secret key is
restricted (usually to two entities).
3.3.16 security administrator: A person who is responsible for the definition or enforcement of one or more parts of
a security policy.
3.3.17 security authority: An entity that is responsible for the definition, implementation or enforcement of security
policy.
3.3.18 security certificate: A set of security-relevant data issued by a security authority or trusted third party,
together with security information which is used to provide the integrity and data origin authentication services for the
data.
NOTE - All certificates are deemed to be security certificates (see the relevant definitions in IS0 7498-2). The term
security certzjicate is adopted in order to avoid terminology conflicts with ITU-T Rec. X.509 I ISO/IEC 9594-8 (i.e. the directory
authentication standard).
3.3.19 security certificate chain: An ordered sequence of security certificates, in which the first security certificate
contains security-relevant information, and each subsequent security certificate contains security information which can
be used in the verification of previous security certificates.
security domain: A set of elements, a security policy, a security authority and a set of security-relevant
3.3.20
activities in which the set of elements are subject to the security policy for the specified activities, and the security policy
is administered by the security authority for the security domain.
authority: A security responsible for the implementation
3.3.21 security domain ty that is ofa security policy
for a security domain.
3.3.22 security information: Information needed to implement security services.
3.3.23 security recovery: Actions that are taken and procedures that are carried out when a violation of security is
either detected or suspected to have taken place.
3.3.24 secure interaction ruIes: Security policy rules that regulate interactions between security domains.
3.3.25 security policy rules: A representation of a security policy for a security domain within a real system.
ITU-T Rec. X.810 (1995 E)
ISO/IEC 10181-l : 1996 (E)
one or more security services, together with security i .nformation
3.3.26 security token: A set of data protected by
transferred between communicating entities.
used in the provision of those security services, that is
algorithm: An algorithm for performing enciphermen t or the corresponding
3.3.27 symmetric cryptographic
red for both encipherment and decipherment.
algorithm t in which the same key is requi
for performing deciphermen
3.3.28 trust: Entity X is said to trust entity y for a set of activities if and only if entity X relies upon entity Y
behaving in a particular way with respect to the activities.
3.3.29 trusted entity: An entity that can violate a security policy, either by performing actions which it is not
supposed to do, or by failing to perform actions which it is supposed to do.
3.3.30 trusted third party: A security authority or its agent that is trusted with respect to some security-relevant
activities (in the context of a security policy).
3.3.31 unconditionally trusted entity: A trusted entity that can violate a security policy without being detected,
4 Abbreviations
For the purposes of this Recommendation I International Standard, the following abbreviations apply:
AC1 Access Control Information
OS1 Open Systems Interconnection
ODP Open Distributed Processing
SI Security Information
TTP Trusted Third Party
Notation
The layer notation used is the same as that defined in ITU-T Rec. X.200 I ISOLIEC 7498-1.
The term sewice, where not otherwise qualified, is used to refer to a security service.
The term certificate, where not otherwise qualified, is used to refer to a security certificate.
6 Organization
The securitv frameworks are Parts of a multi-part International Standard (ISO/IEC 1018 1) and a series of ITU
Recommendations. The security frameworks are described below. Additional security frameworks may be identified in
the future. The key management framework is not a part of ISO/IEC 10181, but it has a similar scope and its description
is included for completeness.
61 0 Part 1 - Overview
See clause 1.
62 0 Part 2 - Authentication
This framework describes all aspects of authenticati
.on as these to Open Systems, the relationship of authenti .cation
apply
with other security functions such as access control and the management requirements for authentication.
This framework:
a) defines the basic concepts of authentication;
identifies the possible classes of authentication mechanisms;
b)
defines the services for these classes of authentication mechanism;
C)
identifies functional requirements for protocols to support these classes of authentication mechanism; and
identifies general management requirements for authentication.
e>
4 ITU-T Rec. X.810 (1995 E)
ISO/IEC 10181-l : 1996 (E)
The Authentication Framework occupies a position at the top of a hierarchy of authentication standards that provide
concepts, nomenclature and a classification for authentication methods. Directly below it, standards such as
ISO/IEC 9798 (Entity Authentication Mechanisms) provide a particular set of these methods in more detail. Finally, at
the bottom of the hierarchy, standards such as ITU-T Rec. X.509 I ISO/IEC 9594-8 (the Directory Authentication
Framework) use these concepts and methods in the context of a specific application or requirement.
The Authentication Framework describes a model of authentication, a number of phases into which authentication
activities can be categorized, the use of a trusted third party9 the use of authentication certificates to exchange
authentication information, a generic authentication service based on these phases, and at least five classes of
authentication mechanism which provide the generic authentication service. These include mechanisms protecting
against disclosure of authentication information, and disclosure and replay on the same (and/or different) verifiers.
63 . Part 3 - Access control
This framework describes all aspects of access control (e.g. user-to-processes, user-to-data, process-to-process, process-
to-data) in Open Systems, the relationship to other security functions, such as authentication and audit, and the
management requirements for access control.
This framework:
a) defines the basic concepts for access control;
demonstrates the manner in which the basic concepts of access control can be specialized to support some
b)
commonly recognized access control services and mechanisms;
defines these services and the corresponding access control mechanisms;
C)
identifies functional requirements for protocols to support these access control services and mechanisms;
d)
identifies management requirements to support these access control services and mechanisms;
e)
mechanisms with other
addresses the interaction of access control services and security services and
f)
mechanisms.
This security framework describes a model of access control, a number of phases into which access control activities can
be categorized, a generic access control service based on these phases, and at least three classes of access control
mechanism which provide the generic access control service. These include access control lists, capabilities and labels.
64 . Part 4 - Non-repudiation
This framework refines and extends the concepts of the non-repudiation services described in CCITT Rec. X.800 I
IS0 7498-2, and provides a framework for the development and provision of these services.
This framework:
defines the basic concepts for non-repudiation;
a)
defines general non-repudiation services;
b)
identifies possible mechanisms to provide the non-repudiation services;
d
identifies general management requirements for non-repudiation services and mechanisms.
d)
65 . Part 5 - Confidentiality
The purpose of the confidentiality service i .s to protect 1 nformation from unau .thori zed disclosure. This framework
addresses the confidentiality of information i n retrieval, tra n sfer and management.
This framework:
defines the basic concepts of confidentiality;
a>
identifies possible classes of confidentiality mechanism;
W
defines facilities of each class of confidentiality mechanism;
C)
identifies management required to support the classes of confidentiality mechanisms; and
addresses the interaction of the confidentiality mechanism and the supporting services with
other security
e)
services a nd mechanisms.
Some of the procedures described in this security framework achieve confidentiality by the application of cryptographic
techniques. Use of this framework is not dependent on the use of particular cryptographic or other algorithms, although
certain classes of confidentiality mechanism may depend upon particular algorithm properties.
ITU-T Rec. X.810 (1995 E)
ISO/IEC 10181-l : 1996 (E)
66 . Part 6 - Integrity
The property that data has not been altered or destroyed in an unauthorized manner is called integrity. This framework
addresses the integrity of data in information retrieval, transfer, and management.
This framework:
a) defines the basic concept of integrity;
b) identifies possible classes of integrity mechanisms;
c) defines facilities for each class of integrity mechanisms;
d) identifies management required to support the classes of integrity mechanism;
addresses the interaction of the integrity mechanism and the supporting services with other security
e)
services and mechanisms.
Some of the procedures described in this security framework achieve integrity by the application of cryptographic
techniques. Use of this framework is not dependent on the use of particular cryptographic or other algorithms, although
certain classes of integrity mechanism may depend upon particular algorithm properties.
The integrity addressed by this framework is that defined by the constancy of a data value, not that of the constancy of
the information that the data is deemed to represent. Other forms of invariance are excluded.
67 0 Part 7 - Security audit and alarms
This framework:
a) defines the basic concepts of security audit and alarms;
b) provides a general model for security audit and alarms;
identifies the relationship of the security audit and alarms service with the other security services.
Cl
As with other security services, a security audit can only be provided within the context of a defined security policy. The
security policy will be defined by security authorities within their security domain. Any standard(s) specifying
mechanisms based upon this framework should be able to support various security policies.
68 . Key management
The key management framework, part 1 of ISO/IEC 11770, has a special relationship to the other security frameworks in
that it is concerned with functions that are not directly related to the security services identified in CCITT Rec. X.800 I
IS0 7498-2. Those functions are applicable in any information technology environment where encipherment or digital
signature is appropriate.
This framework:
identifies objectives of key management;
a>
b) describes general models on which key management mechanisms are based;
c) defines the basic concepts of key management common to all the parts of this multi-part standard;
d) defines key management services;
identifies the characteristics of key management mechanisms;
e)
f) specifies requirements for the management of keying material during its life cycle;
g) describes a framework for the management of keying material during its life cycle.
7 Common concepts
Many concepts are required in more than one part of the security frameworks. This standard defines these concepts for
use within the remaining parts of this Recommendation I International Standard.
6 IT&T Rec. X.810 (1995 E)
ISO/IEC 101814 : 1996 (E)
71 . Security information
Security (SI) is information needed to implement security services. Examples of security information
Information
include:
security policy rules;
-
information to realize specific security services, such as Authentication Information (AI) and Access
Control Information (ACI); and
-
security mechanisms, such as security labels, cryptographic checkvalues security
information relevant to
tokens.
certificates and security
The types of SI common to more than one of the security frameworks are discussed in clause 8.
72 . Security domain
A security domain is a set of elements under a given security policy administered by a single security authority for some
specific security-relevant activities. The activities of a security domain involve one or more elements from that security
domain and, possibly, elements of other security domains.
Examples of activities are:
accesses to elements;
- establishment or use of OS1 (N)-layer connections;
operations relating to a specific management function;
non-repudiation operations involving a notary.
An activity may be security-relevant even if it is currently not the subject of mechanisms that could enforce an arbitrary
policy regarding its use. In particular, activities that cannot be prevented from taking place among any group of elements
can be security-relevant and may become the subject of controlling mechanisms in the future.
Examples of the elements of a security domain in an Open Systems environment include logical or physical elements
such as real open systems, application processes, (N)-entities, (N)-protocol data units, relays, and human users of real
open systems. There are occasions when the human users must be distinguished from the other elements in a security
domain. In such cases, to distinguish the non-human elements, the term data objects will be used.
7.2.1 Security policy and security policy rules
A security policy expresses security requirements for a security domain in general terms. For example, a security policy
may identify requirements that apply to all members of a security domain when operating under specific conditions, or
that apply to all information in a security domain. The implementation of a security policy will result in security services
being identified that will satisfy the security policy, and security mechanisms will be chosen to implement the security
services. The decision as to which security mechanisms are chosen is influenced by the threats that are anticipated and
by the value of the resources to be protected.
Security policies are commonly stated as broad principles in a natural language. These principles reflect the security
requirements of a particular organization or the members of a security domain. Before these requirements can be
reflected in real open systems, the security policy must be refined so that a set of security policy rules can be derived
from them. The interpretation of these requirements as security policy rules is an engineering activity. A security policy
constrains the activities of elements subject to that security policy, either by requiring certain actions or by prohibiting
certain activities. A security policy may also give elements permission to take part in certain activities. This is a broader
interpretation of security policy than that contained in CCITT Rec. X.800 I IS0 7498-2, which is concerned only with
OSI. Aspects of security policy which are specific to a particular security service are discussed in the security framework
for that service.
Security policy rules for a security domain are of two types, those for activities within a security domain and those for
activities between security domains. Security policy rules of the latter type are referred to as secure interaction rules. A
security policy may also define which rules apply to relations with all security domains, and which rules apply to
relations with particular security domains.
The security policy rules for a security domain must be kept valid as the system changes or the activities and security
policy of the security domain are modified.
NOTE! - This framework is not concerned with the following aspects of security policy:
- the party who establishes or maintains a security policy itself;
- procedures for establishing or maintaining a security policy;
IT&T Rec. X.810 (1995 E)
ISO/IEC 10181-l : 1996 (E)
the contents of a security policy;
procedures for binding a security policy to a security domain.
7.2.2 Security domain authority
responsible for the implementation of a security policy for a
A security domain authority is a security authority that is
security domain.
A security domain authority:
-
may be a composite entity; such an entity must be identifiable;
-
may, depending on any security policy that the security domain authority may be subject to, &leg& the
responsibility for implementing the security policy to one or more entities;
-
has authority over the elements in the security domain.
NOTE - A security policy may be null if the security domain authority has decided not to impose any constraints.
Two security domain authorities are said to be linked if they are constrained to coordinate their security policies.
7.2.3 Inter-relationships among security domains
The notion of a security domain is deemed to be important for two reasons. Namely:
it can be used to describe how security is managed and administered; and
-
block in modeling security-relevant activities that involve elements under
it can be used as a building
distinct security authorities.
Security domains may be related in one or more ways. Some possible security domain relationships are discussed here.
Relationships among security domains must be reflected in the security policies of the security domains as agreed by
their security authorities. These relationships are stated in terms of elements and activities of the security domains and
are reflected in the secure interaction rules for each of the related security domains. Some particular security domain
relationships are described in the remainder of this subclause. Many other security domain relationships are possible.
other if they have no data objects
Two security domains are said to be isolated from each common
a)
no activities in common and, therefore, cannot interact.
Two security domains are said to be independent of each other if:
W
they have no data objects in common; and
-
ned only by their own security policies (and
the activities withi n each security domain are constrai
of security policy rules); and
corresponding sets
-
the security authorities of the security domains are not constrained to coordinate their security
policies.
Two or more independent security domains may choose to enter into an agreement to coordinate sharing
of information among them (see 7.2.4).
Security domain A is said to be a security subdomain of another security domain B if, and only if:
C>
-
the set of elements of A is a subset of, or is the same as, the set of elements of B;
-
the set of activities in A is a subset of, or is the same as, the set of activities in B;
-
jurisdiction for A is delegated from the security authority of B to the security authority of A; and
-
the security policy of A does not conflict with the security policy of B. A may introduce additional
security policy if required, and if permitted by the security policy of B.
NOTE 1 - A subset may be equal to the full set. A security subdomain may be formed on one extreme of
the full set of elements of the security superdomain for some classes of activity or on another extreme of all the
classes of activity for some subset from the set of elements of the security superdomain. Between these two
extremes many variations may exist.
security domain A is said
security superdomain of security domain B if and only if B is a
d)
security subdomain of A.
isolated, independent,
NOTE 2 - The Security Frameworks do not require the subdomain or superdomain
concepts to be supported by any particular protocol, specification or implementation.
8 ITU-T Rec. X.810 (1995 E)
ISO/IEC 10181-l : 1996 (E)
7.2.4 Establishment of secure interaction rules
To be able to exchange information among security domains, there must be an agreed set of security policy rules for this
exchange. These security policy rules are called secure interaction rules. They are part of each security domain’s security
policy rules. Secure interaction rules enable common security services and mechanisms to be selected, possibly through
negotiation, and security information items in each security domain to be related to one another, possibly through
mapping. Security management information needed to support secure interaction rules may be exchanged among
security domains. Depending on the relationships among security domains, the secure interaction rules may be
determined in different ways.
For secure interactions among independent security domains, the secure interaction rules must be agreed by the security
authorities for the security domains involved.
For secure interactions among security subdomains, the secure interaction rules can be established by the security
authority for the security superdomain. If allowed by the security superdomain’s security policy, the security
subdomains may establish their own secure interaction rules.
7.2.5 Inter-domain security information transfer
and this security information may need to be
Secure interaction rules may themselves constitute security information,
transferred between security domains. The following cases are considered:
-
representation of the security information in each of the
The semantics and the security domains is
means that translation is unnecessary.
identical. This
-
The semantics of the security information in each of the security domains is identical, but the
representations differ. This means that the method by which the security information is described is
different, and thus that syntax translation is necessary.
-
Both the semantics and the representation of the security information are different in each of the security
domains. This means that the secure interaction rules must specify how security information of one
domain is to be translated into security information of the other domain. Syntax translation may also be
necessary.
73 e Security policy considerations
...

NORME
ISO/CEI
INTERNATIONALE 10181-1
Première édition
1996-08-01
Technologies de l’information -
Interconnexion de systèmes
ouverts (OSI) - Cadres de sécurité pour les
systèmes ouverts: Aperçu
Information technology - Open Sys tems In terconnection - Security
frameworks for open systems: Overview
Numéro de référence
ISO/CEI 1 OI 81-1 :1996(F)
ISO/CEI 10181-i : 1996 (F)
Sommaire
Page
Domaine d’application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Références normatives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1 Recommandations I Normes internationales identiques
2.2 Paires de Recommandations I Normes internationales équivalentes por leur contenu technique . . . . . . .
Définitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .*.
3.1 Définitions du modèle de réference de base
Définitions de l’architecture de sécurité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .*.
3.2
Définitions additionnelles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3
Abréviations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5 Notation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .*.
6 Organisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
.- -
. Partie l-- Aperçu général . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .-.
-6 1
. Partie 2 - Authentification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
63 . Partie 3 - Contrôle d’accès . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
64 . Partie 4 - Non-répudiation
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
65 Partie 5 - Confidentialité
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6:6 Partie 6 - Intégrité
Partie 7 - Audit et alarmes de sécurité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
67 .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
68 . Gestion de clé
Concepts communs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Information de sécurité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.1
Domaines de sécurité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.2
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .*.
7.2.1 Politique de sécurité et règles de politique de sécurité
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
7.2.2 Autorité du domaine de sécurité
Corrélations entre domaines de sécurité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.2.3
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
7.2.4 Etablissement des règles d’interaction sécurisée
7.2.5 Transfert d’information de sécurité entre domaines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Considérations de politique de sécurité pour des services spécifiques de sécurité
7.3
7.4 Entités de confiance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .*.
7.5 Confiance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
7.6 Tierces parties de confiance
0 ISOKEI 1996
Droits de reproduction réservés. Sauf prescription différente, aucune partie de cette publication
ne peut être reproduite ni utilisée sous quelque forme que ce soit et par aucun procédé,
électronique ou mécanique, y compris la photocopie et les microfilms, sans l’accord écrit de
l’éditeur.
ISOKEI Copyright Office l Case postale 56 l CH-121 1 Genève 20 l Suisse
Version française tirée en 1997
Imprimé en Suisse
ii
ISO/CEIlOl81-1:1996(F)
@ ISO/CEI
Information générique de sécurité . 11
Etiquettes de sécurité .
8.1
Valeurs de contrôle cryptographique .
Certificats de sécurité .
8:3
Introduction aux certificats de sécurité . 12
8.3.1
........................................................... 13
8.3.2 Vérification et chaînage des certificats de sécurité
8.3.3 Révocation des certificats de sécurité . 13
Réutilisation des certificats de sécurité . 13
8.3.4
8.3.5 Structure des certificats de sécurité .
8.4 Jetons de sécurité .
........................................................................................................... 14
9 Fonctionnalités génériques de sécurité
......................................................................................................... 14
9.1 Fonctionnalités liées à la gestion
................................................................................................... 15
9.1.1 Installer l’information SI
Démonter l’information SI . 15
9.1.2
Changer l’information SI . 15
9.1.3
Valider l’information SI . 15
9.1.4
9.1.5 Invalider l’information SI .
9.1.6 Mise hors d’usage/remise en service du service de sécurité . 15
Insérer . 15
9.1.7
9.1.8 Enlever .
9.1.9 Distribuer l’information SI . 15
9.1.10 Lister l’information SI . 15
9.2 Fonctionnalités liées aux aspects opérationnels . 15
9.2.1 Identifier les autorités de sécurité de confiance . 15
Identifier des règles d’interaction sécurisée . 15
9.2.2
Acquérir l’information SI . 15
9.2.3
9.2.4 Générer l’information SI .
9.2.5 Vérifier l’information SI . 16
Interactions entre mécanismes de sécurité . 16
11 Déni de service et disponibilité . 17
12 Autres besoins .
Annexe A - Exemples de mécanismes de protection pour les certificats de sécurité . 18
A. 1 Protection utilisant un service de sécurité des communications OS1 . 18
........................................................... 18
A.2 Protection utilisant un paramètre dans le certificat de sécurité
A.2.1 La méthode d’authentification .
A.2.2 La méthode de la clé secrète . 19
La méthode de la clé publique . 19
A.2.3
La méthode de la fonction à sens unique . 19
A.2.4
A.3 Protection des paramètres interne et externe lors de leur transfert . 19
Transfert des paramètres internes vers l’autorité de sécurité émettrice . 19
A.3.1
A.3.2 Transfert de paramètres externes entre entites . 19
....................... 20
A.4 Utilisation de certificats de sécurité par une seule entité ou par des groupes d’entités
A.5 Liaison d’un certificat de sécurité avec les accès . 20
Annexe B - Bibliographie .
. . .
ISOKEI 101814 : 1996 (F) @ ISOKEI
Avant-propos
L’ISO (Organisation internationale de normalisation) et la CE1 (Commission
électrotechnique internationale) forment ensemble un système consacré à la
normalisation internationale considérée comme un tout. Les organismes nationaux
membres de I’ISO ou de la CE1 participent au développement des Normes
internationales par l’intermédiaire des comités techniques créés par l’organisation
concernée afin de s’occuper des différents domaines particuliers de l’activité
technique. Les comités techniques de FIS0 et de la CE1 collaborent dans des
domaines d’intérêt commun. D’autres organisations internationales, gouveme-
mentales et non gouvernementales, en liaison avec 1’ISO et la CE1 participent
également aux travaux.
Dans le domaine des technologies de l’information, I’ISO et la CE1 ont créé un
comité technique mixte, l’ISO/CEI JTC 1. Les projets de Normes internationales
adoptés par le comité technique mixte sont soumis aux organismes nationaux pour
approbation, avant leur acceptation comme Normes internationales. Les Normes
internationales sont approuvées conformément aux procédures qui requièrent
l’approbation de 75 % au moins des organismes nationaux votants.
La Norme internationale ISOKEI 10 18 l-l a été élaborée par le comit6 technique
mixte ISOKEI JTC 1, Technologies de l’information, sous-comité SC 21,
Interconnexion des systèmes ouverts, gestion des données et traitement distribué
ouvert, en collaboration avec I’UIT-T. Le texte identique est publié en tant que
Recommandation UIT-T X.8 10.
ISO/CEI 10 18 1 comprend les parties suivantes, présentées sous le titre général
Technologies de l’information - Interconnexion de systèmes ouverts (OSI) -
Cadres de sécurité pour les systèmes ouverts :
Partie 1: Aperçu
- Partie 2: Cadre d’authenttjkation
- Partie 3: Cadre de contrôle d’accès
Partie 4: Cadre de non-répudiation
- Partie 5: Cadre de confidentialité
- Partie 6: Cadre d’intégrité
Partie 7: Cadre pour l’audit de sécurité et les alarmes
Les annexes A et B de la présente partie de l’ISO/CEI 10 18 1 sont données
uniquement à titre d’information.

@ ISOKEI
ISOKEI 101814 : 1996 (F)
Introduction
Plusieurs applications ont des besoins de S&urit6 pour protéger les communications d’information contre les menaces.
Quelques menaces connues ainsi que les services et mécanismes de sécurité qui peuvent être utilisés pour s’en protéger
sont décrites dans la Rec. X.800 du CCITT I ISO 7498-2.
La présente Recommandation I Norme internationale définit le cadre dans lequel les services de sécurité pour les
systèmes ouverts sont spécifiés.
v
Page blanche
ISOKEI 10181~1:1996 (F)
NORME INTERNATIONALE
RECOMMANDATION UIT-T
TECHNOLOGIES DE L’INFORMATION- INTERCONNEXION DE
SYSTÈMES OUVERTS (OSI) - CADRES DE SÉCURITÉ POUR LES SYSTÈMES
OUVERTS: APERÇU
1 Domaine d’application
Les cadres de sécurité concernent l’application des services de sécurité dans l’environnement des systèmes ouverts, où le
terme systèmes ouverts est utilise pour inclure des domaines comme les bases de données, les applications distribuées, le
traitement ODP et l’interconnexion OSI. Les cadres de sécurité sont impliqués dans la définition des moyens d’offrir la
protection pour les systèmes et les objets au sein des systèmes, ainsi que les interactions entre systèmes. Ils ne couvrent
pas la méthodologie de construction des systèmes ou des mécanismes.
Les cadres de sécurité traitent à la fois des éléments de données et des séquences d’opérations (mais pas des éléments de
protocole) utilisés pour obtenir des services spécifiques de sécurité. Ces services de securité peuvent s’appliquer aux
entités communicantes des systèmes aussi bien qu’aux données échangées entre systemes, et aux donnees gérees par les
systèmes.
Les cadres de sécurité fournissent la base pour une normalisation ulterieure, fournissant une terminologie cohérente et
des définitions d’interfaces de service générique abstrait pour des besoins de sécurité spécifiques. Ils classifient
également les mécanismes qui peuvent être utilisés pour répondre à ces besoins.
Un service de sécurité dépend fréquemment d’autres services de sécurité, rendant difficile l’isolation d’une partie de la
sécurité des autres parties. Les cadres de sécurité font intervenir des services de sécurité particuliers, décrivent la gamme
des mécanismes qui peuvent être utilisés pour fournir les services de sécurité et identifient les interdépendances entre les
services et les mécanismes. La description de ces mécanismes peut mettre en jeu la confiance envers un service de
sécurité différent, et c’est de cette façon que les cadres de sécurite décrivent la confiance d’un service de sécurité envers
un autre.
Cette partie des cadres de sécurité:
-
décrit l’organisation des cadres de sécurité;
-
décrit les concepts de sécurité qui sont requis dans plus d’une partie des cadres de sécurité;
décrit la corrélation entre les services et mécanismes identifiés dans les autres parties des cadres.
Références normatives
Les Recommandations et Normes internationales suivantes contiennent des dispositions qui, par suite de la reférence qui
y est faite, constituent des dispositions valables pour la présente Recommandation I Norme internationale. Au moment de
la publication, les éditions indiquées étaient en vigueur. Toutes Recommandations et Normes sont sujettes à révision, et
les parties prenantes aux accords fondés sur la présente Recommandation I Norme internationale sont invitées à
rechercher la possibilité d’appliquer les éditions les plus récentes des Recommandations et Normes indiquées ci-après.
Les membres de la CE1 et de I’ISO possèdent le registre des Normes internationales en vigueur. Le Bureau de la
normalisation des télécommunications de I’UIT tient à jour une liste des Recommandations de I’UIT en vigueur.
21 . Recommandations I Normes internationales identiques
-
Recommandation UIT-T X.200 (1994) I ISOKEI 7498-l : 1994, Technologies de Z’infomtion -
Interconnexion des systèmes ouverts - Modèle de référence de base: Le modèle de référence de base.
Rec. UIT-T X.810 (1995 F)
ISOKEI 101814 : 1996 (F)
22 . Paires de Recommandations I Normes internationales équivalentes par leur contenu technique
-
Recommandation X.800 du CCITT (199 l), Architecture de sécurité pour l’interconnexion en systèmes
ouverts d’applications du CCITT.
ISO 7498-2: 1989, Systèmes de traitement de 1 ‘information - Interconnexion des systèmes ouverts -
Modèle de référence de base - Partie 2: Architecture de sécurité.
Définitions
Les définitions suivantes sont utilisées dans l’aperçu général ou sont communes a deux parties consécutives ou plus des
cadres de sécurité.
Pour les besoins de la présente Recommandation I Norme internationale, les définitions suivantes s’appliquent.
31 l Définitions du modèle de référence de base
La présente Recommandation I Norme internationale utilise les termes suivants définis dans la Rec. UIT-T X.200 I
ISOKEI 7498- 1:
-
couche (N);
- entite (N);
-
unité de données de protocole (N);
-
processus d’application;
- système réel ouvert;
-
système réel.
32 0 Définitions de l’architecture de sécurité
La présente Recommandation I Norme internationale utilise les termes suivants définis dans la Rec. X.800 du CCITT I
ISO 7498-2:
-
contrôle d’accès;
-
disponibilité;
-
cryptogramme;
-
valeur de contrôle cryptographique;
-
déchiffrement;
-
déni de service;
-
signature numérique;
-
chiffrement;
-
menace de l’intérieur;
-
clé;
-
gestion de clé;
-
texte en clair;
-
menace de l’extérieur;
-
audit de sécurité;
-
étiquette de sécurité;
-
poli tique de sécurité;
-
sensibilité;
-
menace.
33 0 Définitions additionnelles
Pour les besoins de la présente Recommandation I Norme internationale, les définitions suivantes s’appliquent.
2 Rec. UIT-T X.810 (1995 F)
ISOKEI 101814 : 1996 (F)
3.3.1 algorithme asymétrique de cryptographie: algorithme pour réaliser le chiffrement ou le déchiffrement
correspondant dans lequel les clés utilisées pour le chiffrement et le déchiffrement sont différentes.
NOTE - Avec certains algorithmes asymétriques de cryptographie, il faut utiliser plus d’une cl6 privée pour dechiffrer un
cryptogramme ou pour générer une signature numérique.
autorité de certification: entité habilitée à laquelle il est fait confiance (dans le contexte d’une politique de
3.3.2
sécurité) pour créer des certificats de sécurité contenant une ou plusieurs classes de données relatives à la sécurité.
entité de confiance conditionnelle: entité à laquelle il est fait confiance dans le contexte d’une politique de
3.3.3
sécurité, mais qui ne peut pas violer la politique de sécurité sans être détectée.
3.3.4 chaînage cryptographique: mode d’utilisation d’un algorithme cryptographique dans lequel la transformation
effectuée par l’algorithme dépend des valeurs des entrées ou sorties précédentes.
caractéristique d’un élément de données, telle qu’une valeur de contrôle
3.3.5 empreinte numérique:
cryptographique ou le résultat de la réalisation d’une fonction de hachage unidirectionnelle sur les données, qui est
suffisamment spécifique à l’élément de données pour qu’il ne soit pas possible de trouver, de façon informatique, un
autre élément de données ayant les mêmes caractéristiques.
3.3.6 identificateur caractéristique: données qui identifient de façon univoque une entité.
fonction de hachage: fonction (mathématique) qui fait correspondre les valeurs d’un grand ensemble
3.3.7
(potentiellement très grand) de valeurs à une gamme plus réduite de valeurs.
fonction unidirectionnelle: fonction (mathématique) qu’il est facile de calculer mais pour laquelle, lorsque le
3.3.8
résultat est connu, il n’est pas possible de trouver, de façon informatique, n’importe laquelle des valeurs qui auraient pu
être fournies pour obtenir celui-ci.
fonction de hachage unidirectionnelle: fonction (mathématique) qui est à la fois une fonction
3.3.9
unidirectionnelle et une fonction de hachage.
clé privée: clé qui est utilisée avec un algorithme asymétrique de cryptographie et dont la possession est
3.3.10
(habituellement a une seule entité).
limitée
3.3.11 clé publique: clé qui est utilisée avec un algorithme asymétrique de cryptographie et qui peut être rendue
publique.
sécurité émis par une autorité de sécurité pour indiquer qu’un certificat
3.3.12 certificat de révocation: certificat de
de sécurité particulier a été révoqué.
3.3.13 certificat de révocation de liste: certificat de sécurité qui identifie une liste de certificats de sécurité qui ont
été révoqués.
3.3.14 scellé: valeur de contrôle cryptographique qui met en œuvre l’intégrité mais qui ne protège pas d’une
falsification du récepteur (c’est-à-dire qu’il n’offre pas la non-répudiation). Lorsqu’un scellé est associé à un élément de
données, cet élément de données est dit scellé.
NOTE - Bien qu’un scellé n ‘offre pas lui- #même la non-répudiation, certains mkanismes de non-répudiation font usage du
service d’intégrité offert par les scellés, par exemple, pour protéger les communications avec des tierces parties de confiance.
3.3.15 clé secrète: clé qui est utilisée avec un algorithme symétrique de cryptographie. La possession de cette clé est
(habituellement à deux entités).
limitée
administrateur de sécurité: personne qui est responsable de la définition ou de l’application d’une ou de
3.3.16
plusieurs parties de la poli .tique de sécurité.
3.3.17 autorité de sécurité: entité qui est responsable de la définition, de la mise en œuvre ou de l’application de la
politique de sécurité.
3.3.18 certificat de sécurité: ensemble de données relatives a la sécurité émis par une autorité de sécurité ou une
tierce partie de confiance ainsi que les informations de sécurité qui sont utilisées pour fournir des services d’intégrité et
d’authentification de l’origine des données.
NOTE - Tous les certificats sont réputés être des certificats de sécurité (voir les definitions applicables dans 1’ISO 7498-2).
Le terme certificat de sécurité est adopté afin d’éviter des conflits de terminologie avec la Rec. UIT-T X.509 I ISOKEI 9594-8
(c’est-à-dire la norme d’authentification de l’annuaire).
3.3.19 chaîne de certificat de sécurité: séquence ordonnée de certificats de sécurité, dans laquelle le premier
certificat de sécurité contient des informations relatives a la sécurité et les certificats de sécurité suivants contiennent des
informations de sécurité qui peuvent être utilisées pour la vérification des certificats de sécurité précédents.
Rec. UIT-T X.810 (1995 F)
ISOKEI 10181-l : 1996 (F)
3.3.20 domaine de sécurité: ensemble d’éléments, politique de sécurité, autorité de sécurité et ensemble d’activités
liées a la sécurité dans lesquels l’ensemble des éléments est sujet à la politique de sécurité, pour les activités spécifiées et
la politique de sécurité est administrée par l’autorité de sécurité, pour le domaine de sécurité.
3.3.21 autorité du domaine de sécurité: autorité de sécurité qui est responsable de la mise en œuvre d’une politique
de sécurité pour un domaine de sécurité.
3.3.22 information de sécurité: information nécessaire pour mettre en œuvre des services de sécurité.
rétablissement de la sécurité: actions qui sont menées et procédures qui sont utilisées lorsqu’une violation de
3.3.23
sécurité est soit détectée soit soupçonnée d’avoir eu lieu.
3.3.24 règles d’interaction sécurisée: règles de politique de sécurité qui régissent des interactions entre domaines de
sécurité.
de sécurité: représentation politique de sécurité pour un domaine de sécurité au sein
3.3.25 règles de politique
d’un système réel.
3.3.26 jeton de sécurité: ensemble de données protégé par un ou plusieurs services de sécurité, ainsi que les
informations de sécurité utilisées pour la fourniture de ces services de sécurité, qui est transféré entre les entités
communicantes.
algorithme symétrique de cryptographie: algorithme pour réaliser le chiffrement ou algorithme pour réaliser
3.3.27
le déchi .ffrement correspondant dans lequel la même clé est requise à la fois pour le chiffrement et le déchiffrement.
3.3.28 confiance: on dit que l’entité X fait confiance à l’entité Y pour un ensemble d’activités si et seulement si
l’entité X suppose que l’entité Y se comportera d’une certaine façon par rapport aux activités.
3.3.29 entité de confiance: entité qui peut violer une politique de sécurité, soit en réalisant des actions qu’elle n’est
pas censée accompl ir, soit en ne réussissant pas à réaliser des action u’elle est censée accomplir.
s 9
tierce partie de confiance: autori .té de sécurité ou son agent auquel il est fait confiance au certaines
3.3.30
activités liées à la sécurité (dans le contexte d’une politique de sécurité).
3.3.31 entité de confiance inconditionnelle: entite de confiance qui peut violer une politique de sécurité sans être
détectée.
4 Abréviations
Pour les besoins de la présente Recommandation I Norme internationale, les abréviations suivantes sont utilisées.
ACI Information de contrôle d’accés (access control information)
os1 Interconnexion des systèmes ouverts (open systems interconnection)
ODP Traitement réparti ouvert (open distributed processing)
SI Information de sécurité (security information)
TTP Tierce partie de confiance (trusted third party)
5 Notation
La notation de couche utilisée est la même que celle qui est définie dans la Rec. UIT-T X.200 I ISOKEI 7498- 1.
Sauf indication contraire, le terme service sert à désigner un service de sécurité.
Sauf indication contraire, le terme certificat sert à désigner un certificat de sécurité.
6 Organisation
Le cadre de sécurité fait partie d’une Norme internationale multipartie (ISOKEI 10181) et d’une série de
Recommandations de I’UIT. Les cadres de sécurité sont décrits ci-après. Des cadres de sécurité additionnels pourront
être identifiés à l’avenir. Le cadre de gestion des clés ne fait pas partie de I’ISOKEI 10181, mais il a un domaine
d’application similaire et sa description est incluse dans un souci d’exhaustivité.
4 Rec. UIT-T X.810 (1995 F)
ISOKEI 10181-l : 1996 (F)
Partie 1 - Aperçu général
61 l
Voir l’article 1.
62 0 Partie 2 - Authentification
Ce cadre décrit tous les aspects d’authentification tels qu’ils s’appliquent aux systèmes ouverts, la relation de
l’authentification avec d’autres fonctions de sécurité comme le contrôle d’accès et les besoins de gestion pour
l’authentification.
Ce cadre:
a) définit les concepts élémentaires de l’authentification;
b) identifie les classes possibles pour les mécanismes d’authentification;
définit les services pour ces classes de mécanismes d’authentification;
C>
identifie les besoins fonctionnels pour les protocoles afin de mettre en œuvre ces classes de mécanismes
d)
d’authentification;
identifie des besoins généraux de gestion pour l’authentification.
e>
Le cadre d’authentification est situé au sommet de la hiérarchie des normes d’authentification qui fournissent les services,
la nomenclature et la classification des méthodes d’authentification. Immédiatement en dessous de celui-ci, des normes
comme I’ISOKEI 9798 (mécanismes d’authentification d’entité) fournissent plus en détail un ensemble particulier de ces
méthodes. Finalement, au bas de la hiérarchie, des normes comme la Rec. UIT-T X.509 I ISOKEI 9594-8 (le cadre
d’authentification de l’annuaire) utilisent ces concepts et ces méthodes dans le contexte d’une application ou d’un besoin
spécifique.
Le cadre d’authentification décrit un modèle d’authentification, un ensemble d’étapes dans lesquelles les activités
d’authentification peuvent être rangées par catégories, l’utilisation d’une tierce partie de confiance, l’utilisation de
certificats d’authentification pour échanger des informations d’authentification, un service d’authentification générique
basé sur ces étapes, et au moins cinq classes de mécanismes d’authentification qui fournissent le service générique
d’authentification. Cela comprend des mécanismes protégeant contre la divulgation d’informations d’authentification, et
contre la divulgation et la répétition sur les mêmes (et/ou différents) vérificateurs.
63 . Partie 3 - Contrôle d’accès
Ce cadre définit tous les aspects du contrôle d’accès (c’est-à-dire utilisateur à processus, utilisateur à données, processus à
processus, processus à données) dans les systèmes ouverts, les relations avec d’autres fonctions de sécurité, telles que
l’authentification et l’audit, et les besoins de gestion pour le contrôle d’accès.
Ce cadre:
a) définit les concepts de base pour le contrôle d’accès;
démon tre la façon dont les l concepts de base du contrôle d’accès peuvent être spécialisés pour en
b)
œuvre quelques services et mécanismes de contrôle d’accès communément reconnus;
définit ces services et les mécanismes de contrôle d’accès correspondants;
Cl
d) identifie les besoins fonctionnels des protocoles pour mettre en œuvre ces services et mécanismes de
contrôle d’accès;
identifie les besoins de gestion pour mettre en œuvre ces services et mécanismes de contrôle d’accès;
e)
f) traite de l’interaction des services et mécanismes de contrôle d’accès avec d’autres services et mécanismes
de sécurité.
Ce cadre de sécurité décrit un modèle de contrôle d’accès, un certain nombre d’étapes dans lesquelles les activités de
contrôle d’accès peuvent être rangées par catégories, un service générique de contrôle d’accès basé sur ces étapes, et au
moins trois classes de mécanismes de contrôle d’accès qui fournissent le service générique de contrôle d’accès. Cela
comprend des listes de contrôle d’accès, des capacités et des étiquettes.
64 l Partie 4 - Non-répudiation
Ce cadre détaille et étend les concepts des services de non-répudiation décrits dans la Rec. X.800 du CCITT I
ISO 7498-2 et fournit un cadre pour le développement et la fourniture de ces services.
Rec. UIT-T X.810 (1995 F)
ISOKEI 10181-l : 1996 (F)
Ce cadre:
définit les concepts élémentaires de non-répudiation;
a>
b) définit les services généraux de non-répudiation;
identifie les mécanismes possibles pour fournir des services de non-répudiation;
Cl
d) identifie des besoins généraux de gestion pour des services et mécanismes de non-répudiation.
65 . Partie 5 - Confidentialité
confidentialité vise à protéger l’information contre une divulgati .on non autorisée. Ce
Le service de cadre traite de la
confidentialité des informations pour la recherche, le transfert et la gestion.
Ce cadre:
a) définit les concepts élémentaires de confidentialité;
b) identifie les classes possibles de mécanismes de confidentialité;
c) définit les fonctionnalités de chaque classe de mécanismes de confidentialité;
d) identifie la gestion nécessaire pour mettre en œuvre les classes de mécanismes de confidentialité;
traite de l’interaction du mécanisme de confidentialité et des services le mettant en œuvre avec les autres
e)
services et mécanismes de sécurité.
Quelques-unes des procédures décrites dans ce cadre de sécurité assurent la confidentialité par l’application de
techniques cryptographiques. L’utilisation de ce cadre ne dépend pas de l’utilisation d’une technique cryptographique
particuliere ou d’autres algorithmes, bien que certaines classes de mécanismes de confidentialité puissent dépendre de
propriétés algorithmiques particulières.
66 . Partie 6 - Intégrité
que des données n’ont pas été modifiées ou détruites façon non
On appelle intégrité la propriété assurant de autorisée. Ce
cadre couvre l’intégrite des données pour la recherche, le transfert et la gestion des données.
Ce cadre:
a) définit le concept élémentaire d’intégrité;
identifie des classes possibles de mécanismes d’intégrite;
b)
définit des fonctionnalités pour chaque classe des mécanismes d’intégrité;
C)
identifie la gestion nécessaire pour mettre en œuvre les classes des mécanismes d’intégrité;
traite de l’interaction des services supports et des mécanismes d’intégrité avec d’autres services et
e)
mécanismes de sécurité.
Quelques-unes des procédures décrites dans ce cadre de sécurité permettent l’intégrité par l’application de techniques
cryptographiques. L’utilisation de ce cadre ne dépend pas de l’utilisation d’une technique cryptographique particulière ou
d’autres algorithmes, bien que certaines classes de mécanismes d’intégrité puissent dépendre de propriétés algorithmiques
particulières.
L’intégrité dont il est question dans ce cadre est celle qui est définie par l’invariabilité d’une valeur de données et non pas
celle de l’invariabilité de l’information que les données sont supposées représenter. Les autres formes d’invariabilité sont
exclues.
67 . Partie 7 - Audit et alarmes de sécurité
Ce cadre:
a) définit les concepts élémentaires d’audit et d’alarmes de sécurité;
b) fournit un modèle général pour l’audit et les alarmes de sécurité;
identifie la relation du service d’audit et d’alarmes de sécurité avec les autres services de sécurité.
C>
Comme pour les autres services de sécurité, un audit de sécurité peut être offert uniquement dans le contexte d’une
politique de sécurité. La politique de sécurité sera définie par les autorités de sécurité au sein de leur domaine de
sécurité. Toute(s) norme(s) spécifiant des mécanismes basés sur ce cadre devrait (devraient) être capable(s) de mettre en
œuvre différentes politiques de sécurité.
6 Rec. UIT-T X.810 (1995 F)
ISOKEI 10181-l : 1996 (F)
l Gestion de clé
Le cadre de gestion de clé, Partie 1 de I’ISOKEI 11770, a une relation spéciale avec les autres cadres de sécurité car il
couvre les fonctions qui ne sont pas directement liées aux autres services de sécurit6 identifiés dans la Rec. X.800 du
CCITT I ISO 7498-2. Ces fonctions sont applicables dans tout environnement de technologie de l’information où le
chiffrement ou la signature numérique est approprie(e).
Ce cadre:
identifie les objectifs de la gestion de clé;
a)
décrit les modèles généraux sur lesquels les mécanismes de gestion de cl6 sont basés;
c) définit les concepts élémentaires de la gestion de clé communs a toutes les parties de cette norme
mul tipartie;
définit les services de gestion de clé;
dl
identifie les caractéristiques des mécanismes de gestion de clé;
e>
spécifie les besoins pour la gestion des éléments relatifs aux clés durant leur cycle de vie;
décrit le cadre pour la gestion des éléments relatifs aux clés durant leur cycle de vie.
7 Concepts communs
De nombreux concepts sont nécessaires dans plus d’une partie des cadres de sécurité. Cette norme définit ces concepts à
utiliser dans les autres parties de cette Recommandation I Norme internationale.
71 . Information de sécurité
L’information de sécurité (SI) est l’information requise pour mettre en œuvre les services de sécurité. A titre d’exemples
d’information de sécurité, on peut citer:
-
les règles de politique de sécurité;
-
les informations pour réaliser des services spécifiques de sécurité, telles que l’information
d’authentification (AI) et l’information de contrôle d’accès (ACI);
-
aux mécanismes de sécurité, telles que les étiquettes de sécurité, les valeurs de
les informations relatives
contrôle cryptographique, les certificats de sécurité et les jetons de sécurité.
Les types de SI communs à plus d’un des cadres de sécurité sont traites dans l’article 8.
72 . Domaines de sécurité
Un domaine de sécurité est un ensemble d’éléments subordonnes a une politique de sécurité donnée administrée, pour
certaines activités spécifiques liées à la sécurité, par une seule autorité de sécurité. Les activités d’un domaine de sécurité
mettent en jeu un ou plusieurs éléments de ce domaine de sécurité et, éventuellement, des éléments d’autres domaines de
sécurité.
Exemples d’activités:
-
accès au x él éments;
-
établissement ou utilisation des connexions de couche (N);
opérations relatives à une fonction spécifique de gestion;
opérations de non-répudiation impliquant un notaire.
Une activité peut être relative à la sécurité même si elle n’est pas sujette a des mécanismes qui pourraient imposer une
politique arbitraire pour son utilisation. En particulier, des activités dont on ne peut empêcher le déroulement entre
n’importe quel groupe d’éléments peuvent être relatives à la sécurité et devenir, à l’avenir, le sujet de mécanismes de
contrôle.
Des exemples d’éléments d’un domaine de sécurité dans un environnement de systèmes ouverts comprennent des
éléments logiques ou physiques comme des systèmes ouverts réels, des processus d’application, des entités (N), des
unités de données de protocole (N), des relais et des utilisateurs humains de systèmes ouverts réels. Il y a des cas où les
utilisateurs humains doivent être distingués des autres éléments dans le domaine de sécurité. En pareils cas, le terme
objets de données sera utilisé pour distinguer les éléments non humains.
Rec. UIT-T X.810 (1995 F) 7
ISO/CEI 10181-l : 1996 (F)
7.2.1 Politique de sécurité et règles de politique de sécurité
Une politique de sécurité exprime, en des termes généraux, des besoins de sécurité pour un domaine de sécurité. Par
exemple, une politique de sécurité peut identifier des besoins qui s’appliquent à tous les membres du domaine de sécurité
fonctionnant sous des conditions spécifiques, ou qui s’appliquent à toutes les informations dans un domaine de sécurité.
La mise en œuvre d’une politique de sécurité se concrétisera par l’identification de services de sécurite qui satisferont la
politique de sécurité, et des mécanismes de sécurité seront choisis pour mettre en œuvre les services de sécurité. La
décision du choix des mécanismes de sécurité est influencée par les menaces prévues et par la valeur des ressources à
protéger.
Les politiques de sécurité sont communément formulées sous forme de principes généraux exprimés en langage naturel.
Ces principes reflètent les besoins de sécurité d’une organisation particulière ou les membres d’un domaine de sécurité.
Avant que ces besoins puissent être reflétés dans des systèmes ouverts réels, la politique de sécurité doit être détaillée de
telle façon qu’un ensemble de règles de politique de sécurité puisse en être dérivé. L’interprétation de ces besoins en tant
que règles de sécurité est une activité d’ingénierie. Une politique de sécurité limite les activités des éléments sujets a
cette politique de sécurité, soit en demandant certaines actions soit en interdisant certaines activités. Une politique de
sécurité peut également donner à des éléments la permission de prendre part à certaines activités. Il s’agit
d’une interprétation plus large de la politique de sécurité que celle qui est contenue dans la Rec. X.800 du CCITT I
ISO 7498-2, uniquement concernée par l’interconnexion OSI. Les aspects de politique de sécurité spécifiques à un
service de sécurité sont présentés dans le cadre de sécurité de ce service.
Les règles de la politique de sécurité pour un domaine de sécurité sont de deux types, celles concernant les activités au
sein d’un domaine de sécurité et celles concernant les activités entre domaines de sécurité. Les règles de politique de
sécurité du dernier type sont traitées comme des règles d’interaction sécurisée. Une politique de sécurité peut également
définir les règles qui s’appliquent aux relations avec tous les domaines de sécurité et les règles qui s’appliquent aux
relations avec des domaines de sécurité particuliers.
Les règles de politique de sécurité pour un domaine de sécurité doivent être maintenues en vigueur lorsque le système
change ou lorsque les activités et la politique de sécurité du domaine de sécurité sont modifiées.
NOTE - Ce cadre ne concerne pas les aspects suivants de la politique de
...

NORME
ISO/CEI
INTERNATIONALE 10181-1
Première édition
1996-08-01
Technologies de l’information -
Interconnexion de systèmes
ouverts (OSI) - Cadres de sécurité pour les
systèmes ouverts: Aperçu
Information technology - Open Sys tems In terconnection - Security
frameworks for open systems: Overview
Numéro de référence
ISO/CEI 1 OI 81-1 :1996(F)
ISO/CEI 10181-i : 1996 (F)
Sommaire
Page
Domaine d’application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Références normatives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1 Recommandations I Normes internationales identiques
2.2 Paires de Recommandations I Normes internationales équivalentes por leur contenu technique . . . . . . .
Définitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .*.
3.1 Définitions du modèle de réference de base
Définitions de l’architecture de sécurité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .*.
3.2
Définitions additionnelles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3
Abréviations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5 Notation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .*.
6 Organisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
.- -
. Partie l-- Aperçu général . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .-.
-6 1
. Partie 2 - Authentification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
63 . Partie 3 - Contrôle d’accès . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
64 . Partie 4 - Non-répudiation
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
65 Partie 5 - Confidentialité
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6:6 Partie 6 - Intégrité
Partie 7 - Audit et alarmes de sécurité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
67 .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
68 . Gestion de clé
Concepts communs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Information de sécurité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.1
Domaines de sécurité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.2
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .*.
7.2.1 Politique de sécurité et règles de politique de sécurité
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
7.2.2 Autorité du domaine de sécurité
Corrélations entre domaines de sécurité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.2.3
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
7.2.4 Etablissement des règles d’interaction sécurisée
7.2.5 Transfert d’information de sécurité entre domaines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Considérations de politique de sécurité pour des services spécifiques de sécurité
7.3
7.4 Entités de confiance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .*.
7.5 Confiance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
7.6 Tierces parties de confiance
0 ISOKEI 1996
Droits de reproduction réservés. Sauf prescription différente, aucune partie de cette publication
ne peut être reproduite ni utilisée sous quelque forme que ce soit et par aucun procédé,
électronique ou mécanique, y compris la photocopie et les microfilms, sans l’accord écrit de
l’éditeur.
ISOKEI Copyright Office l Case postale 56 l CH-121 1 Genève 20 l Suisse
Version française tirée en 1997
Imprimé en Suisse
ii
ISO/CEIlOl81-1:1996(F)
@ ISO/CEI
Information générique de sécurité . 11
Etiquettes de sécurité .
8.1
Valeurs de contrôle cryptographique .
Certificats de sécurité .
8:3
Introduction aux certificats de sécurité . 12
8.3.1
........................................................... 13
8.3.2 Vérification et chaînage des certificats de sécurité
8.3.3 Révocation des certificats de sécurité . 13
Réutilisation des certificats de sécurité . 13
8.3.4
8.3.5 Structure des certificats de sécurité .
8.4 Jetons de sécurité .
........................................................................................................... 14
9 Fonctionnalités génériques de sécurité
......................................................................................................... 14
9.1 Fonctionnalités liées à la gestion
................................................................................................... 15
9.1.1 Installer l’information SI
Démonter l’information SI . 15
9.1.2
Changer l’information SI . 15
9.1.3
Valider l’information SI . 15
9.1.4
9.1.5 Invalider l’information SI .
9.1.6 Mise hors d’usage/remise en service du service de sécurité . 15
Insérer . 15
9.1.7
9.1.8 Enlever .
9.1.9 Distribuer l’information SI . 15
9.1.10 Lister l’information SI . 15
9.2 Fonctionnalités liées aux aspects opérationnels . 15
9.2.1 Identifier les autorités de sécurité de confiance . 15
Identifier des règles d’interaction sécurisée . 15
9.2.2
Acquérir l’information SI . 15
9.2.3
9.2.4 Générer l’information SI .
9.2.5 Vérifier l’information SI . 16
Interactions entre mécanismes de sécurité . 16
11 Déni de service et disponibilité . 17
12 Autres besoins .
Annexe A - Exemples de mécanismes de protection pour les certificats de sécurité . 18
A. 1 Protection utilisant un service de sécurité des communications OS1 . 18
........................................................... 18
A.2 Protection utilisant un paramètre dans le certificat de sécurité
A.2.1 La méthode d’authentification .
A.2.2 La méthode de la clé secrète . 19
La méthode de la clé publique . 19
A.2.3
La méthode de la fonction à sens unique . 19
A.2.4
A.3 Protection des paramètres interne et externe lors de leur transfert . 19
Transfert des paramètres internes vers l’autorité de sécurité émettrice . 19
A.3.1
A.3.2 Transfert de paramètres externes entre entites . 19
....................... 20
A.4 Utilisation de certificats de sécurité par une seule entité ou par des groupes d’entités
A.5 Liaison d’un certificat de sécurité avec les accès . 20
Annexe B - Bibliographie .
. . .
ISOKEI 101814 : 1996 (F) @ ISOKEI
Avant-propos
L’ISO (Organisation internationale de normalisation) et la CE1 (Commission
électrotechnique internationale) forment ensemble un système consacré à la
normalisation internationale considérée comme un tout. Les organismes nationaux
membres de I’ISO ou de la CE1 participent au développement des Normes
internationales par l’intermédiaire des comités techniques créés par l’organisation
concernée afin de s’occuper des différents domaines particuliers de l’activité
technique. Les comités techniques de FIS0 et de la CE1 collaborent dans des
domaines d’intérêt commun. D’autres organisations internationales, gouveme-
mentales et non gouvernementales, en liaison avec 1’ISO et la CE1 participent
également aux travaux.
Dans le domaine des technologies de l’information, I’ISO et la CE1 ont créé un
comité technique mixte, l’ISO/CEI JTC 1. Les projets de Normes internationales
adoptés par le comité technique mixte sont soumis aux organismes nationaux pour
approbation, avant leur acceptation comme Normes internationales. Les Normes
internationales sont approuvées conformément aux procédures qui requièrent
l’approbation de 75 % au moins des organismes nationaux votants.
La Norme internationale ISOKEI 10 18 l-l a été élaborée par le comit6 technique
mixte ISOKEI JTC 1, Technologies de l’information, sous-comité SC 21,
Interconnexion des systèmes ouverts, gestion des données et traitement distribué
ouvert, en collaboration avec I’UIT-T. Le texte identique est publié en tant que
Recommandation UIT-T X.8 10.
ISO/CEI 10 18 1 comprend les parties suivantes, présentées sous le titre général
Technologies de l’information - Interconnexion de systèmes ouverts (OSI) -
Cadres de sécurité pour les systèmes ouverts :
Partie 1: Aperçu
- Partie 2: Cadre d’authenttjkation
- Partie 3: Cadre de contrôle d’accès
Partie 4: Cadre de non-répudiation
- Partie 5: Cadre de confidentialité
- Partie 6: Cadre d’intégrité
Partie 7: Cadre pour l’audit de sécurité et les alarmes
Les annexes A et B de la présente partie de l’ISO/CEI 10 18 1 sont données
uniquement à titre d’information.

@ ISOKEI
ISOKEI 101814 : 1996 (F)
Introduction
Plusieurs applications ont des besoins de S&urit6 pour protéger les communications d’information contre les menaces.
Quelques menaces connues ainsi que les services et mécanismes de sécurité qui peuvent être utilisés pour s’en protéger
sont décrites dans la Rec. X.800 du CCITT I ISO 7498-2.
La présente Recommandation I Norme internationale définit le cadre dans lequel les services de sécurité pour les
systèmes ouverts sont spécifiés.
v
Page blanche
ISOKEI 10181~1:1996 (F)
NORME INTERNATIONALE
RECOMMANDATION UIT-T
TECHNOLOGIES DE L’INFORMATION- INTERCONNEXION DE
SYSTÈMES OUVERTS (OSI) - CADRES DE SÉCURITÉ POUR LES SYSTÈMES
OUVERTS: APERÇU
1 Domaine d’application
Les cadres de sécurité concernent l’application des services de sécurité dans l’environnement des systèmes ouverts, où le
terme systèmes ouverts est utilise pour inclure des domaines comme les bases de données, les applications distribuées, le
traitement ODP et l’interconnexion OSI. Les cadres de sécurité sont impliqués dans la définition des moyens d’offrir la
protection pour les systèmes et les objets au sein des systèmes, ainsi que les interactions entre systèmes. Ils ne couvrent
pas la méthodologie de construction des systèmes ou des mécanismes.
Les cadres de sécurité traitent à la fois des éléments de données et des séquences d’opérations (mais pas des éléments de
protocole) utilisés pour obtenir des services spécifiques de sécurité. Ces services de securité peuvent s’appliquer aux
entités communicantes des systèmes aussi bien qu’aux données échangées entre systemes, et aux donnees gérees par les
systèmes.
Les cadres de sécurité fournissent la base pour une normalisation ulterieure, fournissant une terminologie cohérente et
des définitions d’interfaces de service générique abstrait pour des besoins de sécurité spécifiques. Ils classifient
également les mécanismes qui peuvent être utilisés pour répondre à ces besoins.
Un service de sécurité dépend fréquemment d’autres services de sécurité, rendant difficile l’isolation d’une partie de la
sécurité des autres parties. Les cadres de sécurité font intervenir des services de sécurité particuliers, décrivent la gamme
des mécanismes qui peuvent être utilisés pour fournir les services de sécurité et identifient les interdépendances entre les
services et les mécanismes. La description de ces mécanismes peut mettre en jeu la confiance envers un service de
sécurité différent, et c’est de cette façon que les cadres de sécurite décrivent la confiance d’un service de sécurité envers
un autre.
Cette partie des cadres de sécurité:
-
décrit l’organisation des cadres de sécurité;
-
décrit les concepts de sécurité qui sont requis dans plus d’une partie des cadres de sécurité;
décrit la corrélation entre les services et mécanismes identifiés dans les autres parties des cadres.
Références normatives
Les Recommandations et Normes internationales suivantes contiennent des dispositions qui, par suite de la reférence qui
y est faite, constituent des dispositions valables pour la présente Recommandation I Norme internationale. Au moment de
la publication, les éditions indiquées étaient en vigueur. Toutes Recommandations et Normes sont sujettes à révision, et
les parties prenantes aux accords fondés sur la présente Recommandation I Norme internationale sont invitées à
rechercher la possibilité d’appliquer les éditions les plus récentes des Recommandations et Normes indiquées ci-après.
Les membres de la CE1 et de I’ISO possèdent le registre des Normes internationales en vigueur. Le Bureau de la
normalisation des télécommunications de I’UIT tient à jour une liste des Recommandations de I’UIT en vigueur.
21 . Recommandations I Normes internationales identiques
-
Recommandation UIT-T X.200 (1994) I ISOKEI 7498-l : 1994, Technologies de Z’infomtion -
Interconnexion des systèmes ouverts - Modèle de référence de base: Le modèle de référence de base.
Rec. UIT-T X.810 (1995 F)
ISOKEI 101814 : 1996 (F)
22 . Paires de Recommandations I Normes internationales équivalentes par leur contenu technique
-
Recommandation X.800 du CCITT (199 l), Architecture de sécurité pour l’interconnexion en systèmes
ouverts d’applications du CCITT.
ISO 7498-2: 1989, Systèmes de traitement de 1 ‘information - Interconnexion des systèmes ouverts -
Modèle de référence de base - Partie 2: Architecture de sécurité.
Définitions
Les définitions suivantes sont utilisées dans l’aperçu général ou sont communes a deux parties consécutives ou plus des
cadres de sécurité.
Pour les besoins de la présente Recommandation I Norme internationale, les définitions suivantes s’appliquent.
31 l Définitions du modèle de référence de base
La présente Recommandation I Norme internationale utilise les termes suivants définis dans la Rec. UIT-T X.200 I
ISOKEI 7498- 1:
-
couche (N);
- entite (N);
-
unité de données de protocole (N);
-
processus d’application;
- système réel ouvert;
-
système réel.
32 0 Définitions de l’architecture de sécurité
La présente Recommandation I Norme internationale utilise les termes suivants définis dans la Rec. X.800 du CCITT I
ISO 7498-2:
-
contrôle d’accès;
-
disponibilité;
-
cryptogramme;
-
valeur de contrôle cryptographique;
-
déchiffrement;
-
déni de service;
-
signature numérique;
-
chiffrement;
-
menace de l’intérieur;
-
clé;
-
gestion de clé;
-
texte en clair;
-
menace de l’extérieur;
-
audit de sécurité;
-
étiquette de sécurité;
-
poli tique de sécurité;
-
sensibilité;
-
menace.
33 0 Définitions additionnelles
Pour les besoins de la présente Recommandation I Norme internationale, les définitions suivantes s’appliquent.
2 Rec. UIT-T X.810 (1995 F)
ISOKEI 101814 : 1996 (F)
3.3.1 algorithme asymétrique de cryptographie: algorithme pour réaliser le chiffrement ou le déchiffrement
correspondant dans lequel les clés utilisées pour le chiffrement et le déchiffrement sont différentes.
NOTE - Avec certains algorithmes asymétriques de cryptographie, il faut utiliser plus d’une cl6 privée pour dechiffrer un
cryptogramme ou pour générer une signature numérique.
autorité de certification: entité habilitée à laquelle il est fait confiance (dans le contexte d’une politique de
3.3.2
sécurité) pour créer des certificats de sécurité contenant une ou plusieurs classes de données relatives à la sécurité.
entité de confiance conditionnelle: entité à laquelle il est fait confiance dans le contexte d’une politique de
3.3.3
sécurité, mais qui ne peut pas violer la politique de sécurité sans être détectée.
3.3.4 chaînage cryptographique: mode d’utilisation d’un algorithme cryptographique dans lequel la transformation
effectuée par l’algorithme dépend des valeurs des entrées ou sorties précédentes.
caractéristique d’un élément de données, telle qu’une valeur de contrôle
3.3.5 empreinte numérique:
cryptographique ou le résultat de la réalisation d’une fonction de hachage unidirectionnelle sur les données, qui est
suffisamment spécifique à l’élément de données pour qu’il ne soit pas possible de trouver, de façon informatique, un
autre élément de données ayant les mêmes caractéristiques.
3.3.6 identificateur caractéristique: données qui identifient de façon univoque une entité.
fonction de hachage: fonction (mathématique) qui fait correspondre les valeurs d’un grand ensemble
3.3.7
(potentiellement très grand) de valeurs à une gamme plus réduite de valeurs.
fonction unidirectionnelle: fonction (mathématique) qu’il est facile de calculer mais pour laquelle, lorsque le
3.3.8
résultat est connu, il n’est pas possible de trouver, de façon informatique, n’importe laquelle des valeurs qui auraient pu
être fournies pour obtenir celui-ci.
fonction de hachage unidirectionnelle: fonction (mathématique) qui est à la fois une fonction
3.3.9
unidirectionnelle et une fonction de hachage.
clé privée: clé qui est utilisée avec un algorithme asymétrique de cryptographie et dont la possession est
3.3.10
(habituellement a une seule entité).
limitée
3.3.11 clé publique: clé qui est utilisée avec un algorithme asymétrique de cryptographie et qui peut être rendue
publique.
sécurité émis par une autorité de sécurité pour indiquer qu’un certificat
3.3.12 certificat de révocation: certificat de
de sécurité particulier a été révoqué.
3.3.13 certificat de révocation de liste: certificat de sécurité qui identifie une liste de certificats de sécurité qui ont
été révoqués.
3.3.14 scellé: valeur de contrôle cryptographique qui met en œuvre l’intégrité mais qui ne protège pas d’une
falsification du récepteur (c’est-à-dire qu’il n’offre pas la non-répudiation). Lorsqu’un scellé est associé à un élément de
données, cet élément de données est dit scellé.
NOTE - Bien qu’un scellé n ‘offre pas lui- #même la non-répudiation, certains mkanismes de non-répudiation font usage du
service d’intégrité offert par les scellés, par exemple, pour protéger les communications avec des tierces parties de confiance.
3.3.15 clé secrète: clé qui est utilisée avec un algorithme symétrique de cryptographie. La possession de cette clé est
(habituellement à deux entités).
limitée
administrateur de sécurité: personne qui est responsable de la définition ou de l’application d’une ou de
3.3.16
plusieurs parties de la poli .tique de sécurité.
3.3.17 autorité de sécurité: entité qui est responsable de la définition, de la mise en œuvre ou de l’application de la
politique de sécurité.
3.3.18 certificat de sécurité: ensemble de données relatives a la sécurité émis par une autorité de sécurité ou une
tierce partie de confiance ainsi que les informations de sécurité qui sont utilisées pour fournir des services d’intégrité et
d’authentification de l’origine des données.
NOTE - Tous les certificats sont réputés être des certificats de sécurité (voir les definitions applicables dans 1’ISO 7498-2).
Le terme certificat de sécurité est adopté afin d’éviter des conflits de terminologie avec la Rec. UIT-T X.509 I ISOKEI 9594-8
(c’est-à-dire la norme d’authentification de l’annuaire).
3.3.19 chaîne de certificat de sécurité: séquence ordonnée de certificats de sécurité, dans laquelle le premier
certificat de sécurité contient des informations relatives a la sécurité et les certificats de sécurité suivants contiennent des
informations de sécurité qui peuvent être utilisées pour la vérification des certificats de sécurité précédents.
Rec. UIT-T X.810 (1995 F)
ISOKEI 10181-l : 1996 (F)
3.3.20 domaine de sécurité: ensemble d’éléments, politique de sécurité, autorité de sécurité et ensemble d’activités
liées a la sécurité dans lesquels l’ensemble des éléments est sujet à la politique de sécurité, pour les activités spécifiées et
la politique de sécurité est administrée par l’autorité de sécurité, pour le domaine de sécurité.
3.3.21 autorité du domaine de sécurité: autorité de sécurité qui est responsable de la mise en œuvre d’une politique
de sécurité pour un domaine de sécurité.
3.3.22 information de sécurité: information nécessaire pour mettre en œuvre des services de sécurité.
rétablissement de la sécurité: actions qui sont menées et procédures qui sont utilisées lorsqu’une violation de
3.3.23
sécurité est soit détectée soit soupçonnée d’avoir eu lieu.
3.3.24 règles d’interaction sécurisée: règles de politique de sécurité qui régissent des interactions entre domaines de
sécurité.
de sécurité: représentation politique de sécurité pour un domaine de sécurité au sein
3.3.25 règles de politique
d’un système réel.
3.3.26 jeton de sécurité: ensemble de données protégé par un ou plusieurs services de sécurité, ainsi que les
informations de sécurité utilisées pour la fourniture de ces services de sécurité, qui est transféré entre les entités
communicantes.
algorithme symétrique de cryptographie: algorithme pour réaliser le chiffrement ou algorithme pour réaliser
3.3.27
le déchi .ffrement correspondant dans lequel la même clé est requise à la fois pour le chiffrement et le déchiffrement.
3.3.28 confiance: on dit que l’entité X fait confiance à l’entité Y pour un ensemble d’activités si et seulement si
l’entité X suppose que l’entité Y se comportera d’une certaine façon par rapport aux activités.
3.3.29 entité de confiance: entité qui peut violer une politique de sécurité, soit en réalisant des actions qu’elle n’est
pas censée accompl ir, soit en ne réussissant pas à réaliser des action u’elle est censée accomplir.
s 9
tierce partie de confiance: autori .té de sécurité ou son agent auquel il est fait confiance au certaines
3.3.30
activités liées à la sécurité (dans le contexte d’une politique de sécurité).
3.3.31 entité de confiance inconditionnelle: entite de confiance qui peut violer une politique de sécurité sans être
détectée.
4 Abréviations
Pour les besoins de la présente Recommandation I Norme internationale, les abréviations suivantes sont utilisées.
ACI Information de contrôle d’accés (access control information)
os1 Interconnexion des systèmes ouverts (open systems interconnection)
ODP Traitement réparti ouvert (open distributed processing)
SI Information de sécurité (security information)
TTP Tierce partie de confiance (trusted third party)
5 Notation
La notation de couche utilisée est la même que celle qui est définie dans la Rec. UIT-T X.200 I ISOKEI 7498- 1.
Sauf indication contraire, le terme service sert à désigner un service de sécurité.
Sauf indication contraire, le terme certificat sert à désigner un certificat de sécurité.
6 Organisation
Le cadre de sécurité fait partie d’une Norme internationale multipartie (ISOKEI 10181) et d’une série de
Recommandations de I’UIT. Les cadres de sécurité sont décrits ci-après. Des cadres de sécurité additionnels pourront
être identifiés à l’avenir. Le cadre de gestion des clés ne fait pas partie de I’ISOKEI 10181, mais il a un domaine
d’application similaire et sa description est incluse dans un souci d’exhaustivité.
4 Rec. UIT-T X.810 (1995 F)
ISOKEI 10181-l : 1996 (F)
Partie 1 - Aperçu général
61 l
Voir l’article 1.
62 0 Partie 2 - Authentification
Ce cadre décrit tous les aspects d’authentification tels qu’ils s’appliquent aux systèmes ouverts, la relation de
l’authentification avec d’autres fonctions de sécurité comme le contrôle d’accès et les besoins de gestion pour
l’authentification.
Ce cadre:
a) définit les concepts élémentaires de l’authentification;
b) identifie les classes possibles pour les mécanismes d’authentification;
définit les services pour ces classes de mécanismes d’authentification;
C>
identifie les besoins fonctionnels pour les protocoles afin de mettre en œuvre ces classes de mécanismes
d)
d’authentification;
identifie des besoins généraux de gestion pour l’authentification.
e>
Le cadre d’authentification est situé au sommet de la hiérarchie des normes d’authentification qui fournissent les services,
la nomenclature et la classification des méthodes d’authentification. Immédiatement en dessous de celui-ci, des normes
comme I’ISOKEI 9798 (mécanismes d’authentification d’entité) fournissent plus en détail un ensemble particulier de ces
méthodes. Finalement, au bas de la hiérarchie, des normes comme la Rec. UIT-T X.509 I ISOKEI 9594-8 (le cadre
d’authentification de l’annuaire) utilisent ces concepts et ces méthodes dans le contexte d’une application ou d’un besoin
spécifique.
Le cadre d’authentification décrit un modèle d’authentification, un ensemble d’étapes dans lesquelles les activités
d’authentification peuvent être rangées par catégories, l’utilisation d’une tierce partie de confiance, l’utilisation de
certificats d’authentification pour échanger des informations d’authentification, un service d’authentification générique
basé sur ces étapes, et au moins cinq classes de mécanismes d’authentification qui fournissent le service générique
d’authentification. Cela comprend des mécanismes protégeant contre la divulgation d’informations d’authentification, et
contre la divulgation et la répétition sur les mêmes (et/ou différents) vérificateurs.
63 . Partie 3 - Contrôle d’accès
Ce cadre définit tous les aspects du contrôle d’accès (c’est-à-dire utilisateur à processus, utilisateur à données, processus à
processus, processus à données) dans les systèmes ouverts, les relations avec d’autres fonctions de sécurité, telles que
l’authentification et l’audit, et les besoins de gestion pour le contrôle d’accès.
Ce cadre:
a) définit les concepts de base pour le contrôle d’accès;
démon tre la façon dont les l concepts de base du contrôle d’accès peuvent être spécialisés pour en
b)
œuvre quelques services et mécanismes de contrôle d’accès communément reconnus;
définit ces services et les mécanismes de contrôle d’accès correspondants;
Cl
d) identifie les besoins fonctionnels des protocoles pour mettre en œuvre ces services et mécanismes de
contrôle d’accès;
identifie les besoins de gestion pour mettre en œuvre ces services et mécanismes de contrôle d’accès;
e)
f) traite de l’interaction des services et mécanismes de contrôle d’accès avec d’autres services et mécanismes
de sécurité.
Ce cadre de sécurité décrit un modèle de contrôle d’accès, un certain nombre d’étapes dans lesquelles les activités de
contrôle d’accès peuvent être rangées par catégories, un service générique de contrôle d’accès basé sur ces étapes, et au
moins trois classes de mécanismes de contrôle d’accès qui fournissent le service générique de contrôle d’accès. Cela
comprend des listes de contrôle d’accès, des capacités et des étiquettes.
64 l Partie 4 - Non-répudiation
Ce cadre détaille et étend les concepts des services de non-répudiation décrits dans la Rec. X.800 du CCITT I
ISO 7498-2 et fournit un cadre pour le développement et la fourniture de ces services.
Rec. UIT-T X.810 (1995 F)
ISOKEI 10181-l : 1996 (F)
Ce cadre:
définit les concepts élémentaires de non-répudiation;
a>
b) définit les services généraux de non-répudiation;
identifie les mécanismes possibles pour fournir des services de non-répudiation;
Cl
d) identifie des besoins généraux de gestion pour des services et mécanismes de non-répudiation.
65 . Partie 5 - Confidentialité
confidentialité vise à protéger l’information contre une divulgati .on non autorisée. Ce
Le service de cadre traite de la
confidentialité des informations pour la recherche, le transfert et la gestion.
Ce cadre:
a) définit les concepts élémentaires de confidentialité;
b) identifie les classes possibles de mécanismes de confidentialité;
c) définit les fonctionnalités de chaque classe de mécanismes de confidentialité;
d) identifie la gestion nécessaire pour mettre en œuvre les classes de mécanismes de confidentialité;
traite de l’interaction du mécanisme de confidentialité et des services le mettant en œuvre avec les autres
e)
services et mécanismes de sécurité.
Quelques-unes des procédures décrites dans ce cadre de sécurité assurent la confidentialité par l’application de
techniques cryptographiques. L’utilisation de ce cadre ne dépend pas de l’utilisation d’une technique cryptographique
particuliere ou d’autres algorithmes, bien que certaines classes de mécanismes de confidentialité puissent dépendre de
propriétés algorithmiques particulières.
66 . Partie 6 - Intégrité
que des données n’ont pas été modifiées ou détruites façon non
On appelle intégrité la propriété assurant de autorisée. Ce
cadre couvre l’intégrite des données pour la recherche, le transfert et la gestion des données.
Ce cadre:
a) définit le concept élémentaire d’intégrité;
identifie des classes possibles de mécanismes d’intégrite;
b)
définit des fonctionnalités pour chaque classe des mécanismes d’intégrité;
C)
identifie la gestion nécessaire pour mettre en œuvre les classes des mécanismes d’intégrité;
traite de l’interaction des services supports et des mécanismes d’intégrité avec d’autres services et
e)
mécanismes de sécurité.
Quelques-unes des procédures décrites dans ce cadre de sécurité permettent l’intégrité par l’application de techniques
cryptographiques. L’utilisation de ce cadre ne dépend pas de l’utilisation d’une technique cryptographique particulière ou
d’autres algorithmes, bien que certaines classes de mécanismes d’intégrité puissent dépendre de propriétés algorithmiques
particulières.
L’intégrité dont il est question dans ce cadre est celle qui est définie par l’invariabilité d’une valeur de données et non pas
celle de l’invariabilité de l’information que les données sont supposées représenter. Les autres formes d’invariabilité sont
exclues.
67 . Partie 7 - Audit et alarmes de sécurité
Ce cadre:
a) définit les concepts élémentaires d’audit et d’alarmes de sécurité;
b) fournit un modèle général pour l’audit et les alarmes de sécurité;
identifie la relation du service d’audit et d’alarmes de sécurité avec les autres services de sécurité.
C>
Comme pour les autres services de sécurité, un audit de sécurité peut être offert uniquement dans le contexte d’une
politique de sécurité. La politique de sécurité sera définie par les autorités de sécurité au sein de leur domaine de
sécurité. Toute(s) norme(s) spécifiant des mécanismes basés sur ce cadre devrait (devraient) être capable(s) de mettre en
œuvre différentes politiques de sécurité.
6 Rec. UIT-T X.810 (1995 F)
ISOKEI 10181-l : 1996 (F)
l Gestion de clé
Le cadre de gestion de clé, Partie 1 de I’ISOKEI 11770, a une relation spéciale avec les autres cadres de sécurité car il
couvre les fonctions qui ne sont pas directement liées aux autres services de sécurit6 identifiés dans la Rec. X.800 du
CCITT I ISO 7498-2. Ces fonctions sont applicables dans tout environnement de technologie de l’information où le
chiffrement ou la signature numérique est approprie(e).
Ce cadre:
identifie les objectifs de la gestion de clé;
a)
décrit les modèles généraux sur lesquels les mécanismes de gestion de cl6 sont basés;
c) définit les concepts élémentaires de la gestion de clé communs a toutes les parties de cette norme
mul tipartie;
définit les services de gestion de clé;
dl
identifie les caractéristiques des mécanismes de gestion de clé;
e>
spécifie les besoins pour la gestion des éléments relatifs aux clés durant leur cycle de vie;
décrit le cadre pour la gestion des éléments relatifs aux clés durant leur cycle de vie.
7 Concepts communs
De nombreux concepts sont nécessaires dans plus d’une partie des cadres de sécurité. Cette norme définit ces concepts à
utiliser dans les autres parties de cette Recommandation I Norme internationale.
71 . Information de sécurité
L’information de sécurité (SI) est l’information requise pour mettre en œuvre les services de sécurité. A titre d’exemples
d’information de sécurité, on peut citer:
-
les règles de politique de sécurité;
-
les informations pour réaliser des services spécifiques de sécurité, telles que l’information
d’authentification (AI) et l’information de contrôle d’accès (ACI);
-
aux mécanismes de sécurité, telles que les étiquettes de sécurité, les valeurs de
les informations relatives
contrôle cryptographique, les certificats de sécurité et les jetons de sécurité.
Les types de SI communs à plus d’un des cadres de sécurité sont traites dans l’article 8.
72 . Domaines de sécurité
Un domaine de sécurité est un ensemble d’éléments subordonnes a une politique de sécurité donnée administrée, pour
certaines activités spécifiques liées à la sécurité, par une seule autorité de sécurité. Les activités d’un domaine de sécurité
mettent en jeu un ou plusieurs éléments de ce domaine de sécurité et, éventuellement, des éléments d’autres domaines de
sécurité.
Exemples d’activités:
-
accès au x él éments;
-
établissement ou utilisation des connexions de couche (N);
opérations relatives à une fonction spécifique de gestion;
opérations de non-répudiation impliquant un notaire.
Une activité peut être relative à la sécurité même si elle n’est pas sujette a des mécanismes qui pourraient imposer une
politique arbitraire pour son utilisation. En particulier, des activités dont on ne peut empêcher le déroulement entre
n’importe quel groupe d’éléments peuvent être relatives à la sécurité et devenir, à l’avenir, le sujet de mécanismes de
contrôle.
Des exemples d’éléments d’un domaine de sécurité dans un environnement de systèmes ouverts comprennent des
éléments logiques ou physiques comme des systèmes ouverts réels, des processus d’application, des entités (N), des
unités de données de protocole (N), des relais et des utilisateurs humains de systèmes ouverts réels. Il y a des cas où les
utilisateurs humains doivent être distingués des autres éléments dans le domaine de sécurité. En pareils cas, le terme
objets de données sera utilisé pour distinguer les éléments non humains.
Rec. UIT-T X.810 (1995 F) 7
ISO/CEI 10181-l : 1996 (F)
7.2.1 Politique de sécurité et règles de politique de sécurité
Une politique de sécurité exprime, en des termes généraux, des besoins de sécurité pour un domaine de sécurité. Par
exemple, une politique de sécurité peut identifier des besoins qui s’appliquent à tous les membres du domaine de sécurité
fonctionnant sous des conditions spécifiques, ou qui s’appliquent à toutes les informations dans un domaine de sécurité.
La mise en œuvre d’une politique de sécurité se concrétisera par l’identification de services de sécurite qui satisferont la
politique de sécurité, et des mécanismes de sécurité seront choisis pour mettre en œuvre les services de sécurité. La
décision du choix des mécanismes de sécurité est influencée par les menaces prévues et par la valeur des ressources à
protéger.
Les politiques de sécurité sont communément formulées sous forme de principes généraux exprimés en langage naturel.
Ces principes reflètent les besoins de sécurité d’une organisation particulière ou les membres d’un domaine de sécurité.
Avant que ces besoins puissent être reflétés dans des systèmes ouverts réels, la politique de sécurité doit être détaillée de
telle façon qu’un ensemble de règles de politique de sécurité puisse en être dérivé. L’interprétation de ces besoins en tant
que règles de sécurité est une activité d’ingénierie. Une politique de sécurité limite les activités des éléments sujets a
cette politique de sécurité, soit en demandant certaines actions soit en interdisant certaines activités. Une politique de
sécurité peut également donner à des éléments la permission de prendre part à certaines activités. Il s’agit
d’une interprétation plus large de la politique de sécurité que celle qui est contenue dans la Rec. X.800 du CCITT I
ISO 7498-2, uniquement concernée par l’interconnexion OSI. Les aspects de politique de sécurité spécifiques à un
service de sécurité sont présentés dans le cadre de sécurité de ce service.
Les règles de la politique de sécurité pour un domaine de sécurité sont de deux types, celles concernant les activités au
sein d’un domaine de sécurité et celles concernant les activités entre domaines de sécurité. Les règles de politique de
sécurité du dernier type sont traitées comme des règles d’interaction sécurisée. Une politique de sécurité peut également
définir les règles qui s’appliquent aux relations avec tous les domaines de sécurité et les règles qui s’appliquent aux
relations avec des domaines de sécurité particuliers.
Les règles de politique de sécurité pour un domaine de sécurité doivent être maintenues en vigueur lorsque le système
change ou lorsque les activités et la politique de sécurité du domaine de sécurité sont modifiées.
NOTE - Ce cadre ne concerne pas les aspects suivants de la politique de
...