ISO/IEC TR 13594:1995
(Main)Information technology — Lower layers security
Information technology — Lower layers security
Describes the cross layer aspects of the revision of security services in the lower layers of the OSI reference Model (transport, network, data link, physical). Describes the architectural concepts common to these layers, the basis for interactions relating to security between layers and the placement of security protocols in the lower layers.
Technologies de l'information — Modèle de sécurité des couches inférieures
La présente Recommandation | Rapport technique décrit les aspects inter-couches de la fourniture de services de sécurité dans les couches inférieures du Modèle de référence OSI (couches transport, réseau, liaison de données et physique). La présente Recommandation | Rapport technique décrit: a) les concepts architecturaux communs aux couches inférieures sur la base des éléments définis dans la Rec. X.800 du CCITT | ISO 7498-2; b) les bases des interactions relatives à la sécurité entre les protocoles des couches inférieures; c) les bases de toute interaction relative à la sécurité entre couches inférieures et couches supérieures de l'OSI; d) le positionnement des protocoles de sécurité par rapport aux autres protocoles des couches inférieures, et le rôle relatif de tels positionnements. Il ne doit pas y avoir de conflit entre les protocoles de sécurité des couches inférieures et le modèle décrit dans la présente Recommandation | Rapport technique. La Rec. X.500 du CCITT | ISO/CEI 9594-1 identifie les services de sécurité qui relèvent de chacune des couches inférieures du Modèle de référence OSI.
General Information
Buy Standard
Standards Content (Sample)
ISO/IEC
TECHNICAL
TR 13594
REPORT
First edition
1995-12-15
Information technology - Lower layers
security
Technologies de /‘information - ModGle de s&wit6 pour les couches
infkeures
Reference number
&O/I EC TR 13594: 1995(E)
---------------------- Page: 1 ----------------------
ISO/IEC TR 13594: 1995(E)
CONTENTS
Page
1
1
Scope .
1
2 References .
2.1 . 1
Identical Recommendations I International Standards
.......................... 2
2.2 Paired Recommendations I International Standards equivalent in technical content
2
2.3 Additional references .
2
3 Definitions .
2
31 . OS1 Reference Model definitions .
3
3.2 Open System Security Frameworks definitions .
3
3.3 Internal Organization of the Network Layer definitions .
Additional definitions . 3
3.4
Abbreviations . 3
4
3
5 Security associations .
3
5.1 General overview .
...................................................................... 5
5.2 Establishing a security association for the lower layers
6
5.3 Security association close .
6
5.4 Modification of attributes in a connection .
6
6 Influence on existing protocols .
6
. General principle .
61
6
Connectionless SDU size .
62 .
6
63 . Concatenation of PDUs .
6
64 . Algorithm and mechanism independence .
7
7 Common security PDU structure .
...................................................................................... 7
Determination of security services and mechanisms
8
7
Protection QOS .
9
7
..................................................................................................................................................
10 Security rules
7
.......................................................................................................
11 Placement of security in the lower layers
13
......................................................................................
12 Use of (N-1)-layer(s) to enhance (N)-layer security
13
13 Security labelling .
13
14 Security domains .
13
15 Security of routeing .
14
Security Management .
16
14
....................................................................................................................................
16.1 Security policy
14
.......................................................................................................
16.2 Security association management
14
16.3 Key management .
14
16.4 Security Audit .
14
Traffic flow confidentiality .
17
15
Guidelines for the definition of SA-Attributes .
18
15
................................................................................................................................................
19 Error handling
16
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Annex A - Illustrative example of an Agreed Set of Security Rules
0 ISO/IEC 1995
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
microfilm, without permission in writing from the publisher.
ISO/IEC Copyright Office l Case postale 56 l CH-1211 Gen&ve 20 l Switzerland
Printed in Switzerland
ii
---------------------- Page: 2 ----------------------
@ ISO/IEC ISO/lEC TR 13594:1995(E)
Foreword
IS0 (the International Organization for Standardization) and IEC (the International 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.
The main task of technical committees is to prepare International Standards, but in exceptional circum .stances a technical
committee may propose the publication ofa Technical Report of one of the following types:
- type 1, when the required support cannot be obtained for the publication of an International Standard, despite
repeated efforts;
- type 2, when the subject is still under technical development or where for any other reason there is the future but
not immediate possibility of an agreement on an International Standard;
type 3, when a technical committee has collected data of
a different kind from that which is normally published as
an International Standard (“state of the art”, for example).
Technical reports of types 1 and 2 are subject to review within three years of publication, to decide whether they can be
transformed into International Standards. Technical Reports of type 3 do not necessarily have to be reviewed until the
data they provide are considered to be no longer valid or useful.
ISO/IEC TR 13594, which is a Technical Report of type 3, was prepared by Joint Technical Committee ISO/IEC JTC 1,
Information technology, in collaboration with ITU-T. The identical text is published as ITU-T Recommendation X.802.
. . .
111
---------------------- Page: 3 ----------------------
ISO/IEC TR 13594: 1995(E) @ ISO/IEC
Introduction
This Recommendation I International Standard describes the cross layer aspects of the revision of security services in the
lower layers of the OS1 Reference Model (Transport, Network, Data Link, Physical). It describes the architectural
concepts common to these layers, the basis for interactions relating to security between layers and the placement of
security protocols in the lower layers.
iv
---------------------- Page: 4 ----------------------
ISO/IEC TR 13594 : 1995 (E)
TECHNICAL REPORT
ITU-T RECOMMENDATION
INFORMATION TECHNOLOGY - LOWER LAYERS SECURITY MODEL
1 * Scope
This Recommendation I Technical Report describes the cross layer aspects of the provision of security services in the
lower layers of the OS1 Reference Model (Transport, Network, Data Link and Physical layers).
This Recommendation I Technical Report describes:
a) architectural concepts common to the lower layers based on those defined in CCITT Rec. X.800 I
IS0 7498-2;
the basis for interactions relating to security between protocols in the lower layers;
b)
the basis for any interactions relating to security between the lower layers and upper layers of OSI;
C>
the placement of security protocols in relation to other lower layer security protocols and the relative role
d)
of such placements.
There should be no conflict between the
security protocols for the lower layers and the model described in this
Recommendation I Technical Report.
CCITT Rec. X.500, I ISO/IEC 9594-l identifies the security services relevant to each of the lower layers of the OS1
Reference Model.
2 References
The following Recommendations and International Standards contain provisions which, through reference in this text,
constitute provisions of this Recommendation I Technical Report. At 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 Technical Report are encouraged to investigate the possibility of applying the most recent edition of
the Recommendations and Standards listed 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-T Recommendations.
21 . 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.
-
ITU-T Recommendation X.233 (1993) I ISOIIEC 8473-l : 1994, Information technology - Protocol for
providing the OSI connectionless-mode Network service: Protocol specification.
-
ITU-T Recommendation X.234 (1994) I ISO/IEC 8602: 1995, Information technology - Protocol for
providing the OSI connectionless-mode Transport service.
-
ITU-T Recommendation X.273 (1994) I ISO/IEC 11577:1995, Information technology - Open Systems
Interconnection - Network layer security protocol.
-
ITU-T Recommendation X.274 (1994) I ISO/IEC 10736:1995, Information technology - Telecommuni-
cations and information exchange between systems - Transport layer security protocol.
-
ITU-T Recommendation X.803 (1994) I ISO/IEC 10745: 1995, Information technology - Open Systems
Interconnection
- Upper layers security model.
ITU-T Rec. X.802 (1995 E) 1
---------------------- Page: 5 ----------------------
ISOIIEC TR 13594 : 1995 (E)
-
ITU-T Recommendation X.810’) I ISO/IEC 10181-l.*), Information technology - Open Systems
Interconnection - Security frameworks in open systems: Security frameworks overview.
- ITU-T Recommendation X.812’) I ISO/IEC 10181-3.*), Information technology - Open Systems
Interconnection - Security frameworks in open systems: Access control framework.
22 . Paired Recommendations I International Standards equivalent in technical content
-
CCITT Recommendation X.800 (199 l), Security architecture for Open Systems Interconnection for
CCITT applications.
IS0 7498-2: 1989, Information processing systems - Open Systems Interconnection - Basic Reference
Model - Part 2: Security Architecture.
- ITU-T Recommendation X.224 (1993), Protocol for providing the OSI connection-mode transport
servzce.
ISO/IEC 8073: 1992, Information technology - Telecommunications and information exchange between
- Protocol for providing the connection-mode Transport service.
systems - Open Systems Interconnection
-
CCITT Recommendation X.208 (1988), Specification of Abstract Syntax Notation One (ASN. I).
Open Systems Interconnection - Specification of Abstract
ISO/IEC 8824: 1990, Information technology -
Syntax Notation One (ASN.1).
-
CCITT Recommendation X.209 (1988), Specification of Basic Encoding Rules for Abstract Syntax
Notation One (ASN. I).
ISO/IEC 8825: 1990, Information technology - Open Systems Interconnection - Specification of Basic
Encoding Rules for Abstract Syntax Notation One (ASN. I).
23 . Additional references
-
ISO/IEC 8208:1995, Information technology - Data communications - X.25 Packet Layer Protocol For
Data Terminal Equipment.
-
ITU-T Recommendation X.25 (1993), Inter$ace between Data TerminaL Equipment (DTE) and Data
Circuit-Terminating Equipment (DCE) for terminals operating in packet mode and connected to public
data networks by dedicated circuits.
- IS0 8648: 1988, Information processing systems - Open Systems Interconnection - Internal organization
of the Network Layer.
-
IS0 9542: 1988*), Information processing systems - Telecommunications and information exchange
- End system to intermediate system routeing exchange protocol for use in conjunction
between systems
with the Protocol for providing the connectionless-mode network service (IS0 8473).
-
- Telecommunications and information exchange between
ISO/IEC 10589: 1992, Information technology
systems - Intermediate system to intermediate system intra-domain-routeing routine information
exchange protocol for use in conjunction with the protocol for providing the connectionless-mode
Network service (IS0 8473).
-
ISO/IEC 10747: 1994, Information technology - Telecommunications and information exchange between
systems - Protocol for exchange of inter-domain routeing information among intermediate systems to
support forwarding of IS0 8473 PDUs.
Definitions
3
. OS1 Reference Model definitions
31
This Recommendation I Technical Report makes use of the following terms as defined in ITU-T Rec. X.200 I
ISO/IEC 7498- 1:
- Quality of Service
‘) Presently at the stage of draft.
*) Currently under revision.
ITU-T Rec. X.802 (1995 E)
2
---------------------- Page: 6 ----------------------
ISO/IEC TR 13594 : 1995 (E)
32 . Open System Security Frameworks definitions
This Recommendation I Technical Report makes use of the following terms as defined in ITU-T Rec. X.810 I
ISO/IEC 10181-l:
0. 1
-
security aomain
33 b Internal Organization of the Network Layer definitions
This Recommendation I Technical Report makes use of the following terms as defined in IS0 8648:
subnetwork access protocol;
a>
b) end system;
intermediate system.
C>
34 . Additional definitions
For the purposes of this Recommendation I Technical Report, the following definitions apply:
3.4.1 reflection protection: A protection mechanism to detect when a protocol data unit has been sent back to the
originator.
3.4.2 security association attributes: The collection of information required to control the security of
communications between an entity and its remote peer(s).
3.4.3 security association: The relationship between lower layer communicating entities for which there exists
corresponding security association attributes.
security rules: Local information which, given the security services selected specify the underlying security
3.4.4
mechanisms to be employed, including all parameters needed for the operation of the mechanism.
NOTE - Security rules are a form of secure interaction rules as defined in the Upper Layers Security Model
(ITU-T Rec. X.803 I ISO/IEC 10745).
4 Abbreviations
ISN Integrity Sequence Number
SSAA Set of SA-Attributes
NLSP Network Layer Security Protocol
NLSP-CO NLSP Connection mode
NLSP-CL NLSP Connectionless mode
Quality of Service (as defined in CCITT Rec. X.200 I ISO/IEC 7498-l)
QOS
SA Security Association
SA-ID
Security Association Identifier
SNAcP Subnetwork Access Protocol (as defined in IS0 8648)
SNISP Subnetwork Independent Security Protocol
TLSP Transport Layer Security Protocol
5 Security associations
. General overview
51
5.1.1 Any security protocol makes use of a number of security mechanisms to provide security services to the layer
above. The security services required by the higher layer may be indicated to the lower layers through use of local
security management functions. The security protocol and each of its security mechanisms require information, in
addition to that which is encoded in the PDUs, to enable secure communication. Examples of such additional
IT&T Rec. X.802 (1995 E)
3
---------------------- Page: 7 ----------------------
ISO/IEC TR 13594 : 1995 (E)
information are the specification of the mechanisms to be used by the protocol and, for each mechanism, specific
information such as the key required by an encipherment mechanism. Each piece of additional information is known as a
Security Association Attribute.
5.1.2 Security Association Attributes may be placed in a protocol entity using a number of mechanisms. Some
examples of placement mechanisms are:
placement during manufacture of a device;
a>
b) placement during initialisation of a device;
placement via a manual interface, e.g. front panel controls;
C>
placement by OS1 Systems Security Management;
d)
’ e) placement by OS1 Layer Security Management;
f) placement by OS1 Operations Security Management.
5.1.3 SA-Attributes may be placed at any time prior to the communication to which they relate. When compatible
Sets of SA-Attributes (SSAA) are in place in each protocol entity, a Security Association is said to exist between the
protocol entities.
5.1.4 SSAAs (and Security Associations) may exist with different granularity. Sometimes it is useful to be able to
refer to SSAAs with different granularity. For instance, the SSAA defined by an Agreed Set of Security Rules (ASSR)
could be denoted by SSAA ASSR. Or a pairwise key may be established between two protocol entities for use over a
number of instances of common Source-Destination Address Pair. Similarly the SSAA for an instance of communication
could be referred to by S&AA-Instance of Communication. Likewise the SSAA for a connection oriented PDU could be
referred to by SSAA CO PDU.
5.1.5 In general, SA-Attributes must be placed in the Protocol Entity by secure means in order to maintain security.
This implies that the SA-Attributes are either placed using a physically secure means or they may be placed making use
of an existing Security Association which has been pre-placed for this purpose.
5.1.6 The SSAA which are part of a security association are often referred to by an identifier which has local
significance and is known as an SA-ID. At any instant, some members of the Set of SA-Attributes may be undefined.
Typically during the initialisation of a secure communication, the SSAA will not be fully populated and the initial
exchanges will be used to completely populate the SSAA before user data is exchanged.
5.1.7 In order to provide Replay Protection, constraints must be applied to the use of SA-IDS, their referenced
SSAAs and SA-Attributes.
SA-IDS may not be re-used with the same encipherment key.
a>
b) After any SA-Attribute has been populated in a SSAA which is referred to by an SA-ID, that
SA-Attribute may never be changed unless the security protocol has a means for signalling the change
between the communicating entities. This implies that to enable key roll-over a new SA-ID must be used
with copies of the old SA-Attributes and a new key unless the security protocol has an alternative means
of signalling the key change (e.g. as supported by NLSP-CO CSC PDU).
5.1.8 Removal of any SA-Attribute from the SSAA effectively closes the Security Association
5.1.9 Some SA-Attributes have significance for an instance of communication (a connectionless PDU or a
connection). Other SA-Attributes have significance for a single PDU on a connection. Examples of such SA-Attributes
are Integrity Sequence Numbers and Security Labels. It may appear that the changing of these SA-Attributes violates the
constraint in b) in 5.1.7 above. However, logically the Security Association, including these SA-Attributes, is only valid
for the lifetime of a single PDU. The ISN acts as a logical extension to the SA-ID, hence changing the effective SA-ID.
The label is only valid for this instance of the extended SA-ID. Thus, the constraints are maintained. Such SA-Attributes
are sometimes termed ‘Dynamic’ SA-Attributes.
5.1.10 Part of a security policy will constrain the operation of the protocol entity. This part of the security policy is
termed the Set of Security Rules for the Protocol Entity. The Set of Security Rules for a protocol entity may constrain
such things as the security mechanisms to be used and the values and placement mechanisms for the SA-Attributes. The
Set of Security Rules will also define the mapping of the security services selected into Security mechanisms used by the
Security Protocol. The Set of Security Rules is a form of Secure Interaction Rules.
5.1.11 When used for operation within or between domains, a unique identifier for such Sets of Security Rules needs
to be established and is known as an Agreed Set of Security Rules. The ASSR identifier may be exchanged as part of
Security Association establishment to define or constrain the SSAA ASSR which are defined in that Set of Security
Rules. The remaining SA-Attributes, if any, must be established using other means such as those listed in 5.1.2 above.
4 ITU-T Rec. X.802 (1995 E)
---------------------- Page: 8 ----------------------
ISO/IEC TR 13594 : 1995 (E)
52 * Establishing a security association for the l.ower layers
5.2.1 In order to protect an instance of communication (a connectionless SDU or a connection) a security association
.’
has to be established between the communicating entities.
The information forming an SA is either static information, which may be “negotiated” when the SA is
5.2.2
established and then remains fixed for the duration of the association, or dynamic information which may be updated in
an instance of communication.
5.2.3 An SA may be established as a OS1 layer 1 to 4 protocol through the exchange of security association protocol
data units (PDUs), or through mechanisms outside the scope of the lower layers of OSI.
5.2.4 Prior to establishing an SA each entity must have pre-established a common, mutually agreed and uniquely
identified, set of security rules as well as the security services that may be selected.
5.2.5 If the SA is to be established through the exchange of security association PDUs, then the following must also
be pre-established:
An initial selection of security services, and hence the security mechanisms, to be applied in establishing
a)
anSA.
b) Basic keying information needed to establish an SA.
5.2.6 On SA establishment, an entity establishes the following shared information with its remote peer which must
remain unchanged (i.e. static) for the lifetime of the association:
a) Local and remote SA-IDS.
b) The Security Services Selected for use between the associated entities for instances of communication.
NOTE - The security services to be used may be selected among the pre-established security services.
c) The mechanisms and their properties to be used as implied through the Security Services Selected.
d) Initial shared keys for integrity, encipherment mechanisms and authentication of an instance of
communication;
e) The set of security labels and addresses that may be used on this association for access control.
5.2.7 The SA-IDS and shared keys [items a) and d) above] must be established on a per association basis. The other
information may be pre-established. In addition, as part of establishing a SA the identity of the remote peer must be
authenticated to provide peer entity authentication.
5.2.8 The following information can be dynamically updated for an instance of communication:
a) Integrity sequence number(s) as needed for normal and expedited data in each direction.
b) A security label which is selected dynamically from the static set of security labels.
c) Re-key information for the encipherment/integrity mechanisms in security protocols supporting re-keying
within an association (e.g. the connection-mode Network Layer Security Protocol).
5.2.9 To achieve peer entity or data origin authentication, authentication mechanisms need to be applied to each
instance of communication.
5.2.10 The different SA-Attributes that may be established at the different stages of a security association are shown
diagrammatically as in Figure 1. The terms pre-established, static and dynamic are used in relation to a security
association as described in the preceding subclauses. The terms used and the form of authentication are as described in
the preceding subclauses.
Dynamic
Static
Pre-established
SA-I Ds ISN
Agreed Set of Security Rules
Initial Keys Security Label
Possible Security Services
Re-key information
Initial Security Services Authentication
Authentication
Basic key information
Selected level of Protection QOS
Selected mechanism
Security label / Address set
Figure 1 - Illustration of Attributes of a Security Association
IT&T Rec. X.802 (1995 E)
---------------------- Page: 9 ----------------------
ISO/IEC TR 13594 : 1995 (E)
5.2.11 An entity should identify necessary SA-Attributes using the SA-ID.
5.2.12 The SA shall be established prior to protecting an instance of communication.
.
53 Security association close
An SA indicated by an SA-ID is closed when the SA is no longer valid.
A security association can be closed by the following methods:
a) as a OS1 layer 1 to 4 protocol through the exchange of security association protocol data units (PDUs);
b) using external mechanisms outside the scope of the lower layers of OSI;
implicitly by closing a connection (this is applicable only to connection mode);
C>
d) implicitly when a key within the SA expires.
NOTE - Care should be taken in using this approach d) with the lifetime of a key defined by the number of
packets sent/received between peer entities since significantly different values may result in each peer.
Before using method c) above, an attribute of the security association must indicate that the association is to be closed
on closing a connection using that association.
54 . Modification of attributes in a connection
For each instance of communication (a connectionless PDU or a connection), only one SA can be established.
During the exi stence of a connection the set urity services and mechanisms used on that connection cannot be modified
(note this does not preclude changing keys).
Indication of use of new keys shall be described by the security protocol.
6 Influence on existing protocols
61 . General principle
In principle the influence of security protocols on existing protocols should be minimal.
62 . Connectionless SDU size
During data transfer, depending on the security mechanisms selected, security has the following impact on the (N)-layer
protocol:
the (N)-user-data, and in some cases parts of the (N)-protocol-control-information, is operated on by
a>
This may change the length of the
cryptographic transformations before and after transmission.
(N)-user-data.
b) protocol control information related to (N)-user-data (e.g. security association identifier, cryptographic
check code) may need to be carried by the (N)-protocol.
NOTE - This will have impact on the maximum User Data size as defined in CCITT Rec. X.213 I
ISO/IEC 8348, subclause 152.3 and CCITT Rec. X.214 I ISOAEC 8072.
63 . Concatenation of PDUs
Only PDUs which are to be protected under the same security association may be concatenated.
64 . Algorithm and mechanism independence
Lower layer security protocols are specified to be independent of the algorithm. Furthermore, NLSP has taken the
approach of separating mechanism dependent and mechanism independent parts of the security protocol. It is anticipated
that future lower layer security protocols may achieve this using generic abstract services for security common to the
upper and lower layers of OSI.
6 ITU-T Rec. X.802 (1995 E)
---------------------- Page: 10 ----------------------
ISO/IEC TR 13594 : 1995 (E)
7 Common security PDU structure
A common general PDU structure is to be used for protected data
...
RAPPORT
ISO/CEI
TECHNIQUE
TR 13594
Première édition
1995-l 2-15
Technologies de l’information - Modèle
de sécurité des couches inférieures
Information technology - Lower layers security
\
Numéro de référence
la
ISO/CEI TR 13594:1995(F)
---------------------- Page: 1 ----------------------
ISOKEI TR 13594: 1995(F)
Sommaire
Page
1
....................................................................................................................................
1 Domaine d’application
1
...................................................................................................................................
2 Références normatives
1
......................................................................
21 Recommandations I Normes internationales identiques
2
.......
2:2 Paires de Recommandations I Normes internationales équivalentes par leur contenu technique
2
2.3 Autres références .
3
3 Définitions .
3
.............................................................................................
3.1 Définitions du modele de réference OS1
............................................... 3
3.2 Définitions du cadre général de la sécurité dans les systèmes ouverts
................................................................... 3
Définitions de l’organisation interne de la couche reseau
33
3
314 Définitions supplémentaires .
3
Abreviations .
4
4
Associations de sécurité .
5
4
Vue d’ensemble .
51
5
................................................
5:2 Etablissement d’associations de sécurité pour les couches inférieures
6
.........................................................................................................
5.3 Clôture d’association de securite
6
...................................................................................
54 . Modification des attributs dans une connexion
7
.............................................................................................................
6 Influence sur les protocoles existants
7
61 Principe général .
7
.......................................................................................................
612 Taille d’une SDU sans connexion
7
6.3 Concaténation de PDU .
7
..............................................................................
Indépendance des algorithmes et des mécanismes
64 .
7
Structure commune de sécurite des PDU .
7
8
..................................................................................
8 Détermination des services et mécanismes de sécurité
8
.....................................................................................................................
9 Qualité de service de protection
8
...........................................................................................................................................
10 Règles de sécurité
....................................................... 8
11 Positionnement des protocoles de sécurité dans les couches inférieures
14
....................................................
Utilisation des couches (N-l) pour renforcer la sécurité de la couche (N)
12
15
.....................................................................................................................................
13 Etiquetage de sécurité
15
.....................................................................................................................................
14 Domaines de sécurité
15
.........................................................................................................................................
15 Sécurite du routage
0 ISOKEI 1995
Droits de reproduction réservés. Sauf prescription différente, aucune partie de cette publi-
cation ne peut être reproduite ni utilisée sous quelque forme que ce soit et par aucun pro-
cé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 1996
Imprimé en Suisse
ii
---------------------- Page: 2 ----------------------
ISOKEI TR 13594: 1995(F)
0 ISOKEI
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
16 Gestion de la sécurité
16
16.1 Politique de skurité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
16.2 Gestion des associations se sécurité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16.3 Gestion des clés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
16.4 Vérifications de sécurité
16
17 Confidentialité du flux de trafic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
18 Directives pour la définition des attributs d’association de sécurité
17
19 Traitement d’erreurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .~.
18
Annexe A - Exemple d’ensemble convenu de règles de sécurité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . .
111
---------------------- Page: 3 ----------------------
ISOKEI TR 13594: 1995(F)
0 ISO/CEI
Avant-propos
LIS0 (Organisation internationale de normalisation) et la CE1 (Commission
électrotechnique internationale) forment le système spécialisé de normalisation
mondiale. Les organismes nationaux membres de 1’ISO ou de la CE1 participent
au développement de 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 l’IS0 et
de la CE1 collaborent dans des domaines d’intérêt commun. D’autres organisa-
tions internationales, gouvernementales ou non gouvernementales, en liaison avec
I’ISO et la CE1 participent également aux travaux.
Dans le domaine des technologies de l’information, 1’ISO et la CE1 ont créé un
comité technique mixte, 1’ISOKEI JTC 1.
La tâche principale des comités techniques est d’élaborer les Normes interna-
tionales. Exceptionnellement, un comité technique peut proposer la publication
d’un rapport technique de l’un des types suivants:
- type 1, lorsque, en dépit de maints efforts, l’accord requis ne peut être
réalisé en faveur de la publication d’une Norme internationale;
- type 2, lorsque le sujet en question est encore en cours de développement
technique ou lorsque, pour toute autre raison, la possibilité d’un accord pour
la publication d’une Norme internationale peut être envisagée pour l’avenir
mais pas dans l’immédiat;
- type 3, lorsqu’un comité technique a réuni des données de nature différente
de celles qui sont normalement publiées comme Normes internationales
(ceci pouvant comprendre des informations sur l’état de la technique, par
exemple).
Les rapports techniques des types 1 et 2 font l’objet d’un nouvel examen trois ans
au plus tard après leur publication afin de décider éventuellement de leur transfor-
mation en Normes internationales. Les rapports techniques du type 3 ne doivent
pas nécessairement être révisés avant que les données fournies ne soient plus
jugées valables ou utiles.
L’ISOKEI TR 13594, rapport technique du type 3, a été élaboré par le comité
technique mixte ISOKEI JTC 1, Technologies de Z’information, en collabora-
tion avec I’UIT-T. Le texte identique est publié en tant que Recommandation
UIT-T X.802.
---------------------- Page: 4 ----------------------
ISOKEI TR 13594: 1995(F)
0 ISOKEI
Introduction
La présente Recommandation I Rapport technique décrit les aspects inter-couches de la fourniture des services de
sécurité dans les couches inferieures du Modele de référence OS1 (couches transport, reseau, liaison de données et
physique). Elle décrit les concepts architecturaux communs à ces couches, la base des interactions entre couches
relatives à la sécurité, et le positionnement des protocoles de sécurité dans les couches inférieures.
---------------------- Page: 5 ----------------------
Page blanche
---------------------- Page: 6 ----------------------
ISOKEI TR 13594 : 1995 (F)
RAPPORT TECHNIQUE
RECOMMANDATION UIT-T
TECHNOLOGIES DE L’INFORMATION -
MODÈLE DE SÉCURITÉ DES COUCHES INFÉRIEURES
1 Domaine d’application
La présente Recommandation I Rapport technique décrit les aspects inter-couches de la fourniture de services de sécurite
dans les couches inférieures du Modèle de réference OS1 (couches transport, réseau, liaison de données et physique).
La présente Recommandation I Rapport technique décrit:
a) les concepts architecturaux communs aux couches inférieures sur la base des éléments définis dans la
Rec. X.800 du CCITT I ISO 7498-2;
b) les bases des interactions relatives à la sécurité entre les protocoles des couches inférieures;
c) les bases de toute interaction relative à la sécurité entre couches inférieures et couches supérieures de
I’OSI;
d) le positionnement des protocoles de securité par rapport aux protocoles des inférieures
le rôle relatif de tels positionnements.
conflit entre les protocoles de sécurité des couches inferieures et le modèle décrit dans la
Il ne doit pas y avoir de
présente Recommandation I Rapport technique.
La Rec. X.500 du CCITT I ISOKEI 9594-l identifie les services de sécurité qui relèvent de chacune des couches
inférieures du Modèle de référence OSI.
2 Références normatives
Les Recommandations et les 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 Rapport technique. 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 fondes sur la présente Recommandation I Rapport technique 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-T en vigueur.
21 . Recommandations I Normes internationales identiques
-
Recommandation UIT-T X.200 (1994) I ISOKEI 749% 1: 1994, Technologies de Z’information -
Interconnexion de systèmes ouverts -Modèle de référence: Le modèle de référence de base.
-
Recommandation UIT-T X.233 (1993) l ISOKEI 8473-l : 1994, Technologies de l’information - Protocole
assurant le service réseau en mode sans connexion de l’interconnexion de systèmes ouverts: Spécifîcation
du protocole.
-
Recommandation UIT-T X.234 (1994) I ISOKEI 8602:1995, Technologies de I?nformation - Protocole
assurant le service de transport en mode sans connexion de l’interconnexion des systèmes ouverts (OU).
-
Recommandation UIT-T X.273 (1994) I ISOKEI 11577:1995, Technologies de Z’information -
Interconnexion de systèmes ouverts - Protocole de sécurité de la couche réseau.
-
Recommandation UIT-T X.274 (1994) 1 ISOKEI 10736:1995, Technologies de Z’information -
Télécommunications et échange d’informations entre systèmes - Protocole de sécurité de la couche
transport.
Rec. UIT-T X.802 (1995 F) 1
---------------------- Page: 7 ----------------------
ISOKEI TR 13594 : 1995 (F)
-
Recommandation UIT-T X.803 (1994) I ISOKEI 10745:1994, Technologies de l’information -
Interconnexion de systèmes ouverts - Modèle de sécurité pour les couches supérieures.
-
Recommandation UIT-T X.810’) I ISOKEI 10181-l. l), Technologies de 1 ‘information - Interconnexion
de systèmes ouverts - Cadre général de la sécurité dans les systèmes ouverts: Aperçu général.
-
l) Technologies de l’information - Interconnexion
Recommandation UIT-T X.812l) I ISOKEI 10181-3. ,
de systèmes ouverts - Cadre général de la sécurité dans les systèmes ouverts: Contrôle d’accès.
v
22 0 Paires de Recommandations I Normes internationales équivalentes par leur contenu technique
-
Recommandation X.800 du CCITT (1991), Architecture de sécurité pour Z’interconnexion en systèmes
ouverts d’applications du CCITT.
ISO 7498-2: 1989, Systèmes de traitement de l’information - Interconnexion de systèmes ouverts - Modèle
de référence de base. Partie 2 - Architecture de sécurité.
-
Recommandation UIT-T X.224 (1993), Protocole pour assurer le service de couche transport en mode
connexion pour 1 ‘interconnexion de systèmes ouverts.
ISOKEI 8073: 1992, Technologies de 1 ‘information - Télécommunications et échanges d’informations
Protocole pour fourniture du service de
entre systèmes - Interconnexion de systèmes ouverts (OSI) -
transport en mode connexion.
-
Recommandation X.208 du CCITT (1988), Spécijkation de la syntaxe abstraite numéro un (ASN. I).
ISOKEI 8824: 1990, Technologies de 1 ‘information - Interconnexion de systèmes ouverts (OSI) -
Spécification de la notation de syntaxe abstraite numéro 1 (ASN. I).
-
Recommandation X.209 du CCITT (1988), Spécifkation des règles de codage de base pour la notation
de syntaxe abstraite numéro un (ASN. 1).
Interconnexion de systèmes ouverts - Spécification
ISOKEI 8825: 1990, Technologies de 1 ‘information -
de règles de base pour coder la notation de syntaxe abstraite numéro I (ASN. 1).
23 0 Autres références
-
ISOKEI 8208: 1995, Technologies de l’information - Communications de données - Protocole X.25 de
couche paquet pour terminal de données.
-
Recommandation UIT-T X.25 (1993), Inteeace entre équipement terminal de traitement de données et
équipement de terminaison du circuit de données pour terminaux fonctionnant en mode paquet et
raccordés par circuit spécialisé à des réseaux publics pour données.
-
ISO 8648:1988, Systèmes de traitement de l’information - Interconnexion de systèmes ouverts -
Organisation interne de la couche Réseau.
-
ISO 9542:198g2), Systèmes de traitement de l’information - Téléinformatique - Protocole de routage d’un
système d’extrémité à un système intermédiaire à utiliser conjointement avec le protocole fournissant le
service de réseau en mode sans connexion (ISO 8473).
-
ISOKEI 10589: 1992, Technologies de 1 ‘information - Communication de données et échange
d’informations entre systèmes - Protocole intra-domaine de routage d’un système intermédiaire à un
système intermédiaire à utiliser conjointement avec le protocole fournissant le service de réseau en mode
sans connexion (ISO 8473).
-
ISOKEI 10747: 1994, Technologies de 1 ‘information - Télécommunications et échange d’informations
entre systèmes - Protocole pour échange d’informations inter-domaine de routage parmi les systèmes
intermédiaires supportant la transmission de PDU de I’ISO 8473.
0 Actuellement à l’état de projet.
2, Actuellement en révision.
2 Rec. UIT-T X.802 (1995 F)
---------------------- Page: 8 ----------------------
ISOKEI TR 13594 : 1995 (F)
Définitions
3
Définitions du modèle de référence OS1
31 0
La présente Recommandation l Rapport technique utilise les termes suivants définis dans la Rec. UIT-T X.200 I
ISOKEI 749% 1:
-
qualité de service
. Définitions du cadre général de la sécurité dans les systèmes ouverts
32
La présente Recommandation I Rapport technique utilise les termes suivants définis dans la Rec. UIT-T X.810 I
ISOKEI 10181-l:
-
domaine de sécurité
. Définitions de l’organisation interne de la couche réseau
33
La présente Recommandation l Rapport technique utilise les termes suivants définis dans ISO 8648:
a) protocole d’accès de sous-réseau;
b) système d’extrémité;
système intermédiaire.
Cl
34 . Définitions supplémentaires
Pour les besoins de la présente Recommandation I Rapport technique les définitions suivantes s’appliquent:
3.4.1 protection de réflexion: Mécanisme de protection qui détecte le renvoi d’une unité de donnée protocolaire
vers son expéditeur.
3.4.2 attributs d’association de sécurité: Collection des informations requises pour régir la sécurité des
communications entre une entité et son entité homologue.
3.4.3 association de sécurité: Relation établie entre des entités communicantes de couches inférieures pour laquelle
sont définis les attributs d’association de sécurité correspondants.
3.4.4 règles de sécurité: Information locale qui, pour les services de sécurité choisis, spécifie les mécanismes de
sécurité sous-jacents à utiliser, y compris l’ensemble des paramètres nécessaires au fonctionnement de ces mécanismes.
NOTE - Les règles de sécurité. sont une forme de règles d’interaction sûres telles que celles-ci sont définies dans le Modèle
de sécurité pour les couches supérieures (Rec. UIT-T X.803 I ISOKEI 10745).
Abréviations
4
ISN Numéro de séquence d’intégrité (integrity sequence number)
Ensemble d’attributs d’association de sécurité (set of SA-attributes)
SSAA
NLSP Protocole de sécurité de couche réseau (network layer security protocol)
NLSP-CO Protocole NLSP en mode connexion (NLSP connection mode)
NLSP-CL Protocole NLSP en mode sans connexion (NLSP connectionless mode)
Qualité de service (quality of service) (conformément à la définition de la Rec. X.200 du
QOS
CCITT I ISOKEI 7498-l)
Association de sécurité (security association)
SA
SA-ID Identificateur d’association de sécurité (security association identifier)
SNAcP Protocole d’accès de sous-réseau (subnetwork access protocol) (conformément à la définition de
ISO 8648)
SNISP Protocole indépendant de sécurité de sous-réseau (subnetwork independent security protocol)
TLSP Protocole de sécurité de couche transport (transport layer security protocol)
Rec. UIT-T X.802 (1995 F)
3
---------------------- Page: 9 ----------------------
ISOKEI TR 13594 : 1995 (F)
5 Associations de sécurité
51 . Vue d’ensemble
5.1.1 Chaque protocole de sécurité utilise un certain nombre de mécanismes de sécurité pour fournir des services de
sécurité à la couche immédiatement supérieure. Les services de sécurité nécessaires aux couches supérieures peuvent
être indiqués aux couches inférieures au moyen de fonctions locales de supervision de la sécurité. Pour établir des
communications sécurisées, le protocole de sécurité et tous les mécanismes de sécurité nécessitent un supplément
d’information par rapport à ce qui est codé dans les PDU. Il s’agira par exemple de la spécification des mécanismes à
utiliser par le protocole et, pour chaque mécanisme, d’informations spécifiques comme les clés nécessaires au mécanisme
de chiffrement. Chaque élément d’information additionnelle est connu sous le nom d’attribut d’association de sécurité.
Les attributs d’association de séc .urité peu vent : être placés dans une enti té de protocole au moyen d’un certain
5.1.2
nombre de mécanismes de positionnement. Il s’agira exemple des mécanismes suivants:
.Par
positionnement pendant la fabrication d’un dispositif;
a>
positionnement pendant l’initialisation d’un dispositif;
b)
positionnement via une interface manuelle, par exemple par les commandes des panneaux de face avant;
c)
positionnement par la gestion de sécurité des systèmes OSI;
d)
e) positionnement par la gestion de sécurite de couche OSI;
positionnement par la gestion de sécurité des opérations OSI.
5.1.3 Les attributs d’association de sécurité (SA) peuvent être positionnés à n’importe quel moment avant la
communication à laquelle ils se rapportent. Quand des ensembles compatibles d’attributs d’associations de sécurité
(SSAA) sont positionnés dans chaque entité de protocole, on dit qu’une association de sécurité existe entre ces entités.
5.1.4 Des ensembles SSAA (et des associations de sécurité) peuvent exister avec différents niveaux de granularité.
Parfois il est utile de pouvoir se référer à des ensembles SSAA de granularité différente. Par exemple, l’ensemble SSAA
défini par un ensemble convenu de règles de sécurité (ASSR) pourrait être appelé SSAA ASSR. Ou une clef appariée
pourrait être établie entre deux entités de protocole pour être employée sur un certain nombre d’instances de couples
d’adresses ayant des sources et destinations communes. De façon similaire le SSAA pour une instance de communication
pourrait être dénommé instance de communication SSAA. De même l’ensemble SSAA pour une PDU orientée
connexion pourrait être appelée SSAA CO PDU.
5.1.5 En régie générale, les attributs d’associations SA doivent être placés dans l’entité de protocole par un moyen
sécurisé afin d’en préserver la sécurité. Ceci implique que les attributs d’associations de sécurité soient positionnés par un
moyen physique sécurisé ou à l’aide d’une association de sécurité existante qui aura préalablement été positionnée a cette
fin .
5.1.6 Les ensembles d’attributs SSAA qui font partie d’une association de sécurité sont souvent désignés par un
identificateur dénommé SA-ID ayant une signification locale. A un instant donné, certains éléments de l’ensemble
d’attributs d’association de sécurité peuvent être indéfinis. Au moment de l’initialisation d’une communication sécurisée,
l’ensemble des attributs SSAA ne sera généralement pas complètement valué, et les échanges initiaux seront utilisés pour
compléter la valuation des attributs SSAA avant l’échange des données utilisateur.
5.1.7 Afin de fournir une protection de répétition, il faut appliquer des contraintes à l’usage d’identificateurs SA-ID,
leurs ensembles SSAA de référence et les attributs d’association SA.
a) Les identificateurs SA-ID ne peuvent pas être réutilisés avec la même clé de chiffrement.
b) Apres qu’un quelconque attribut SA a été valué dans un ensemble SSAA identifié par un identificateur
SA-ID, cet attribut ne pourra jamais être changé, à moins que le protocole de sécurité ne possède un
moyen de signaler le changement aux entités en communication. Ceci implique que, pour autoriser un
basculement de clé, un nouvel identificateur de SA-ID doit être utilisé avec des copies des anciens
attributs SA et une nouvelle clé, à moins que le protocole de sécurité ne dispose d’un autre moyen
de signaler le changement de clé (fonction assurée par exemple par l’unité de données protocolaires
NLSP-CO CSC).
5.1.8 Le retrait de l’un quelconque des attributs de sécurité SSAA a pour effet de clôturer l’association de sécurité.
5.1.9 Certains attributs d’association de sécurité ont une signification pour une instance de communication (une PDU
sans connexion ou une connexion). D’autres attributs d’association de sécurité ont une signification pour une seule PDU
sur une connexion. Comme exemple de tels attributs, on citera les numéros de séquence d’intégrité (ISN) et les étiquettes
de sécurité. Il peut sembler que la modification de ces attributs viole les contraintes citées au point b) du 5.1.7.
Cependant, l’association de sécurité comprenant ces attributs SA n’est logiquement valide que pour la durée de vie d’une
Rec. UIT-T X.802 (1995 F)
---------------------- Page: 10 ----------------------
ISOKEI TR 13594 : 1995 (F)
seule PDU. Le numéro ISN joue le rôle d’une extension logique de l’identificateur SA-ID, et modifie par conséquent
l’identificateur SA-ID en vigueur. L’étiquette de sécurité n’est alors valide que pour cette instance d’identificateur SA-ID
étendu. Ainsi les contraintes sont-elles respectées. De tels attributs sont parfois qualifiés de «dynamiques».
5.1.10 Une part de la politique de séçurité va imposer des contraintes aux opérations de l’entité protocolaire. Cette
partie de la politique de sécurité est appelée «ensemble de règles de sécurité pour l’entité protocolaire». Cet ensemble de
règles peut imposer des contraintes à des composants tels que le mécanisme de sécurité a utiliser ainsi que les valeurs et
le mécanisme de positionnement des attributs d’association de sécurité. L’ensemble des règles de sécurité définira aussi le
mappage des services de sécurité sélectionnés sur les mécanisme utilisés par le protocole de sécurité. L’ensemble de
règles de sécurité est une forme de règles d’interaction sécurisée.
5.1.11 Lorsqu’un tel ensemble est utilisé en exploitation intra ou inter domaines, il recevra un identificateur unique, et
cet ensemble est alors appelé «ensemble mutuellement convenu de règles de sécurité (ASSR) (agreed set of security
rules)». L’identificateur de l’ensemble ASSR peut être modifié lors de l’établissement de l’association de sécurité pour
déterminer ou contraindre l’ensemble des règles de sécurité s’appliquant à l’ensemble des attributs et qui est défini pour
l’association de sécurité. Les attributs d’association de sécurité, s’il y en a, doivent être établis en utilisant d’autres
moyens, par exemple ceux qui sont énumérés au 51.2.
52 . Etablissement d’associations de sécurité pour les couches inférieures
5.2.1 Afin de protéger une instance de communication (une SDU sans connexion ou une connexion) une association
de sécurité doit être établie entre les entités en communication.
5.2.2 L’information constitutive d’une association de sécurité est soit une information statique qui peut être
«négociée» lorsque l’association est établie et qui demeure ensuite fixe pour toute la durée de l’association, soit une
information dynamique qui peut être mise a jour au cours d’une instance de communication.
5.2.3 Une association SA peut être établie par un protocole des couches OS1 1 à 4 par l’échange d’unités de données
protocolaires (PDU) d’association de sécurité, ou par des mécanismes ne relevant pas des couches inférieures de I’OSI.
d’établir une association de sécurité, chaque entité préétabli un ensemble de règles de sécurité
5.2.4 Avant aura
commun, mutuel lement accep té et uniquemen t défini, ainsi que les ser #vices de sécurité qui peuvent être sélectionnés.
5.2.5 Si l’association de sécurité doit être établie par l’échange de PDU d’association de sécurité, alors les éléments
suivants doivent aussi être préétablis:
l de sécurité et, par mécanismes de sécurité à appliquer
une sélection initiale des services conséquent, les
a>
pendant l’établissement de l’associ .atio n de sécurité;
les informations élémentaires d’encodage nécessaires pour établir l’association de sécurité.
b)
5.2.6 A l’établissement d’une association SA, une entité détermine avec son homologue distant les in ons
partagées suivantes qui doiv ‘ent res ‘ter inchangées (c ‘est- #à-dire statiques) pour la durée de l’association:
a) les identificateurs SA-ID local et distant;
b) les services de sécurité sélectionnés pour être utilisés par les entités associées pour les instances de
communication qu’elles établissent entre elles.
NOTE - Les services de sécurité à utiliser peuvent être s6lectionnés parmi les services de shrité préétablis.
les mécanismes et leurs propriétés a utiliser en conséquence des services de sécurité sélectionnés;
C)
les clés partagées initialement pour l’intégrité, les mécanismes de chiffrement et l’authentification d’une
d)
instance de communication;
.
l’ensemble des étiquettes de sécurité et des adresses dans cette association pour
peuvent être utilisées
e>
ClUl
le contrôle d’accès.
Les identificateurs SA-ID et les clés partagées [points a) et b) ci-dessus] doivent être établis sur la base de
5.2.7
chaque association. Les autres informations peuvent être préétablies. En plus, dans l’établissement d’une association de
sécurité, l’identité du correspondant dista
...
RAPPORT
ISO/CEI
TECHNIQUE
TR 13594
Première édition
1995-l 2-15
Technologies de l’information - Modèle
de sécurité des couches inférieures
Information technology - Lower layers security
\
Numéro de référence
la
ISO/CEI TR 13594:1995(F)
---------------------- Page: 1 ----------------------
ISOKEI TR 13594: 1995(F)
Sommaire
Page
1
....................................................................................................................................
1 Domaine d’application
1
...................................................................................................................................
2 Références normatives
1
......................................................................
21 Recommandations I Normes internationales identiques
2
.......
2:2 Paires de Recommandations I Normes internationales équivalentes par leur contenu technique
2
2.3 Autres références .
3
3 Définitions .
3
.............................................................................................
3.1 Définitions du modele de réference OS1
............................................... 3
3.2 Définitions du cadre général de la sécurité dans les systèmes ouverts
................................................................... 3
Définitions de l’organisation interne de la couche reseau
33
3
314 Définitions supplémentaires .
3
Abreviations .
4
4
Associations de sécurité .
5
4
Vue d’ensemble .
51
5
................................................
5:2 Etablissement d’associations de sécurité pour les couches inférieures
6
.........................................................................................................
5.3 Clôture d’association de securite
6
...................................................................................
54 . Modification des attributs dans une connexion
7
.............................................................................................................
6 Influence sur les protocoles existants
7
61 Principe général .
7
.......................................................................................................
612 Taille d’une SDU sans connexion
7
6.3 Concaténation de PDU .
7
..............................................................................
Indépendance des algorithmes et des mécanismes
64 .
7
Structure commune de sécurite des PDU .
7
8
..................................................................................
8 Détermination des services et mécanismes de sécurité
8
.....................................................................................................................
9 Qualité de service de protection
8
...........................................................................................................................................
10 Règles de sécurité
....................................................... 8
11 Positionnement des protocoles de sécurité dans les couches inférieures
14
....................................................
Utilisation des couches (N-l) pour renforcer la sécurité de la couche (N)
12
15
.....................................................................................................................................
13 Etiquetage de sécurité
15
.....................................................................................................................................
14 Domaines de sécurité
15
.........................................................................................................................................
15 Sécurite du routage
0 ISOKEI 1995
Droits de reproduction réservés. Sauf prescription différente, aucune partie de cette publi-
cation ne peut être reproduite ni utilisée sous quelque forme que ce soit et par aucun pro-
cé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 1996
Imprimé en Suisse
ii
---------------------- Page: 2 ----------------------
ISOKEI TR 13594: 1995(F)
0 ISOKEI
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
16 Gestion de la sécurité
16
16.1 Politique de skurité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
16.2 Gestion des associations se sécurité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16.3 Gestion des clés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
16.4 Vérifications de sécurité
16
17 Confidentialité du flux de trafic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
18 Directives pour la définition des attributs d’association de sécurité
17
19 Traitement d’erreurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .~.
18
Annexe A - Exemple d’ensemble convenu de règles de sécurité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . .
111
---------------------- Page: 3 ----------------------
ISOKEI TR 13594: 1995(F)
0 ISO/CEI
Avant-propos
LIS0 (Organisation internationale de normalisation) et la CE1 (Commission
électrotechnique internationale) forment le système spécialisé de normalisation
mondiale. Les organismes nationaux membres de 1’ISO ou de la CE1 participent
au développement de 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 l’IS0 et
de la CE1 collaborent dans des domaines d’intérêt commun. D’autres organisa-
tions internationales, gouvernementales ou non gouvernementales, en liaison avec
I’ISO et la CE1 participent également aux travaux.
Dans le domaine des technologies de l’information, 1’ISO et la CE1 ont créé un
comité technique mixte, 1’ISOKEI JTC 1.
La tâche principale des comités techniques est d’élaborer les Normes interna-
tionales. Exceptionnellement, un comité technique peut proposer la publication
d’un rapport technique de l’un des types suivants:
- type 1, lorsque, en dépit de maints efforts, l’accord requis ne peut être
réalisé en faveur de la publication d’une Norme internationale;
- type 2, lorsque le sujet en question est encore en cours de développement
technique ou lorsque, pour toute autre raison, la possibilité d’un accord pour
la publication d’une Norme internationale peut être envisagée pour l’avenir
mais pas dans l’immédiat;
- type 3, lorsqu’un comité technique a réuni des données de nature différente
de celles qui sont normalement publiées comme Normes internationales
(ceci pouvant comprendre des informations sur l’état de la technique, par
exemple).
Les rapports techniques des types 1 et 2 font l’objet d’un nouvel examen trois ans
au plus tard après leur publication afin de décider éventuellement de leur transfor-
mation en Normes internationales. Les rapports techniques du type 3 ne doivent
pas nécessairement être révisés avant que les données fournies ne soient plus
jugées valables ou utiles.
L’ISOKEI TR 13594, rapport technique du type 3, a été élaboré par le comité
technique mixte ISOKEI JTC 1, Technologies de Z’information, en collabora-
tion avec I’UIT-T. Le texte identique est publié en tant que Recommandation
UIT-T X.802.
---------------------- Page: 4 ----------------------
ISOKEI TR 13594: 1995(F)
0 ISOKEI
Introduction
La présente Recommandation I Rapport technique décrit les aspects inter-couches de la fourniture des services de
sécurité dans les couches inferieures du Modele de référence OS1 (couches transport, reseau, liaison de données et
physique). Elle décrit les concepts architecturaux communs à ces couches, la base des interactions entre couches
relatives à la sécurité, et le positionnement des protocoles de sécurité dans les couches inférieures.
---------------------- Page: 5 ----------------------
Page blanche
---------------------- Page: 6 ----------------------
ISOKEI TR 13594 : 1995 (F)
RAPPORT TECHNIQUE
RECOMMANDATION UIT-T
TECHNOLOGIES DE L’INFORMATION -
MODÈLE DE SÉCURITÉ DES COUCHES INFÉRIEURES
1 Domaine d’application
La présente Recommandation I Rapport technique décrit les aspects inter-couches de la fourniture de services de sécurite
dans les couches inférieures du Modèle de réference OS1 (couches transport, réseau, liaison de données et physique).
La présente Recommandation I Rapport technique décrit:
a) les concepts architecturaux communs aux couches inférieures sur la base des éléments définis dans la
Rec. X.800 du CCITT I ISO 7498-2;
b) les bases des interactions relatives à la sécurité entre les protocoles des couches inférieures;
c) les bases de toute interaction relative à la sécurité entre couches inférieures et couches supérieures de
I’OSI;
d) le positionnement des protocoles de securité par rapport aux protocoles des inférieures
le rôle relatif de tels positionnements.
conflit entre les protocoles de sécurité des couches inferieures et le modèle décrit dans la
Il ne doit pas y avoir de
présente Recommandation I Rapport technique.
La Rec. X.500 du CCITT I ISOKEI 9594-l identifie les services de sécurité qui relèvent de chacune des couches
inférieures du Modèle de référence OSI.
2 Références normatives
Les Recommandations et les 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 Rapport technique. 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 fondes sur la présente Recommandation I Rapport technique 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-T en vigueur.
21 . Recommandations I Normes internationales identiques
-
Recommandation UIT-T X.200 (1994) I ISOKEI 749% 1: 1994, Technologies de Z’information -
Interconnexion de systèmes ouverts -Modèle de référence: Le modèle de référence de base.
-
Recommandation UIT-T X.233 (1993) l ISOKEI 8473-l : 1994, Technologies de l’information - Protocole
assurant le service réseau en mode sans connexion de l’interconnexion de systèmes ouverts: Spécifîcation
du protocole.
-
Recommandation UIT-T X.234 (1994) I ISOKEI 8602:1995, Technologies de I?nformation - Protocole
assurant le service de transport en mode sans connexion de l’interconnexion des systèmes ouverts (OU).
-
Recommandation UIT-T X.273 (1994) I ISOKEI 11577:1995, Technologies de Z’information -
Interconnexion de systèmes ouverts - Protocole de sécurité de la couche réseau.
-
Recommandation UIT-T X.274 (1994) 1 ISOKEI 10736:1995, Technologies de Z’information -
Télécommunications et échange d’informations entre systèmes - Protocole de sécurité de la couche
transport.
Rec. UIT-T X.802 (1995 F) 1
---------------------- Page: 7 ----------------------
ISOKEI TR 13594 : 1995 (F)
-
Recommandation UIT-T X.803 (1994) I ISOKEI 10745:1994, Technologies de l’information -
Interconnexion de systèmes ouverts - Modèle de sécurité pour les couches supérieures.
-
Recommandation UIT-T X.810’) I ISOKEI 10181-l. l), Technologies de 1 ‘information - Interconnexion
de systèmes ouverts - Cadre général de la sécurité dans les systèmes ouverts: Aperçu général.
-
l) Technologies de l’information - Interconnexion
Recommandation UIT-T X.812l) I ISOKEI 10181-3. ,
de systèmes ouverts - Cadre général de la sécurité dans les systèmes ouverts: Contrôle d’accès.
v
22 0 Paires de Recommandations I Normes internationales équivalentes par leur contenu technique
-
Recommandation X.800 du CCITT (1991), Architecture de sécurité pour Z’interconnexion en systèmes
ouverts d’applications du CCITT.
ISO 7498-2: 1989, Systèmes de traitement de l’information - Interconnexion de systèmes ouverts - Modèle
de référence de base. Partie 2 - Architecture de sécurité.
-
Recommandation UIT-T X.224 (1993), Protocole pour assurer le service de couche transport en mode
connexion pour 1 ‘interconnexion de systèmes ouverts.
ISOKEI 8073: 1992, Technologies de 1 ‘information - Télécommunications et échanges d’informations
Protocole pour fourniture du service de
entre systèmes - Interconnexion de systèmes ouverts (OSI) -
transport en mode connexion.
-
Recommandation X.208 du CCITT (1988), Spécijkation de la syntaxe abstraite numéro un (ASN. I).
ISOKEI 8824: 1990, Technologies de 1 ‘information - Interconnexion de systèmes ouverts (OSI) -
Spécification de la notation de syntaxe abstraite numéro 1 (ASN. I).
-
Recommandation X.209 du CCITT (1988), Spécifkation des règles de codage de base pour la notation
de syntaxe abstraite numéro un (ASN. 1).
Interconnexion de systèmes ouverts - Spécification
ISOKEI 8825: 1990, Technologies de 1 ‘information -
de règles de base pour coder la notation de syntaxe abstraite numéro I (ASN. 1).
23 0 Autres références
-
ISOKEI 8208: 1995, Technologies de l’information - Communications de données - Protocole X.25 de
couche paquet pour terminal de données.
-
Recommandation UIT-T X.25 (1993), Inteeace entre équipement terminal de traitement de données et
équipement de terminaison du circuit de données pour terminaux fonctionnant en mode paquet et
raccordés par circuit spécialisé à des réseaux publics pour données.
-
ISO 8648:1988, Systèmes de traitement de l’information - Interconnexion de systèmes ouverts -
Organisation interne de la couche Réseau.
-
ISO 9542:198g2), Systèmes de traitement de l’information - Téléinformatique - Protocole de routage d’un
système d’extrémité à un système intermédiaire à utiliser conjointement avec le protocole fournissant le
service de réseau en mode sans connexion (ISO 8473).
-
ISOKEI 10589: 1992, Technologies de 1 ‘information - Communication de données et échange
d’informations entre systèmes - Protocole intra-domaine de routage d’un système intermédiaire à un
système intermédiaire à utiliser conjointement avec le protocole fournissant le service de réseau en mode
sans connexion (ISO 8473).
-
ISOKEI 10747: 1994, Technologies de 1 ‘information - Télécommunications et échange d’informations
entre systèmes - Protocole pour échange d’informations inter-domaine de routage parmi les systèmes
intermédiaires supportant la transmission de PDU de I’ISO 8473.
0 Actuellement à l’état de projet.
2, Actuellement en révision.
2 Rec. UIT-T X.802 (1995 F)
---------------------- Page: 8 ----------------------
ISOKEI TR 13594 : 1995 (F)
Définitions
3
Définitions du modèle de référence OS1
31 0
La présente Recommandation l Rapport technique utilise les termes suivants définis dans la Rec. UIT-T X.200 I
ISOKEI 749% 1:
-
qualité de service
. Définitions du cadre général de la sécurité dans les systèmes ouverts
32
La présente Recommandation I Rapport technique utilise les termes suivants définis dans la Rec. UIT-T X.810 I
ISOKEI 10181-l:
-
domaine de sécurité
. Définitions de l’organisation interne de la couche réseau
33
La présente Recommandation l Rapport technique utilise les termes suivants définis dans ISO 8648:
a) protocole d’accès de sous-réseau;
b) système d’extrémité;
système intermédiaire.
Cl
34 . Définitions supplémentaires
Pour les besoins de la présente Recommandation I Rapport technique les définitions suivantes s’appliquent:
3.4.1 protection de réflexion: Mécanisme de protection qui détecte le renvoi d’une unité de donnée protocolaire
vers son expéditeur.
3.4.2 attributs d’association de sécurité: Collection des informations requises pour régir la sécurité des
communications entre une entité et son entité homologue.
3.4.3 association de sécurité: Relation établie entre des entités communicantes de couches inférieures pour laquelle
sont définis les attributs d’association de sécurité correspondants.
3.4.4 règles de sécurité: Information locale qui, pour les services de sécurité choisis, spécifie les mécanismes de
sécurité sous-jacents à utiliser, y compris l’ensemble des paramètres nécessaires au fonctionnement de ces mécanismes.
NOTE - Les règles de sécurité. sont une forme de règles d’interaction sûres telles que celles-ci sont définies dans le Modèle
de sécurité pour les couches supérieures (Rec. UIT-T X.803 I ISOKEI 10745).
Abréviations
4
ISN Numéro de séquence d’intégrité (integrity sequence number)
Ensemble d’attributs d’association de sécurité (set of SA-attributes)
SSAA
NLSP Protocole de sécurité de couche réseau (network layer security protocol)
NLSP-CO Protocole NLSP en mode connexion (NLSP connection mode)
NLSP-CL Protocole NLSP en mode sans connexion (NLSP connectionless mode)
Qualité de service (quality of service) (conformément à la définition de la Rec. X.200 du
QOS
CCITT I ISOKEI 7498-l)
Association de sécurité (security association)
SA
SA-ID Identificateur d’association de sécurité (security association identifier)
SNAcP Protocole d’accès de sous-réseau (subnetwork access protocol) (conformément à la définition de
ISO 8648)
SNISP Protocole indépendant de sécurité de sous-réseau (subnetwork independent security protocol)
TLSP Protocole de sécurité de couche transport (transport layer security protocol)
Rec. UIT-T X.802 (1995 F)
3
---------------------- Page: 9 ----------------------
ISOKEI TR 13594 : 1995 (F)
5 Associations de sécurité
51 . Vue d’ensemble
5.1.1 Chaque protocole de sécurité utilise un certain nombre de mécanismes de sécurité pour fournir des services de
sécurité à la couche immédiatement supérieure. Les services de sécurité nécessaires aux couches supérieures peuvent
être indiqués aux couches inférieures au moyen de fonctions locales de supervision de la sécurité. Pour établir des
communications sécurisées, le protocole de sécurité et tous les mécanismes de sécurité nécessitent un supplément
d’information par rapport à ce qui est codé dans les PDU. Il s’agira par exemple de la spécification des mécanismes à
utiliser par le protocole et, pour chaque mécanisme, d’informations spécifiques comme les clés nécessaires au mécanisme
de chiffrement. Chaque élément d’information additionnelle est connu sous le nom d’attribut d’association de sécurité.
Les attributs d’association de séc .urité peu vent : être placés dans une enti té de protocole au moyen d’un certain
5.1.2
nombre de mécanismes de positionnement. Il s’agira exemple des mécanismes suivants:
.Par
positionnement pendant la fabrication d’un dispositif;
a>
positionnement pendant l’initialisation d’un dispositif;
b)
positionnement via une interface manuelle, par exemple par les commandes des panneaux de face avant;
c)
positionnement par la gestion de sécurité des systèmes OSI;
d)
e) positionnement par la gestion de sécurite de couche OSI;
positionnement par la gestion de sécurité des opérations OSI.
5.1.3 Les attributs d’association de sécurité (SA) peuvent être positionnés à n’importe quel moment avant la
communication à laquelle ils se rapportent. Quand des ensembles compatibles d’attributs d’associations de sécurité
(SSAA) sont positionnés dans chaque entité de protocole, on dit qu’une association de sécurité existe entre ces entités.
5.1.4 Des ensembles SSAA (et des associations de sécurité) peuvent exister avec différents niveaux de granularité.
Parfois il est utile de pouvoir se référer à des ensembles SSAA de granularité différente. Par exemple, l’ensemble SSAA
défini par un ensemble convenu de règles de sécurité (ASSR) pourrait être appelé SSAA ASSR. Ou une clef appariée
pourrait être établie entre deux entités de protocole pour être employée sur un certain nombre d’instances de couples
d’adresses ayant des sources et destinations communes. De façon similaire le SSAA pour une instance de communication
pourrait être dénommé instance de communication SSAA. De même l’ensemble SSAA pour une PDU orientée
connexion pourrait être appelée SSAA CO PDU.
5.1.5 En régie générale, les attributs d’associations SA doivent être placés dans l’entité de protocole par un moyen
sécurisé afin d’en préserver la sécurité. Ceci implique que les attributs d’associations de sécurité soient positionnés par un
moyen physique sécurisé ou à l’aide d’une association de sécurité existante qui aura préalablement été positionnée a cette
fin .
5.1.6 Les ensembles d’attributs SSAA qui font partie d’une association de sécurité sont souvent désignés par un
identificateur dénommé SA-ID ayant une signification locale. A un instant donné, certains éléments de l’ensemble
d’attributs d’association de sécurité peuvent être indéfinis. Au moment de l’initialisation d’une communication sécurisée,
l’ensemble des attributs SSAA ne sera généralement pas complètement valué, et les échanges initiaux seront utilisés pour
compléter la valuation des attributs SSAA avant l’échange des données utilisateur.
5.1.7 Afin de fournir une protection de répétition, il faut appliquer des contraintes à l’usage d’identificateurs SA-ID,
leurs ensembles SSAA de référence et les attributs d’association SA.
a) Les identificateurs SA-ID ne peuvent pas être réutilisés avec la même clé de chiffrement.
b) Apres qu’un quelconque attribut SA a été valué dans un ensemble SSAA identifié par un identificateur
SA-ID, cet attribut ne pourra jamais être changé, à moins que le protocole de sécurité ne possède un
moyen de signaler le changement aux entités en communication. Ceci implique que, pour autoriser un
basculement de clé, un nouvel identificateur de SA-ID doit être utilisé avec des copies des anciens
attributs SA et une nouvelle clé, à moins que le protocole de sécurité ne dispose d’un autre moyen
de signaler le changement de clé (fonction assurée par exemple par l’unité de données protocolaires
NLSP-CO CSC).
5.1.8 Le retrait de l’un quelconque des attributs de sécurité SSAA a pour effet de clôturer l’association de sécurité.
5.1.9 Certains attributs d’association de sécurité ont une signification pour une instance de communication (une PDU
sans connexion ou une connexion). D’autres attributs d’association de sécurité ont une signification pour une seule PDU
sur une connexion. Comme exemple de tels attributs, on citera les numéros de séquence d’intégrité (ISN) et les étiquettes
de sécurité. Il peut sembler que la modification de ces attributs viole les contraintes citées au point b) du 5.1.7.
Cependant, l’association de sécurité comprenant ces attributs SA n’est logiquement valide que pour la durée de vie d’une
Rec. UIT-T X.802 (1995 F)
---------------------- Page: 10 ----------------------
ISOKEI TR 13594 : 1995 (F)
seule PDU. Le numéro ISN joue le rôle d’une extension logique de l’identificateur SA-ID, et modifie par conséquent
l’identificateur SA-ID en vigueur. L’étiquette de sécurité n’est alors valide que pour cette instance d’identificateur SA-ID
étendu. Ainsi les contraintes sont-elles respectées. De tels attributs sont parfois qualifiés de «dynamiques».
5.1.10 Une part de la politique de séçurité va imposer des contraintes aux opérations de l’entité protocolaire. Cette
partie de la politique de sécurité est appelée «ensemble de règles de sécurité pour l’entité protocolaire». Cet ensemble de
règles peut imposer des contraintes à des composants tels que le mécanisme de sécurité a utiliser ainsi que les valeurs et
le mécanisme de positionnement des attributs d’association de sécurité. L’ensemble des règles de sécurité définira aussi le
mappage des services de sécurité sélectionnés sur les mécanisme utilisés par le protocole de sécurité. L’ensemble de
règles de sécurité est une forme de règles d’interaction sécurisée.
5.1.11 Lorsqu’un tel ensemble est utilisé en exploitation intra ou inter domaines, il recevra un identificateur unique, et
cet ensemble est alors appelé «ensemble mutuellement convenu de règles de sécurité (ASSR) (agreed set of security
rules)». L’identificateur de l’ensemble ASSR peut être modifié lors de l’établissement de l’association de sécurité pour
déterminer ou contraindre l’ensemble des règles de sécurité s’appliquant à l’ensemble des attributs et qui est défini pour
l’association de sécurité. Les attributs d’association de sécurité, s’il y en a, doivent être établis en utilisant d’autres
moyens, par exemple ceux qui sont énumérés au 51.2.
52 . Etablissement d’associations de sécurité pour les couches inférieures
5.2.1 Afin de protéger une instance de communication (une SDU sans connexion ou une connexion) une association
de sécurité doit être établie entre les entités en communication.
5.2.2 L’information constitutive d’une association de sécurité est soit une information statique qui peut être
«négociée» lorsque l’association est établie et qui demeure ensuite fixe pour toute la durée de l’association, soit une
information dynamique qui peut être mise a jour au cours d’une instance de communication.
5.2.3 Une association SA peut être établie par un protocole des couches OS1 1 à 4 par l’échange d’unités de données
protocolaires (PDU) d’association de sécurité, ou par des mécanismes ne relevant pas des couches inférieures de I’OSI.
d’établir une association de sécurité, chaque entité préétabli un ensemble de règles de sécurité
5.2.4 Avant aura
commun, mutuel lement accep té et uniquemen t défini, ainsi que les ser #vices de sécurité qui peuvent être sélectionnés.
5.2.5 Si l’association de sécurité doit être établie par l’échange de PDU d’association de sécurité, alors les éléments
suivants doivent aussi être préétablis:
l de sécurité et, par mécanismes de sécurité à appliquer
une sélection initiale des services conséquent, les
a>
pendant l’établissement de l’associ .atio n de sécurité;
les informations élémentaires d’encodage nécessaires pour établir l’association de sécurité.
b)
5.2.6 A l’établissement d’une association SA, une entité détermine avec son homologue distant les in ons
partagées suivantes qui doiv ‘ent res ‘ter inchangées (c ‘est- #à-dire statiques) pour la durée de l’association:
a) les identificateurs SA-ID local et distant;
b) les services de sécurité sélectionnés pour être utilisés par les entités associées pour les instances de
communication qu’elles établissent entre elles.
NOTE - Les services de sécurité à utiliser peuvent être s6lectionnés parmi les services de shrité préétablis.
les mécanismes et leurs propriétés a utiliser en conséquence des services de sécurité sélectionnés;
C)
les clés partagées initialement pour l’intégrité, les mécanismes de chiffrement et l’authentification d’une
d)
instance de communication;
.
l’ensemble des étiquettes de sécurité et des adresses dans cette association pour
peuvent être utilisées
e>
ClUl
le contrôle d’accès.
Les identificateurs SA-ID et les clés partagées [points a) et b) ci-dessus] doivent être établis sur la base de
5.2.7
chaque association. Les autres informations peuvent être préétablies. En plus, dans l’établissement d’une association de
sécurité, l’identité du correspondant dista
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.