ISO 15892:2000

Space data and information transfer systems — Protocol specification for space communications — Security protocol

Systèmes de transfert des informations et données spatiales — Spécification d'un protocole pour communications spatiales — Protocole de sécurité

General Information

• Status: Withdrawn
• Publication Date: 04-Oct-2000
• Withdrawal Date: 04-Oct-2000
• ICS: 49.140 - Space systems and operations
• Technical Committee: ISO/TC 20/SC 13 - Space data and information transfer systems
• Drafting Committee: ISO/TC 20/SC 13 - Space data and information transfer systems
• Current Stage: 9599 - Withdrawal of International Standard
• Completion Date: 10-May-2011

Relations

• Consolidated By: ISO 14122-2:2001/Amd 1:2010 - Safety of machinery — Permanent means of access to machinery — Part 2: Working platforms and walkways — Amendment 1
• Effective Date: 06-Jun-2022

Standards Content (Sample)

INTERNATIONAL ISO
STANDARD 15892
First edition
2000-09-15
Space data and information transfer
systems — Protocol specification for space
communications — Security protocol
Systèmes de transfert des informations et données spatiales —
Spécification d'un protocole pour communications spatiales — Protocole de
sécurité
Reference number
ISO 15892:2000(E)
©
ISO 2000

---------------------- Page: 1 ----------------------
ISO 15892:2000(E)
PDF disclaimer
This PDF file may contain embedded typefaces. In accordance with Adobe's licensing policy, this file may be printed or viewed but shall not
be edited unless the typefaces which are embedded are licensed to and installed on the computer performing the editing. In downloading this
file, parties accept therein the responsibility of not infringing Adobe's licensing policy. The ISO Central Secretariat accepts no liability in this
area.
Adobe is a trademark of Adobe Systems Incorporated.
Details of the software products used to create this PDF file can be found in the General Info relative to the file; the PDF-creation parameters
were optimized for printing. Every care has been taken to ensure that the file is suitable for use by ISO member bodies. In the unlikely event
that a problem relating to it is found, please inform the Central Secretariat at the address given below.
© ISO 2000
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 either ISO at the address below or ISO's member body
in the country of the requester.
ISO copyright office
Case postale 56 � CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail [e-mail]
Web www.iso.ch
Printed in Switzerland
ii © ISO 2000 – All rights reserved

---------------------- Page: 2 ----------------------
ISO 15892:2000(E)
Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards bodies (ISO
member bodies). The work of preparing International Standards is normally carried out through ISO technical
committees. Each member body interested in a subject for which a technical committee has been established has
the right to be represented on that committee. International organizations, governmental and non-governmental, in
liaison with ISO, also take part in the work. ISO collaborates closely with the International Electrotechnical
Commission (IEC) on all matters of electrotechnical standardization.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 3.
Draft International Standards adopted by the technical committees are circulated to the member bodies for voting.
Publication as an International Standard requires approval by at least 75 % of the member bodies casting a vote.
Attention is drawn to the possibility that some of the elements of this International Standard may be the subject of
patent rights. ISO shall not be held responsible for identifying any or all such patent rights.
International Standard ISO 15892 was prepared by the Consultative Committee for Space Data Systems (CCSDS)
(as CCSDS 713.5-B-1) and was adopted (without modifications except those stated in clause 3 of this International
Standard) by Technical Committee ISO/TC 20, Aircraft and space vehicles, Subcommittee SC 13, Space data and
information transfer systems.
© ISO 2000 – All rights reserved iii

---------------------- Page: 3 ----------------------
INTERNATIONAL STANDARD ISO 15892:2000(E)
Space data and information transfer systems — Protocol
specification for space communications — Security protocol
1 Scope
This International Standard specifies the requirements for the services and protocols of the space communications
protocol specification (SCPS) security protocol (SP). These requirements are to allow independent implementations
of this protocol to interoperate if they use compatible security service algorithms.
This International Standard is applicable to any kind of space mission or infrastructure, regardless of complexity.
2 Conformance
This International Standard is applicable to all systems that claim conformance to the ISO/CCSDS SCPS security
protocol.
3 Requirements
Requirements are the technical recommendations made in the following publication (reproduced on the following
pages), which is adopted as an International Standard:
CCSDS 713.5-B-1, May 1999, Recommendation for space data system standards — Space communications
protocol specification (SCPS) — Security protocol (SCPS-SP).
For the purposes of international standardization, the modifications outlined below shall apply to the specific
clauses and paragraphs of publication CCSDS 713.5-B-1.
Pages i to v
This part is information which is relevant to the CCSDS publication only.
Pages B-1 to B-2
Add the following information to the references indicated in annex B:
[B12] Document CCSDS 713.0-B-1, May 1999, is equivalent to ISO 15891:2000.
[B13] Document CCSDS 714.0-B-1, May 1999, is equivalent to ISO 15893:2000.
[B16] Document CCSDS 701.0-B-2, November 1992, is equivalent to ISO 13420:1997.
[B17] Document CCSDS 102.0-B-4, November 1995, is equivalent to ISO 13419:1997.
[B18] Document CCSDS 201.0-B-2, November 1995, is equivalent to ISO 12171:1998.
© ISO 2000 – All rights reserved 1

---------------------- Page: 4 ----------------------
ISO 15892:2000(E)
4 Revision of publication CCSDS 713.5-B-1
It has been agreed with the Consultative Committee for Space Data Systems that Subcommittee ISO/TC 20/SC 13
will be consulted in the event of any revision or amendment of publication CCSDS 713.5-B-1. To this end, NASA
will act as a liaison body between CCSDS and ISO.
2 © ISO 2000 – All rights reserved

---------------------- Page: 5 ----------------------
ISO 15892:2000(E)
RECOMMENDATION FOR SPACE
DATA SYSTEM STANDARDS
SPACE COMMUNICATIONS
PROTOCOL SPECIFICATION (SCPS)—
SECURITY PROTOCOL
(SCPS-SP)
CCSDS 713.5-B-1
BLUE BOOK
May 1999
© ISO 2000 – All rights reserved 3

---------------------- Page: 6 ----------------------
ISO 15892:2000(E)
(Blank page)
4 © ISO 2000 – All rights reserved

---------------------- Page: 7 ----------------------
ISO 15892:2000(E)
CCSDS RECOMMENDATION FOR SCPS SECURITY PROTOCOL (SCPS-SP)
AUTHORITY
Issue: Blue Book, Issue 1
Date: May 1999
Location: Newport Beach, California, USA
This document has been approved for publication by the Management Council of the
Consultative Committee for Space Data Systems (CCSDS) and represents the consensus
technical agreement of the participating CCSDS Member Agencies. The procedure for
review and authorization of CCSDS Recommendations is detailed in reference [B1], and the
record of Agency participation in the authorization of this document can be obtained from the
CCSDS Secretariat at the address below.
This Recommendation is published and maintained by:
CCSDS Secretariat
Program Integration Division (Code MT)
National Aeronautics and Space Administration
Washington, DC 20546, USA
CCSDS 713.5-B-1 Page i May 1999
© ISO 2000 – All rights reserved 5

---------------------- Page: 8 ----------------------
ISO 15892:2000(E)
CCSDS RECOMMENDATION FOR SCPS SECURITY PROTOCOL (SCPS-SP)
STATEMENT OF INTENT
The Consultative Committee for Space Data Systems (CCSDS) is an organization officially
established by the management of member space Agencies. The Committee meets
periodically to address data systems problems that are common to all participants, and to
formulate sound technical solutions to these problems. Inasmuch as participation in the
CCSDS is completely voluntary, the results of Committee actions are termed
Recommendations and are not considered binding on any Agency.
This Recommendation is issued by, and represents the consensus of, the CCSDS Plenary
body. Agency endorsement of this Recommendation is entirely voluntary. Endorsement,
however, indicates the following understandings:
o Whenever an Agency establishes a CCSDS-related standard, this standard will be in
accord with the relevant Recommendation. Establishing such a standard does not
preclude other provisions which an Agency may develop.
o Whenever an Agency establishes a CCSDS-related standard, the Agency will provide
other CCSDS member Agencies with the following information:
-- The standard itself.
-- The anticipated date of initial operational capability.
-- The anticipated duration of operational service.
o Specific service arrangements shall be made via memoranda of agreement. Neither this
Recommendation nor any ensuing standard is a substitute for a memorandum of
agreement.
No later than five years from its date of issuance, this Recommendation will be reviewed by
the CCSDS to determine whether it should: (1) remain in effect without change; (2) be
changed to reflect the impact of new technologies, new requirements, or new directions; or,
(3) be retired or canceled.
In those instances when a new version of a is issued, existing CCSDS-
Recommendation
related Agency standards and implementations are not negated or deemed to be non-CCSDS
compatible. It is the responsibility of each Agency to determine when such standards or
implementations are to be modified. Each Agency is, however, strongly encouraged to direct
planning for its new standards and implementations towards the later version of the
Recommendation.
CCSDS 713.5-B-1 Page ii May 1999
6 © ISO 2000 – All rights reserved

---------------------- Page: 9 ----------------------
ISO 15892:2000(E)
CCSDS RECOMMENDATION FOR SCPS SECURITY PROTOCOL (SCPS-SP)
FOREWORD
This Recommendation defines the services and protocols of the Space Communications
Protocol Specification (SCPS) Security Protocol (SP).
Through the process of normal evolution, it is expected that expansion, deletion, or
modification of this document may occur. This Recommendation is therefore subject to
CCSDS document management and change control procedures as defined in reference [B1].
Current versions of CCSDS documents are maintained at the CCSDS Web site:
http://www.ccsds.org/
Questions relating to the contents or status of this document should be addressed to the
CCSDS Secretariat at the address indicated on page i.
CCSDS 713.5-B-1 Page iii May 1999
© ISO 2000 – All rights reserved 7

---------------------- Page: 10 ----------------------
ISO 15892:2000(E)
CCSDS RECOMMENDATION FOR SCPS SECURITY PROTOCOL (SCPS-SP)
At time of publication, the active Member and Observer Agencies of the CCSDS were
Member Agencies
– British National Space Centre (BNSC)/United Kingdom.
– Canadian Space Agency (CSA)/Canada.
– Centre National d’Etudes Spatiales (CNES)/France.
– Deutsches Zentrum für Luft- und Raumfahrt e.V. (DLR)/Germany.
– European Space Agency (ESA)/Europe.
– Instituto Nacional de Pesquisas Espaciais (INPE)/Brazil.
– National Aeronautics and Space Administration (NASA)/USA.
– National Space Development Agency of Japan (NASDA)/Japan.
– Russian Space Agency (RSA)/Russian Federation.
Observer Agencies
– Austrian Space Agency (ASA)/Austria.
– Central Research Institute of Machine Building (TsNIIMash)/Russian Federation.
– Centro Tecnico Aeroespacial (CTA)/Brazil.
– Chinese Academy of Space Technology (CAST)/China.
– Commonwealth Scientific and Industrial Research Organization (CSIRO)/Australia.
– Communications Research Laboratory (CRL)/Japan.
– Danish Space Research Institute (DSRI)/Denmark.
– European Organization for the Exploitation of Meteorological Satellites
(EUMETSAT)/Europe.
– European Telecommunications Satellite Organization (EUTELSAT)/Europe.
– Federal Service of Scientific, Technical & Cultural Affairs (FSST&CA)/Belgium.
– Hellenic National Space Committee (HNSC)/Greece.
– Indian Space Research Organization (ISRO)/India.
– Industry Canada/Communications Research Centre (CRC)/Canada.
– Institute of Space and Astronautical Science (ISAS)/Japan.
– Institute of Space Research (IKI)/Russian Federation.
– KFKI Research Institute for Particle & Nuclear Physics (KFKI)/Hungary.
– MIKOMTEK: CSIR (CSIR)/Republic of South Africa.
– Korea Aerospace Research Institute (KARI)/Korea.
– Ministry of Communications (MOC)/Israel.
– National Oceanic & Atmospheric Administration (NOAA)/USA.
– National Space Program Office (NSPO)/Taipei.
– Swedish Space Corporation (SSC)/Sweden.
– United States Geological Survey (USGS)/USA.
CCSDS 713.5-B-1 Page iv May 1999
8 © ISO 2000 – All rights reserved

---------------------- Page: 11 ----------------------
ISO 15892:2000(E)
CCSDS RECOMMENDATION FOR SCPS SECURITY PROTOCOL (SCPS-SP)
DOCUMENT CONTROL
Document Title Date Status
CCSDS Space Communications May 1999 Original issue
713.5-B-1 Protocol Specification
(SCPS)—Security Protocol
(SCPS-SP)
CCSDS 713.5-B-1 Page v May 1999
© ISO 2000 – All rights reserved 9

---------------------- Page: 12 ----------------------
ISO 15892:2000(E)
CCSDS RECOMMENDATION FOR SCPS SECURITY PROTOCOL (SCPS-SP)
CONTENTS
Section Page
1 INTRODUCTION.1-1
1.1 PURPOSE .1-1
1.2 SCOPE .1-1
1.3 APPLICABILITY .1-1
1.4 ORGANIZATION OF RECOMMENDATION .1-1
1.5 CONVENTIONS AND DEFINITIONS .1-2
2 OVERVIEW .2-1
3 PROTOCOL SPECIFICATION .3-1
3.1 SCPS-SP TYPES OF SECURITY SERVICES.3-1
3.2 SCPS-SP PROTOCOL DATA UNIT.3-2
3.3 SCPS-SP CLEAR HEADER .3-3
3.4 SCPS-SP PROTECTED HEADER .3-5
3.5 INTEGRITY CHECK VALUE FIELD .3-7
4 PROTOCOL FUNCTIONS .4-1
4.1 TRANSMISSION FUNCTIONS.4-1
4.2 RECEPTION FUNCTIONS .4-2
4.3 INTEGRITY SERVICE PROCESSING.4-4
4.4 AUTHENTICATION SERVICE PROCESSING.4-6
4.5 CONFIDENTIALITY SERVICE PROCESSING .4-7
4.6 END-SYSTEM TO INTERMEDIATE SYSTEM INTERACTIONS.4-11
5 SECURITY ASSOCIATION ATTRIBUTES .5-1
ANNEX A ACRONYMS AND ABBREVIATIONS.A-1
ANNEX B INFORMATIVE REFERENCES. B-1
ANNEX C PROTOCOL IMPLEMETATION CONFORMANCE
STATMENT (PICS) PROFORMA .C-1
ANNEX D SCPS SECURITY PROTOCOL SERVICE SPECIFICATION.D-1
Figure
3-1 SCPS-SP Protocol Data Unit .3-2
3-2 SCPS-SP Clear Header.3-3
3-3 SCPS-SP Protected Header .3-5
3-4 Protected Header Encapsulated Address Field.3-6
CCSDS 713.5-B-1 Page vi May 1999
10 © ISO 2000 – All rights reserved

---------------------- Page: 13 ----------------------
ISO 15892:2000(E)
CCSDS RECOMMENDATION FOR SCPS SECURITY PROTOCOL (SCPS-SP)
1 INTRODUCTION
1.1 PURPOSE
The purpose of this Recommendation is to define the services and protocols of the Space
Communications Protocol Specifications (SCPS) Security Protocol (SP). This definition will
allow independent implementations of the protocol to interoperate if they use compatible
security service algorithms.
1.2 SCOPE
This Recommendation is intended to be applied to all systems that claim conformance to the
SCPS Security Protocol.
1.3 APPLICABILITY
This Recommendation is designed to be applicable to any kind of space mission or
infrastructure, regardless of complexity. It is intended that this should become a uniform
standard among all CCSDS Agencies.
1.4 ORGANIZATION OF RECOMMENDATION
This document is organized as follows:
– Section 1 provides an introduction to the Recommendation;
– Section 2 provides an overview of the Security Protocol;
– Section 3 provides the protocol specification and the header layouts;
– Section 4 provides details on protocol processing;
– Section 5 provides information on Security Association Attributes;
– Annex A provides expansion of acronyms and abbreviations used in the document;
– Annex B lists informative references;
– Annex C provides the Protocol Implementation Conformance Statement (PICS);
– Annex D provides the Security Protocol’s service specification.
CCSDS 713.5-B-1 Page 1-1 May 1999
© ISO 2000 – All rights reserved 11

---------------------- Page: 14 ----------------------
ISO 15892:2000(E)
CCSDS RECOMMENDATION FOR SCPS SECURITY PROTOCOL (SCPS-SP)
1.5 CONVENTIONS AND DEFINITIONS
1.5.1 BIT NUMBERING CONVENTION AND NOMENCLATURE
In this document, the following convention is used to identify each bit in an N-bit field. The
first bit in the field to be transmitted is drawn as the most left justified when drawing a figure,
and is defined to be ‘Bit 0’. The following bit is defined to be ‘Bit 1’ and so on, through ‘Bit
N-1’. The order in which multi-octet fields are transmitted is called ‘Big-Endian’ byte
ordering. When applied to networking, this is called ‘network byte order’. In this ordering
scheme, bit 0 of a 32-bit value is the Most Significant Bit (MSB) and bit 31 is the least
significant bit. The octet containing bits 0-7 is transmitted first, followed by the octet
containing bits 8-15, followed by the octet containing bits 16-23, and finally the octet
containing bits 24-31. Fields are sometimes drawn on more than one line in a figure. In this
case, the uppermost line of a multi-line field is transmitted before subsequent lines in that
field, and in the case of binary values, contains the bits of greater significance than those in
following lines. Note that ‘Big-Endian’ byte ordering is NOT what some machines (notably
the 80x86 class of machines) use internally. Implementers must ensure that headers are
converted to network byte order for transmission.
The following conventions apply throughout this Recommendation:
– the words ‘shall’ and ‘must’ imply a binding and verifiable recommendation;
– the word ‘should’ implies an optional, but desirable, recommendation;
– the word ‘may’ implies an optional recommendation; and
– the words ‘is’, ‘are’, and ‘will’ imply statements of fact.
1.5.2 DEFINITIONS
: the assurance that information transmitted from a claimed source (such as
Authentication
the source’s identity) in fact came only from that source.
Confidentiality: the disclosure of information only to those who are authorized and have
been approved to receive it.
Confirm (primitive): a primitive issued by a service-provider to complete, at a particular
service-access-point, some procedure previously invoked by a request at that service-access-
point.
Decipherment: the mechanism by which coded text is transposed into plain text based on a
predetermined key.
Encipherment: the mechanism by which plain text is transposed into a code based on a
predetermined key.
End System: an addressable network entity within the SCPS Network.
CCSDS 713.5-B-1 Page 1-2 May 1999
12 © ISO 2000 – All rights reserved

---------------------- Page: 15 ----------------------
ISO 15892:2000(E)
CCSDS RECOMMENDATION FOR SCPS SECURITY PROTOCOL (SCPS-SP)
Gateway: a network-addressable system that terminates a protocol at a given layer and
invokes similar services at the same layer of an adjacent network.
(primitive): a primitive issued by a service provider either to invoke some
Indication
procedure or to indicate that a procedure has been invoked by the service user at a peer
service-access-point.
Integrity: the assurance that information received from a source is in fact the information
transmitted, without unauthorized modification.
Internet Protocol Number: the transport protocol identifier used by Internet Protocols.
Values may range from 0 through 255, and valid values are defined in reference [B14].
N-Address: an address in the SCPS Network. The attributes of an N-Address are the
Address Type and the Address Family.
N-Destination_Address: an N-Address that identifies the destination end system of a
datagram in the SCPS Network. The N-Destination_Address is a parameter of all of the
SCPS Network service primitives. It is an N-Address that identifies the destination end
system of a datagram in the SCPS Network. The N-Destination_Address parameter must be
of the Extended End System address type, and may be of either the IP or the SCPS address
family.
Network-Service Data Unit (N-SDU): a variable-length, octet-aligned data unit of arbitrary
format. The Network Service Data Unit (N-SDU) is a parameter of the Unit Data service
primitives.
N-Source_Address: an N-Address that identifies the end system originating a datagram in
the SCPS Network. The N-Source_Address is a parameter to many of the primitives of the
SCPS network service. The N-Source_Address must be of the Extended End System address
type, and may be of either the IP or the SCPS address family. The N-Source_Address may
not be a multicast or a broadcast address.
Primitive: (also known as service-primitive) an abstract, implementation-independent
interaction between a service-user and the service-provider.
Request (primitive): a primitive issued by a service-user to invoke some procedure.
Response (primitive): a primitive issued by a service-user to complete, at a particular
service-access-point, some procedure previously invoked by an indication at that service-
access-point.
Security Association (SA): security management information used by the security
mechanisms.
Security Association Identifier (SAID): the index into the SA database formed by the
source and destination addresses of the communicating systems.
CCSDS 713.5-B-1 Page 1-3 May 1999
© ISO 2000 – All rights reserved 13

---------------------- Page: 16 ----------------------
ISO 15892:2000(E)
CCSDS RECOMMENDATION FOR SCPS SECURITY PROTOCOL (SCPS-SP)
Service-Access-Point: a point at which the services of a layer are made available to the layer
above it.
: see Primitive.
Service-Primitive
Security Service Data Unit (S-SDU): a variable-length, octet-aligned data unit of arbitrary
format. The S-SDU is a parameter of the Unit Data service primitives.
CCSDS 713.5-B-1 Page 1-4 May 1999
14 © ISO 2000 – All rights reserved

---------------------- Page: 17 ----------------------
ISO 15892:2000(E)
CCSDS RECOMMENDATION FOR SCPS SECURITY PROTOCOL (SCPS-SP)
2 OVERVIEW
This document provides the framework for the SCPS-SP, which is a layer-3 subnetwork
independent convergence security protocol.
The SCPS-SP provides the following connectionless security services on an end-to-end basis
(where the service endpoints are defined by the implementer):
– confidentiality;
– integrity;
– authentication; or
– a combination of all of the above.
The basic mode of operation of SCPS-SP is encapsulation of a Transport Protocol Data Unit
(T-PDU) into a Security Protocol Data Unit (S-PDU). The T-PDUs may be enciphered to
provide confidentiality, may have an Integrity Check Value (ICV) calculated and appended to
provide integrity (non-forgeability) of the T-PDU, or may both be enciphered and have an
ICV applied. Explicit authentication in SCPS-SP requires the use of either the integrity
and/or the confidentiality services. Implicit authentication is provided as a by-product of key
management. In the case where both integrity and confidentiality are required, integrity is
applied first, and then confidentiality.
The concepts for this specification are drawn from a number of sources (see annex B) such as
Secure Data Network Systems (SDNS) Security Protocol 3 (SP3) (reference [B2]), ISO
Network Layer Security Protocol (NLSP) (reference [B7]), Internet Protocol Version 6
Encapsulating Security Payload (reference [B3]), and Integrated Network Layer Security
(reference [B5]). SCPS-SP’s major point of departure from these other security
Protocol
protocols is the insistence on near-optimal bit efficiency, which was not a design requirement
for the other protocols. The SCPS-SP has been refined to ensure minimal transmitted bit
overhead.
The SCPS-SP assumes that it resides on top of a connectionless network service, known
throughout this specification as the Underlying Network (UN). An example of such a
protocol is the SCPS Network Protocol (SCPS-NP) (reference[B12]).
Processing within SCPS-SP is security-critical. Therefore, the Security Protocol is the only
portion of the SCPS suite that, from a security perspective, must be trusted to perform its
security functions correctly. This is not to imply that the other protocol layers do not have to
operate correctly. However, only SCPS-SP has the responsibility to perform security-critical
processing. The layers above SCPS-SP may handle classified or proprietary data, but it is
SCPS-SP’s job to ensure that the data is afforded the requisite security protections before
forwarding the data to the lower layers and onto the network. Likewise, a protocol layer
below SCPS-SP may handle sensitive data, but only SCPS-SP has the responsibility for
ensuring that the required security services are applied.
CCSDS 713.5-B-1 Page 2-1 May 1999
© ISO 2000 – All rights reserved 15

---------------------- Page: 18 ----------------------
ISO 15892:2000(E)
CCSDS RECOMMENDATION FOR SCPS SECURITY PROTOCOL (SCPS-SP)
The SCPS-SP employs both a clear and a protected header. The clear header, which must
remain un-enciphered, provides a small amount of processing information to the security
protocol. The protected header contains additional information which may be enciphered
(along with the user data), depending upon the system security policy being enforced by the
Security Protocol as well as the user’s security services request. The security protection that
the SCPS-SP attempts to provide is derived from a combination of the security services
requested by the SCPS-SP user and the protection requirements imposed by the security
domain administrator through the enforcement of the local security policy.
Although the degree of protection afforded by the security mechanisms depends on the use of
specific cryptographic or digital signature secure hash techniques, correct operation of this
protocol is not dependent on the choice of any particular encipherment, decipherment, or
integrity algorithm. The choice of algorithms is left as a local security matter.
In order for SCPS-SP to provide end-to-end protection services and still operate across
security-unaware networks, the addressing information in the UN layer must remain un-
enciphered to allow PDU routing. Because the address information is not enciphered, SCPS-
SP does not provide protection against traffic analysis, nor does it provide protection against
jamming or low-probability-of-intercept (LPI). Traffic analysis protection must be provided
1
at the link layer; jamming and LPI protection must be provided at the physical layer. SCPS-
SP also does not provide protection against replay attacks. It is assumed that either the
encryption algorithm or a sequence number provided by an upper-layer transport protocol,
such as SCPS-TP (reference [B13]), would protect against replay attacks.
Neither the choice nor the implementation of a specific security policy are within the scope of
this specification. The choice of a specific security policy, and therefore the protection that
will be achieved by the SCPS-SP user, is a local matter for determination by the security
domain administration.
1
Confidentiality, integrity, and authentication may also be provided at the physical layer. However,
for store and forward systems, the security services at this layer can only be implemented on a hop-
by-hop basis and not on an end-to-end basis. This means that when using link layer security services,
the data must be deciphered, exposing the data, and then re-enciphered at each hop. This is not the
case when using end-to-end security services such as those provided by SCPS-SP.
CCSDS 713.5-B-1 Page 2-2 May 1999
16 © ISO 2000 – All rights reserved

---------------------- Page: 19 ----------------------
ISO 15892:2000(E)
CCSDS RECOMMENDATION FOR SCPS SECURITY PROTOCOL (SCPS-SP)
3 PROTOCOL SPECIFICATION
3.1 SCPS-SP TYPES OF SECURITY SERVICES
3.1.1 GENERAL
SCPS-SP shall support the following types of Security Services:
– integrity services;
– confidentiality services;
– authentication services.
3.1.2 INTEGRITY SERVICES
When integrity services are requested by a SCPS-SP user (e.g., an upper-layer protocol) or
are required as a default action to enforce an administrative security policy,
a) SCPS-SP shall calculate an ICV over the SCPS-SP clear and protected header
...