Authorized licensed use limited to: UCLA Library. Downloaded on January 19,2016 at 18:54:06 UTC from IEEE Xplore. Restrictions apply.
`
`000001
`
`VIASAT 1009
`IPR of U.S. Pat. No. 5,960,074
`
`

`
`THIS PAGE WAS
`BLANK IN THE ORIGINAL
`
`Authorized licensed use limited to: UCLA Library. Downloaded on January 19,2016 at 18:54:06 UTC from IEEE Xplore. Restrictions apply.
`
`000002
`
`

`
`IEEE Std 802.10-1992
`(Includes IEEE Std 802.10b-1992)
`
`IEEE Standards for Local and
`Metropolitan Area Networks:
`
`Interoperable LAN/MAN Security
`(SILS)
`
`Currently Contains
`Secure Data Exchange (SDE) (Clause 2)
`
`Sponsor
`Technical Committee on Security and Privacy and
`Technical Committee on Computer Communications
`of the
`IEEE Computer Society
`
`Approved September 17, 1992
`IEEE Standards Board
`
`Abstract: A security protocol that can be used to protect IEEE 802 Local Area Networks (LANs)
`and Metropolitan Area Networks (MANS) is described. This Open Systems Interconnection (09)
`Layer 2 security protocol can be used to provide the security services of confidentiality and connec-
`tionless integrity. In conjunction with key management or system management, the security servic-
`es of data origin authentication and access control may also be provided.
`Keywords: decipherment; encipherment; local area networks, security; metropolitan area net-
`works, secure data exchange; security; security association
`
`The Institute of Electrical and Electronics Engineers, Inc.
`345 East 47th Street, New York, NY 10017-2394, USA
`
`Copyright 0 1993 by the Institute of Electrical and Electronics Engineers, Inc.
`All rights reserved. Published 1993. Printed in the United States of America
`
`ISBN 1-55937-254-0
`No part of this publication may be reproduced in any form, in an electronic retrieval system or otherwise, without the prior
`written permission of the publisher.
`
`Authorized licensed use limited to: UCLA Library. Downloaded on January 19,2016 at 18:54:06 UTC from IEEE Xplore. Restrictions apply.
`
`000003
`
`

`
`IEEE Standards documents are developed within the Technical Committees of
`the IEEE Societies and the Standards Coordinating Committees of the IEEE Stan-
`dards Board. Members of the committees serve voluntarily and without compensa-
`tion. They are not necessarily members of the Institute. The standards developed
`within IEEE represent a consensus of the broad expertise on the subject within the
`Institute as well as those activities outside of IEEE that have expressed an interest in
`participating in the development of the standard.
`Use of an IEEE Standard is wholly voluntary. The existence of an IEEE Standard
`does not imply that there are no other ways to produce, test, measure, purchase, mar-
`ket, or provide other goods and services related to the scope of the IEEE Standard.
`Furthermore, the viewpoint expressed at the time a standard is approved and issued is
`subject to change brought about through developments in the state of the art and
`comments received from users of the standard. Every IEEE Standard is subjected to
`review at least every five years for revision or reaffirmation. When a document is
`more than five years old and has not been reaffirmed, it is reasonable to conclude that
`its contents, although still of some value, do not wholly reflect the present state of the
`art. Users are cautioned to check to determine that they have the latest edition of any
`IEEE Standard.
`Comments for revision of IEEE Standards are welcome from any interested party,
`regardless of membership affiliation with IEEE. Suggestions for changes in docu-
`ments should be in the form of a proposed change of text, together with appropriate
`supporting comments.
`Interpretations: Occasionally questions may arise regarding the meaning of por-
`tions of standards as they relate to specific applications. When the need for interpreta-
`tions is brought to the attention of IEEE, the Institute will initiate action to prepare
`appropriate responses. Since IEEE Standards represent a consensus of all concerned
`interests, it is important to ensure that any interpretation has also received the concur-
`rence of a balance of interests. For this reason IEEE and the members of its technical
`committees are not able to provide an instant response to interpretation requests
`except in those cases where the matter has previously received formal consideration.
`Comments on standards and requests for interpretations should be addressed to:
`
`Secretary, IEEE Standards Board
`445 Hoes Lane
`P.O. Box 1331
`Piscataway, NJ 08855-1331
`USA
`
`IEEE Standards documents are adopted by the Institute of Electrical and Electron-
`ics Engineers without regard to whether their adoption may involve patents on arti-
`cles, materials, or processes. Such adoption does not assume any liability to any
`patent owner, nor does it assume any obligation whatever to parties adopting the
`standards documents.
`
`Authorized licensed use limited to: UCLA Library. Downloaded on January 19,2016 at 18:54:06 UTC from IEEE Xplore. Restrictions apply.
`
`000004
`
`

`
`Introduction
`
`(This introduction is not a part of IEEE Std 802.10-1992, IEEE Standards for Local and Metropolitan Area Networks: Interoperable
`LANMAN Security (SILS).)
`
`This standard is part of a family of standards for local and metropolitan area networks. The relationship
`between the standard and other members of the family is shown below. (The numbers in the figure refer to
`IEEE standard numbers.)
`
`N
`
`1
`
`802.2 LOGICAL LINK
`
`802.1 BRIDGING
`
`DATA
`LINK
`LAYER
`
`PHYSICAL
`
`* Formerly IEEE Std 802.1A
`
`This family of standards deals with the Physical and Data Link Layers as defined by the IS0 Open Systems
`Interconnection Basic Reference Model (IS0 7498 : 1984). The access standards define several types of
`medium access technologies and associated physical media, each appropriate for particular applications or
`system objectives. Other types are under investigation.
`
`The standards defining these technologies are as follows:
`
`IEEE Std 802*:
`
`IEEE Std 802.1D:
`
`IEEE Std 802.1E:
`
`Overview and Architecture. This standard provides an over-
`view to the family of IEEE 802 Standards. This document
`forms part of the 802.1 scope of work.
`
`MAC Bridging. Specifies an architecture and protocol for the
`interconnection of IEEE 802 LANs below the MAC service
`boundary.
`
`System Load Protocol. Specifies a set of services and protocol
`for those aspects of management concerned with the loading of
`systems on IEEE 802 LANs.
`
`IS0 8802-2 [ANSVIEEE Std 802.21:
`
`Logical Link Control
`
`ISO/IEC 8802-3 [ANSVIEEE Std 802.31: CSMNCD Access Method and Physical Layer Specifications
`
`ISO/IEC 8802-4 [ANSVIEEE Std 802.41: Token Bus Access Method and Physical Layer Specifications
`
`'The 802 Architecture and Overview Specification, originally known as IEEE Std 802.1A. has been renumbered as IEEE Std 802. This
`has been done to accommodate recognition of the base standard in a family of standards. References to IEEE Std 802.1A should be
`considered as references to IEEE Std 802.
`
`...
`111
`
`Authorized licensed use limited to: UCLA Library. Downloaded on January 19,2016 at 18:54:06 UTC from IEEE Xplore. Restrictions apply.
`
`000005
`
`

`
`ISOAEC 8802-5 [ANSMEEE Std 802.51: Token Ring Access Method and Physical Layer Specifications
`
`IEEE Std 802.6:
`
`IEEE Std 802.10:
`
`Metropolitan Area Network Access Method and Physical
`Layer Specifications
`
`Data
`Interoperable LAN/MAN Security (S1LS)-Secure
`Exchange (SDE) [Currently contains Secure Data Exchange
`(Clause 2)]
`
`In addition to the family of standards, the following is a recommended practice for a common technology:
`
`IEEE Std 802.7:
`
`IEEE Recommended Practice for Broadband Local Area Net-
`works
`
`Conformance Test Methodology
`
`An additional standards series, identified by the number 1802, has been established to identify the conform-
`ance test methodology documents for the 802 family of standards. This makes the correspondence between
`the various 802 standards and their applicable conformance test requirements readily apparent. Thus the
`conformance test documents for 802.3 are numbered 1802.3, the conformance test documents for 802.5 will
`be 1802.5, and so on.
`
`802.1 0-1 992
`
`The IEEE 802.10 LAN Security Working Group was formed in May of 1988 to address the security of Local
`Area Networks (LANs) and Metropolitan Area Networks (MANs). It is co-sponsored by IEEE 802 and by
`the IEEE Technical Committee on Security and Privacy. The committee has representation from vendors,
`government, and users. IEEE Std 802.10 is intended to provide a standard to address security for LANs and
`MANs. The standard is an interoperability standard that is compatible with the existing IEEE 802 and OS1
`architectures. This volume, which includes Secure Data Exchange (SDE), is the first clause to be completed.
`Additional clauses and subclauses will be published as supplements and folded into the base document
`(IEEE Std 802.10) at the appropriate time.
`
`Data networks, especially LANs and MANs, have become widespread. LANs and MANS are used by both
`industry and government for transfemng vast amounts of information in the course of daily operations.
`Because of their ever-increasing use in the private and public sectors, the capabilities of these networks are
`being expanded to encompass more and more performance requirements. As a result, there is the growing
`need to standardize network protocols wherever feasible, to ensure that data networks will interoperate
`effectively.
`
`As standardization practices evolve, several key areas will become critically important. One of these areas is
`network security. Many LANs and MANS require the capability to exchange data in a secure manner. This is
`especially important in cases where disclosure of operational information to unauthorized parties would
`severely undermine an organization’s effectiveness. It is often as critical to protect the integrity of the data as
`it is to prevent disclosure of operating information.
`
`Financial and government institutions have traditionally been most aware of the importance of security.
`However, recent widely publicized cases of computer fraud and related crimes have made security a goal for
`many other industries as well. As the need for security on LANs and MANS gains recognition, the need for a
`standardized approach to providing such a capability also becomes a priority. Much security standardization
`has already been started. Where applicable, this standard attempts to incorporate this work.
`
`iv
`
`Authorized licensed use limited to: UCLA Library. Downloaded on January 19,2016 at 18:54:06 UTC from IEEE Xplore. Restrictions apply.
`
`000006
`
`

`
`Participants
`
`A t the time this standard was completed, the 802.10 LANMAN Security Working Group had the following
`membership:
`
`Kenneth G. Alonge, Chair (1991 to present)
`Kimberly Kirkpatrick, Chair (1988-1991)
`Russell Housley, Vice Chair
`L. Kirk Barker, Technical Editor
`Peter Yee, Recording Secretary
`Alan Amdt
`Paul Lambert
`James Pyles
`Kurt Augustine
`Warren Loper
`James Randall
`Bill Bimbaum
`Eugene Reilly
`Wen-Pai Lu
`Ben Bratcher
`Brian Schanning
`Marc Mandel
`Ronald Gibson
`James Sutherland
`Ken McCoy
`Jon Graff
`Kenta Takumi
`Esther Murphy
`Tom Hunwick
`Lloyd Taylor
`Richard Parker
`Robert Kolacki
`Brian Phillips
`Joseph Williamson
`
`The following individuals also contributed review and comments:
`
`Morrie Gasser
`B.J. Herbison
`Lawrence Kilgallen
`
`John Kimmins
`Scott Lawrence
`Larry Lunsford
`
`C.E. Reaver
`Jim Sanders
`Mitch Tannenbaum
`
`The following persons were o n the balloting committee that approved this document for submission to the
`IEEE Standards Board:
`W. B. Adam
`I. F. Akyildiz
`P. Angarano
`Y. M. Baeg
`M. R. Balomiri
`T. Batten
`J. 0. Bondi
`C. E. Bouldin
`M. A. Branstad
`A. L. Bridges
`D. W. Browne
`R. Caasi
`A. L. Carrato
`A. Castaldo
`K. J. Cooper
`S . J. Covington
`R. S. Crowder
`E. A. Czarcinski
`A. M. De Alvar6
`R. Diaz
`W. C. Dube
`A. M. Dunn
`S. K. Dutta
`T. Dzik
`J. Ellis
`P. H. Enslow, Jr.
`S. A. Faviell
`J. W. Fendrich
`C. A. Finseth
`H. A. Freeman
`G. Fullerton
`R. Gagliano
`M. Gasser
`C . G. Girling
`P. Gonia
`
`H. K. Gorowara
`J. Gaff
`M. Greer
`R. M. Gross
`A. Grund
`D. Hardie
`C. M. Hay
`L. A. Hollaar
`G. L. Hollander
`R. D. Housley
`G. J. Huey
`W. J. Hunteman
`T. R. Hunwick
`B. Iggland
`T. J. Jasinski
`R. Juvonen
`K. C. Kelley
`G. C. Kessler
`F. Khatibi
`K. Kirkpatrick
`T. Korelsky
`P. Kornerup
`M. D. Krenzin
`K. Kung
`C. A. LaBarge
`L. M. Lam
`L. M. Leach
`M. E. Lee
`E. V. Leighninger
`W. A. Levy
`E. Liebman
`P. Lin
`J. Litchfield
`W. E. Loper
`w. Lu
`
`A. J. Luque
`G. Q. Maguire
`E. G. Marmol
`P. Martini
`C. McDonald
`W. C. McDonald
`G. McWilliams
`R. J. Melford
`A. Miller
`R. H. Miller
`D. S. Millman
`R. R. Moeller
`T. Mookken
`D. J. Morris
`C. E. Neblock
`R. Nelson
`D. M. Nessett
`C. Neuman
`D. O’Mahony
`E. Okamoto
`S. A. Orrell
`A. Pfitzmann
`T. E. Phillips
`T. L. Phinney
`R. L. Phipps
`A. J. Pina
`U. W. Pooch
`V. Prabhu
`Y. Qianli
`R. Ramaswamy
`E. J. Reilly
`T. E. Revello
`A. B. Richstein
`C. J. Riddick
`R. Rosenthal
`
`V
`
`Authorized licensed use limited to: UCLA Library. Downloaded on January 19,2016 at 18:54:06 UTC from IEEE Xplore. Restrictions apply.
`
`000007
`
`

`
`V. Rozentouler
`J. W. Rub
`R. A. Rueppel
`C. Ruland
`D. J. Rypka
`E. R. Schallenmuller
`B. P. Schanning
`R. R. Schell
`N. Schneidewind
`J. R. Schwab
`B. Sklar
`D. Snow
`H. P. Solomon
`
`J. Stevenson
`B. J. Stoppe
`E. Sullivan
`E. D. Sykas
`H. Tang
`B. J. Tarbox
`L. W. Taylor
`P. Thaler
`J. C. Thomas
`D. M. Topkis
`B. Tretick
`R. C. Tripi
`G. Tsudik
`D. B. Turner
`
`R. Van Houtte
`J. Vandewalle
`J. T. Vorhies
`B. Vornbrock
`S. T. Walker
`R. K. Walker
`R. Wenig
`W. J. Wenker
`J . A. West
`G. B. Wright
`J. Yang
`P. Yee
`0. Yuen
`
`When the IEEE Standards Board approved this standard on September 17, 1992, it had the following mem-
`bership:
`
`Donald C. Loughry, Vice Chair
`Marco W. Migliaro, Chair
`Andrew G. Salem, Secretary
`Donald N. Heirman
`Ben C. Johnson
`Walter J. Karplus
`Ivor N. Knight
`Joseph Koepfinger*
`Irving Kolodny
`D. N. “Jim” Logothetis
`Lawrence V. McCall
`
`T. Don Michael*
`John L. Rankine
`Wallace S. Read
`Ronald H. Reimer
`Gary S. Robinson
`Martin V. Schneider
`Terrance R. Whittemore
`Donald W. Zipse
`
`Dennis Bodson
`Paul L. Borrill
`Clyde Camp
`Donald C. Fleckenstein
`Jay Forster*
`David E Franklin
`Ramiro Garcia
`Thomas L. Hannan
`
`*Member Emeritus
`
`Also included are the following IEEE Standards Board liaisons:
`
`Satish K. Aggarwal
`James Beall
`Richard B. Engelman
`David E. Soffrin
`Stanley Warshaw
`
`Kristin M. Dittmann
`IEEE Standards Pmject Editor
`
`vi
`
`Authorized licensed use limited to: UCLA Library. Downloaded on January 19,2016 at 18:54:06 UTC from IEEE Xplore. Restrictions apply.
`
`000008
`
`

`
`Contents
`
`CLAUSE
`
`PAGE
`
`1 . Overview and model ............................................................................................................................
`
`1
`
`1.1 Scope and purpose .........................
`1.2 Acronyms and definitions ...................................
`1.3 References ............................................................
`1.4 Architecture .....................................
`
`...................................................
`1
`.......................................................
`1
`...................................................
`5
`............................................................................ 6
`
`2 . Secure Data Exchange (SDE) ..............................................................................................................
`
`7
`
`2.1 Overview
`
`.............................................................................................
`7
`........................................................................ 8
`
`2.5 SDE PDU structure ....................................................................
`2.6 SDE procedure .....................................................
`2.7 Minimum Essential Requirements (MERs) ...............................
`2.8 SDE sublayer management .....................................................................
`
`...................................
`
`11
`
`3 . Key management ............................................................................................................................... 24
`
`4 . Security management .........................................................................................................................
`
`24
`
`5 . Bibliography ...................................................................................................................................... 25
`
`FIGURES
`
`Figure 2- 1
`Figure 2-2
`Figure 2-3
`Figure 2-4
`Figure 2-5
`Figure 2-6
`Figure 2-7
`Figure 2-8
`Figure 2-9
`Figure 2- 10
`Figure 2- 1 1
`Figure 2- 12
`
`Relationship to IEEE 802 reference model ........................................................................
`7
`SDE primitives .................................................................................................................
`10
`Structure of the SDE PDU ...............................................................................................
`11
`Clear Header ....................................................................................................................
`12
`SAID format ..................................................................................................................... 12
`Construction of the SDE PDU .........................................................................................
`14
`SDE management architecture .........................................................................................
`15
`Initial exchange ................................................................................................................
`16
`Example SMIB containing security associations .............................................................
`16
`Parameters used for selecting security association ..........................................................
`16
`Transmission of an MA-UNITDATA.request ................................................................
`19
`Reception of an MA-UNITDATA.indication ................................................................. 22
`
`TABLE
`
`Figure 2- 1
`
`Security service dependencies ...........................................................................................
`
`9
`
`ANNEXES
`
`2A . Service rationale ................................................................................................................................. 27
`............................................................................................................................
`2B . Example .....
`37
`2C . Objectives of SDE .............
`..................................................................................................
`43
`2D . Rationale for placement ....
`....................................................................................................
`44
`2E . Fragmentation ...................
`..................................................................................................
`48
`
`..
`
`vii
`
`Authorized licensed use limited to: UCLA Library. Downloaded on January 19,2016 at 18:54:06 UTC from IEEE Xplore. Restrictions apply.
`
`000009
`
`

`
`THIS PAGE WAS
`BLANK IN THE ORIGINAL
`
`Authorized licensed use limited to: UCLA Library. Downloaded on January 19,2016 at 18:54:06 UTC from IEEE Xplore. Restrictions apply.
`
`000010
`
`

`
`IEEE Standards for Local and Metropolitan Area
`Networks: Interoperable LAN/MAN Security (SILS)
`
`Currently Contains
`Secure Data Exchange (SDE) (Clause 2)
`
`1. Overview and model
`
`1.1 Scope and purpose
`
`This standard was developed to provide security in IEEE 802 Local Area Networks (LANs) and Metropoli-
`tan Area Networks (MANs).
`
`The model for providing security services is described in clause 1. A Secure Data Exchange (SDE) protocol
`for IEEE 802 LANs and MANs is defined in clause 2. Key management and systedsecurity management in
`IEEE 802 LANs and MANs are described in clauses 3 and 4. While SDE is independent of any key manage-
`ment or system management implementation, the security services described in this standard depend on
`management information provided by management entities.
`
`1.2 Acronyms and definitions
`
`1.2.1 Acronyms
`
`This subclause contains acronyms that are applicable to all clauses of the standard.
`
`CMIP
`DA
`DEA
`DSAP
`ICV
`IV
`LAN
`LM
`LLC
`LSAP
`MAC
`MAN
`MDF
`MER
`MU3
`MSDU
`os1
`PDU
`
`Common Management Information Protocol
`Destination Address
`Data Encryption Algorithm
`Destination Service Access Point
`Integrity Check Value
`Initialization Vector
`Local Area Network
`Layer Manager
`Logical Link Control
`Link Service Access Point
`Medium Access Control
`Metropolitan Area Network
`Management-Defined Field
`Minimum Essential Requirements
`Management Information Base
`MAC Service Data Unit
`Open Systems Interconnection
`Protocol Data Unit
`
`1
`
`Authorized licensed use limited to: UCLA Library. Downloaded on January 19,2016 at 18:54:06 UTC from IEEE Xplore. Restrictions apply.
`
`000011
`
`

`
`IEEE
`Std 802.10-1992
`
`IEEE STANDARDS FOR LOCAL AND METROPOLITAN AREA NETWORKS:
`
`SA
`SAID
`S A P
`SDE
`SDU
`SILS
`SMAE
`SMIB
`S S A P
`TCB
`
`Source Address
`Security Association Identifier
`Service Access Point
`Secure Data Exchange
`Service Data Unit
`Standard for Interoperable LAN Security
`System Management Application Entity
`Security Management Information Base
`Source Service Access Point
`Trusted Computing Base
`
`1.2.2 Definitions
`
`This subclause contains the definitions that are applicable to all clauses of this standard. Sources for the def-
`initions are indicated. When no source is indicated, this standard is the source.
`
`1.2.2.1 access control: The prevention of unauthorized use of a resource, including the prevention of use of
`a resource in an unauthorized manner. (IS0 7498-2 : 1989l)
`
`1.2.2.2 attribute: A property of a managed object or a property of an association among OS1 entities. An
`attribute has an associated value, which may have a simple or complex structure. (ISOAEC 10040 : 1992)
`
`1.2.2.3 authentication: See: data origin authentication; peer entity authentication. Note: In this stan-
`dard, the term “authentication” is not used in connection with data integrity; the term “data integrity” is used
`instead.
`
`1.2.2.4 bootstrap SAID. Four SAID values are reserved for the purpose of establishing initial communica-
`tion with key management or system management when an SAID has not already been negotiated. These
`SAID values are called “bootstrap” SAIDs and have a preestablished security association.
`
`1.2.2.5 ciphertext: Data produced through the use of encipherment, the semantic content of which is not
`available. Note: Ciphertext may itself be input to encipherment, producing superenciphered data.
`
`1.2.2.6 cleartext: Intelligible data, the semantic content of which is available. (IS0 7498-2 : 1989)
`
`1.2.2.7 compromise: A violation of the security of a system such that an unauthorized disclosure of sensi-
`tive information may have occurred. (NCSG-TG-005 Version- 1 [B3]*)
`
`1.2.2.8 confidentiality: The property of information that is not made available or disclosed to unauthorized
`individuals, entities, or processes. (IS0 7498-2 : 1989)
`
`1.2.2.9 connection-oriented confidentiality: The protection of all (N)-service data units from unauthorized
`disclosure during communications from one (N+l)-entity to one or more (N+ 1)-entities for which a security
`association is established for the transfer of data and for the application of confidentiality service between
`the entities themselves and between each entity and the physical layer.
`
`1.2.2.10 connection-oriented integrity: A service providing for the integrity of all (N)-service data on a
`security association and detecting any modification, insertion, deletion, or replay of any data within an entire
`SDU sequence.
`
`‘Information on references can be found in 1.3.
`’The numbers in brackets preceded by the letter B correspond to those of the bibliography in clause 5
`
`2
`
`Authorized licensed use limited to: UCLA Library. Downloaded on January 19,2016 at 18:54:06 UTC from IEEE Xplore. Restrictions apply.
`
`000012
`
`

`
`LAN/MAN SECURITY (SILS)
`
`IEEE
`Std 802.10-1992
`
`1.2.2.11 connectionless confidentiality: The protection of (N)-service data units from unauthorized disclo-
`sure during transmission from one (N+l)-entity to one or more (N+l)-entities, where each entity has an
`association with the physical layer, and no association is established for the transmission of data or for the
`application of the confidentiality service between the layer peer-entities themselves.
`
`1.2.2.12 connectionless integrity: A service providing for the integrity of a single SDU. It may take the
`form of determining whether or not the received SDU has been modified.
`
`1.2.2.13 cryptographic checkvalue: Information that is derived by performing a cryptographic transforma-
`tion on the data unit. See: cryptography. (IS0 7498-2 : 1989)
`
`1.2.2.14 cryptography: The discipline embodying principles, means, and methods for the transformation of
`data in order to hide its information content, prevent its undetected modification, andor prevent its unautho-
`rized use. (IS0 7498-2 : 1989)
`
`1.2.2.15 data deciphering key: A key used for the decipherment of an (N)-layer SDU. (It is not used to
`decipher other keys.)
`
`1.2.2.16 data enciphering key: A key used for the encipherment of an (N)-layer SDU. (It is not used to
`encipher other keys.)
`
`1.2.2.17 data integrity: The condition or state in which data has not been altered or destroyed in an unau-
`thorized manner. (IS0 7498-2 : 1989)
`
`1.2.2.18 data origin authentication: The corroboration that the source of data received is as claimed. This
`service, when provided by the (N)-layer, provides the corroboration to an (N+l)-entity that the source of the
`data is the claimed peer (N+l)-entity. (IS0 7498-2 : 1989)
`
`1.2.2.19 decipherment: The reversal of a corresponding reversible encipherment. IS0 7498-2 : 1989)
`
`1.2.2.20 encipherment: The cryptographic transformation of data to produce ciphertext. See: cryptogra-
`phy. (IS0 7498-2 : 1989)
`
`1.2.2.21 Initialization Vector (IV): A binary vector used at the beginning of a cryptographic operation to
`allow cryptographic chaining. (ANSI X9.17-1985)
`
`1.2.2.22 Integrity Check Value (ICV): A value that is derived by performing an algorithmic transformation
`on the data unit for which data integrity services are provided. The ICV is sent with the protected data unit
`and is recalculated and compared by the receiver to detect data modification. See: cryptographic check-
`value.
`
`1.2.2.23 key: A sequence of symbols that controls the operations of encipherment and decipherment. (IS0
`7498-2 : 1989)
`
`1.2.2.24 key management: The generation, storage, distribution, deletion, archiving, and application of
`keys in accordance with a security policy. (IS0 7498-2 : 1989)
`
`1.2.2.25 Key Management Stack: The protocols residing above SDE that request services via an SDE SAP
`that is supported by the use of a bootstrap SAID with either of the two values reserved for key management.
`
`1.2.2.26 layer management: Functions related to the management of the (N)-layer partly performed in the
`(N)-layer itself according to the (N)-protocol of the layer, and partly performed as a subset of systems man-
`agement. (IS0 7498 : 1984)
`
`3
`
`Authorized licensed use limited to: UCLA Library. Downloaded on January 19,2016 at 18:54:06 UTC from IEEE Xplore. Restrictions apply.
`
`000013
`
`

`
`IEEE
`Std 802.10-1992
`
`IEEE STANDARDS FOR LOCAL AND METROPOLITAN AREA NETWORKS:
`
`1.2.2.27 Layer Manager (LM): A systems management service application for which a particular exchange
`of systems management information has taken a manager role of the (N)-layer. (ISOAEC 10040 : 1992)
`
`1.2.2.28 managed object: The OS1 structure of management information (ISOAEC 10165-2 : 1992) term
`used as an abstract representation of a resource. This managed object has a set of attributes. These attributes
`are equivalent to data objects.
`
`1.2.2.29 manipulation detection: A mechanism used to detect whether a data unit has been modified (either
`accidentally or intentionally). (IS0 7498-2 : 1989)
`
`1.2.2.30 masquerade: The pretense by an entity to be a different entity. (IS0 7498-2 : 1989)
`
`1.2.2.31 Management Information Base (MIB): A conceptual database of information contained in the
`collection of all the managed object classes and their instances. (ISOAEC 7498-4 : 1989)
`
`1.2.2.32 misordering data: A form of unauthorized data modification in which the reception sequence of
`data units is altered from the original transmission sequence in an unauthorized manner. This can be
`attempted by a combination of techniques involving deleting, delaying, and reinserting data; or modifying
`sequence control information; or both.
`
`1.2.2.33 object: A data object that has an identifier (name) and a value.
`
`1.2.2.34 Open Systems Interconnection (OSI) (N)-service: A capability of the (N)-layer, and the layers
`beneath it, that is provided to the (N)-entities at the boundary between the (N)-layer and the (N+l)-layer.
`(IS0 7498 : 1984)
`
`1.2.2.35 peer-entity authentication: The corroboration that a peer entity in an association is the one
`claimed. This service, when provided by the (N)-layer, provides corroboration to the (N+l)-entity that the
`peer entity is the claimed (N+l)-entity. (IS0 7498-2 : 1989) This is primarily intended for, although not lim-
`ited to, connection-oriented service and may be either unilateral or mutual.
`
`1.2.2.36 reflection: A form of data modification in which PDUs sent by an entity are returned in an unautho-
`rized manner. This can be attempted by a combination of techniques involving deleting, delaying, and rein-
`serting data; andor modifying address or sequence control information.
`
`1.2.2.37 secret key: The traditional cryptographic key known only to the communicating parties and used
`for both encipherment and decipherment.
`
`1.2.2.38 security association: A cooperative relationship between entities formed by the sharing of crypto-
`graphic keying information and security management objects. This shared information need not be identical,
`but it must be compatible.
`
`1.2.2.39 Security Association Identifier (SAID): A value placed in the clear header of the SDE PDU that
`is used to identify the security association.
`
`1.2.2.40 Security Management Information Base (SMIB): An MIB that stores security-relevant objects.
`
`1.2.2.41 security service: A service, provided by a layer of communicating open systems, that ensures ade-
`quate security of the systems or of data transfers. (IS0 7498-2 : 1989) Note that these security services need
`not be directly requested at the (N)- and (N+l)-layer boundary as is required for an OS1 (N)-service.
`
`1.2.2.42 systems management: Functions in the Application Layer related to the management of various
`OS1 resources and their status across all layers of the OS1 architecture. (IS0 7498 : 1984)
`
`4
`
`Authorized licensed use limited to: UCLA Library. Downloaded on January 19,2016 at 18:54:06 UTC from IEEE Xplore. Restrictions apply.
`
`000014
`
`

`
`LANlM AN SEC U R ITY (SI LS)
`
`IEEE
`Std 802.10-1992
`
`1.2.2.43 System Management Stack: The protocols residing above SDE that request services via an SDE
`SAP that is supported by the use of a bootstrap SAID with either of the two values reserved for system man-
`agement.
`
`1.2.2.44 threat: A potential violation of security. (IS0 7498-2 : 1989)
`
`1.2.2.45 trusted functionality: That which is perceived to be correct with respect to some criteria, e.g., as
`established by a security policy. (IS0 7498-2 : 1989)
`
`1.2.2.46 unauthorized disclosure: The process of making information available to unauthorized individu-
`als, entities, or processes. (IS0 7498-2 : 1989)
`
`1.2.2.47 unauthorized data modification: Alteration of data not consistent with the defined security policy.
`
`1.2.2.48 unauthorized resource use: Use of a resource not consistent with the defined security policy.
`(IS0 7498-2 : 1989)
`
`1.2.2.49 User Stack: The protocols residing above SDE that request services from any SDE SAP except
`those supported by the use of a bootstrap SAID.
`
`1.3 References
`
`This standard shall be used in conjunction with the following references:
`
`ANSI X9.17-1985 (R1991), Financial Institution Key Management (Wh~lesale).~
`
`IEEE Std 802-1990, IEEE Standards for Local Area Networks: Overview and Architecture (ANSI).4
`
`I S 0 7498 :