ISO 15892:2000

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 2000
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.
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 copyright@iso.ch
Web www.iso.ch
Printed in Switzerland
ii © ISO 2000 – All rights reserved

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.
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.
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

RECOMMENDATION FOR SPACE
DATA SYSTEM STANDARDS
SPACE COMMUNICATIONS
PROTOCOL SPECIFICATION (SCPS)—
SECURITY PROTOCOL
(SCPS-SP)
CCSDS 713.5-B-1
BLUE BOOK
May 1999
(Blank page)
4 © ISO 2000 – All rights reserved

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
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

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
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

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
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

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
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

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
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

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
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
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.
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

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 headers, the
user data, which includes any upper-layer protocol headers, and potentially a secret
data stream (e.g., a ‘secret key’);
b) the size of the ICV shall be established in the SA database (integ_alg_ICV_length);
NOTE – The SCPS-SP operates with the assumption that there exists a Security
Association (SA) database that contains pertinent security information, for
use between the communicating entities, such as the encipher key, the key
expiration, the key length, the Initialization Vector (IV) length, the
encipherment algorithm, the integrity algorithm, and the ICV length.
Example Security Association parameters are illustrated in section 5 (Security
Association Attributes) of this Recommendation.
c) the specific manner in which the ICV is calculated shall be determined by the
integrity algorithm as identified by integ_alg_id in the SA database.
3.1.3 CONFIDENTIALITY SERVICES
When confidentiality services are requested by a SCPS-SP user or are required as a default
action to enforce an administrative security policy, the SCPS-SP shall use the encipherment
key (cipher_key) in conjunction with the encipherment algorithm (conf_alg_id) and
algorithm mode (conf_alg_mode_id) specified in the SA database to encipher the SCPS-SP
protected header and the user data.
CCSDS 713.5-B-1 Page 3-1 May 1999
CCSDS RECOMMENDATION FOR SCPS SECURITY PROTOCOL (SCPS-SP)
3.1.4 AUTHENTICATION SERVICES
When authentication services are requested by a SCPS-SP user,
a) the source and destination network addresses shall be encapsulated into the SCPS-SP
protected header, and then either integrity and/or confidentiality services shall be
applied, as above;
b) authentication be requested with either integrity or confidentiality, or both; it
must
cannot be provided without one or both of the other services.
3.1.5 SECURITY SERVICES PROCESSING
When both integrity and confidentiality services are requested, the SCPS-SP shall first
perform the integrity service followed by the confidentiality service.
NOTE – As a result, the protected header, the user data, and the ICV generated by the
integrity service are enciphered.
3.2 SCPS-SP PROTOCOL DATA UNIT
The SCPS-SP Protocol Data Unit (PDU) shall consist of the following parts in the following
sequence:
Length in bits
– Clear Header (mandatory) variable
– Protected Header (mandatory) variable
– User Data (optional) variable
– Integrity Check Value (optional) variable
NOTE – The SCPS-SP PDU is illustrated in figure 3-1.
+---------------------------------------------------+
|      |        |      |     |
| CLEAR HDR | PROTECTED HDR | USER DATA |  ICV  |
|      |        |      |     |
+---------------------------------------------------+
Figure 3-1: SCPS-SP Protocol Data Unit
CCSDS 713.5-B-1 Page 3-2 May 1999
18 © ISO 2000 – All rights reserved

CCSDS RECOMMENDATION FOR SCPS SECURITY PROTOCOL (SCPS-SP)
3.3 SCPS-SP CLEAR HEADER
3.3.1 CLEAR HEADER FORMAT
The SCPS-SP Clear Header shall consist of the following fields in the following sequence:
Length in bits
– Internet Protocol Number (mandatory) 8
– initialization vector (optional) variable
NOTE – The SCPS-SP Clear Header is illustrated in figure 3-2.
+---------------------------------------------------+
|      INTERNET      | INITIALIZATION  |
|      PROTOCOL      |  VECTOR (IV)  |
|       NUMBER       |  (optional)  |
+---------------------------------------------------+
8 bits variable
Figure 3-2: SCPS-SP Clear Header
3.3.2 CLEAR HEADER FIELDS
3.3.2.1 Internet Protocol Number
3.3.2.1.1 The Internet Protocol Number field shall be eight bits in length and shall occupy
bits 0 through 7 of the SCPS-SP Clear Header.
3.3.2.1.2 The Internet Protocol Number field shall contain the Internet Assigned Numbers
Authority (IANA) specified number of the next upper-layer to receive and process the PDU
after SCPS-SP processing.
NOTE – Internet Protocol Number assignment is discussed in reference [B14].
3.3.2.2 Initialization Vector Option
3.3.2.2.1 The Initialization Vector Option field, if included, shall begin in bit 8 of the
SCPS-SP Clear Header and shall end on an octet boundary.
NOTE – Some confidentiality algorithms require the use of an initialization vector (IV) for
synchronization, while others do not. The key requirement for the generation of
an IV is that it be pseudo-random and not repeat itself during the period an
encipherment key is being used.
CCSDS 713.5-B-1 Page 3-3 May 1999
CCSDS RECOMMENDATION FOR SCPS SECURITY PROTOCOL (SCPS-SP)
3.3.2.2.2 The contents of the Initialization Vector Option field shall be determined as
follows:
a) If an Initialization Vector (IV) is explicitly transmitted:
1) the Security Association (SA) database entry IV_explicit shall be set to ‘TRUE’
during the SA establishment;
2) the IV, of IV_length, shall be constructed in accordance with the confidentiality
algorithm’s requirements and shall be placed into the clear header’s optional IV
field;
3) if an IV is not required, IV_length shall be set to zero (0).
b) If it is to be reconstructed by the receiver without being explicitly transmitted:
1) the SA database entry IV_explicit shall be set to ‘FALSE’ during the SA
establishment;
2) the IV may be constructed using the (coarse and fine resolution) clocks available
on the communicating end systems;
3) the IV shall be constructed of length IV_length through the combination of the
source address, the destination address, and the clock outputs used to generate a
UN timestamp;
4) the receiver shall reconstruct the IV as discussed in 4.5.2.
NOTE – In situations where transmitted bit overhead is a major concern, the explicit
IV mode option should not be used. Additionally, in order to reduce
processing overhead further, an encipherment algorithm should be chosen that
affords the requisite protection, but does not require the use of an IV.
Algorithm choices are not a part of this Recommendation and are left as a
local security matter.
3.3.3 CLEAR HEADER PROCESSING
3.3.3.1 The Clear Header shall be used by the receiving SCPS-SP for routing and delivery
of datagrams to an upper-layer protocol after security processing has been performed.
3.3.3.2 The Clear Header shall not be enciphered.
CCSDS 713.5-B-1 Page 3-4 May 1999
20 © ISO 2000 – All rights reserved

CCSDS RECOMMENDATION FOR SCPS SECURITY PROTOCOL (SCPS-SP)
3.4 SCPS-SP PROTECTED HEADER
3.4.1 PROTECTED HEADER FORMAT
The SCPS-SP Protected Header shall consist of the following fields in the following
sequence:
Length in bits
– Protected Header Option Flags (mandatory) 8
– Security Classification Label (optional) variable
– Encapsulated Address (optional) variable
– Cipher Pad (optional) variable
NOTE – The SCPS-SP Protected Header is illustrated in figure 3-3.
+-----------------------------------------------------------+
| Protected |  Security   | Encapsulated |  Cipher  |
| Header   | Classification  |  Address  |  Pad   |
| Option   |   Label    | (optional) | (optional) |
| Flags   |  (optional)   |       |      |
+-----------------------------------------------------------+
8 bits     variable     variable   variable
Figure 3-3: SCPS-SP Protected Header
3.4.2 PROTECTED HEADER FIELDS
3.4.2.1 Protected Header Option Flags Field
3.4.2.1.1 The Protected Header Option Flags field shall be eight bits in length and shall
occupy bits 0 through 7 of the SCPS-SP Protected Header.
3.4.2.1.2 The Protected Header Option Flags field shall contain a value selected from the
following list (no other flag-field bit combinations are currently defined):
Option Binary Value
– ICV_present: ‘00000001’
– cipher_padding_present: ‘00000010’
– encapsulated_address_present: ‘00000100’
– security_classification_label_present: ‘00001000’
3.4.2.2 Security Classification Label Field
3.4.2.2.1 The Security Classification Label field shall, if used, begin in bit 8 of the SCPS-
SP Protected Header and end on an octet boundary.
CCSDS 713.5-B-1 Page 3-5 May 1999
CCSDS RECOMMENDATION FOR SCPS SECURITY PROTOCOL (SCPS-SP)
NOTE – The label may consist of any label format (e.g., IP Security Option, reference
[B8]; Common Security Label, reference [B9]; Standard Security Label, reference
[B11]). The label contents are dictated by the specific standard employed.
3.4.2.2.2 The Security Classification Label field shall consist of a label-length subfield
followed by a label-contents subfield.
3.4.2.2.3 The label standard used shall be specified in the SA database (label_standard_id).
3.4.2.2.4 The length of this field will be determined by the specific label standard
employed.
3.4.2.3 Encapsulated Address Field
3.4.2.3.1 The Encapsulated Address field shall, if included, begin on the next octet
boundary following the locations of the Security Classification Label field, or the Protected
Header Option Flags field if no Security Classification Label field is included, and end on an
octet boundary.
NOTE – The Encapsulated Address option is used when explicit address authentication is
required or when SCPS-SP is run at an Intermediate System (IS) (e.g., a security
front-end device or security gateway). When addressing information is sealed
into the protected header by the integrity or confidentiality services, the
destination End System is assured that the PDU was transmitted from the claimed
source. For a further discussion of the use of SCPS-SP at intermediate systems
see reference [B15].
3.4.2.3.2 The Encapsulated Address field shall contain the following subfields in the
following sequence:
Length in bits
– destination addresses variable
– source address variable
NOTE – The Protected Header Encapsulated Address field is illustrated in figure 3-4.
+-------------------------------------------------+
|             |            |
|  Destination Address  |  Source Address   |
|             |            |
+-------------------------------------------------+
variable         variable
Figure 3-4: Protected Header Encapsulated Address Field
CCSDS 713.5-B-1 Page 3-6 May 1999
22 © ISO 2000 – All rights reserved

CCSDS RECOMMENDATION FOR SCPS SECURITY PROTOCOL (SCPS-SP)
3.4.2.4 Cipher Pad Field
3.4.2.4.1 The Cipher Pad field shall, if included, begin on the next octet boundary
following the location for the Encapsulated Address field, or the Security Classification Label
field if the Encapsulated Address field is not included, or the Protected Header Option Flags
field if neither the Encapsulated Address field nor the Security Classification Label field are
included, and end on an octet boundary.
NOTE – The Cipher Pad field may be used when a particular encipherment or integrity
algorithm requires data blocks to exist on even octet or word boundaries.
3.4.2.4.2 The Cipher Pad field shall contain pad octets each having a numeric value equal
to the number of pad octets.
EXAMPLE – If seven pad octets are needed, the Cipher Pad Field will be filled with seven
octets each having the decimal value seven.
3.4.3 PROTECTED HEADER PROCESSING
3.4.3.1 The protected header shall be enciphered along with the user data when the SCPS-
SP user requests the confidentiality security service or when confidentiality is mandated to
enforce the administrative security policy.
3.4.3.2 If the SCPS-SP user selects the integrity security service, SCPS-SP shall append an
ICV to the PDU (see 3.5).
3.4.3.3 If the SCPS-SP user selects the authentication security service, a copy of the source
and destination addressing information shall be placed into the protected header. This option
shall only be used with the integrity service, confidentiality service, or both.
3.5 INTEGRITY CHECK VALUE FIELD
3.5.1 The Integrity Check Value field shall, if included, begin on an octet boundary
following the location for the User Data field, or the Protected Header if no User Data field is
included, and end on an octet boundary.
3.5.2 The Integrity Check Value field shall contain the results of the integrity algorithm, as
defined by in the SA database, run over the clear header, the protected header,
integ_alg_id
the user data, and a secret key (if required).
3.5.3 The algorithm-dependent length of the ICV shall be stored in the SA database.
NOTE – The specific manner in which the integrity service operates is algorithm
dependent.
CCSDS 713.5-B-1 Page 3-7 May 1999
(Blank page)
24 © ISO 2000 – All rights reserved

CCSDS RECOMMENDATION FOR SCPS SECURITY PROTOCOL (SCPS-SP)
4 PROTOCOL FUNCTIONS
4.1 TRANSMISSION FUNCTIONS
4.1.1 In response to an S-UNITDATA.request primitive (request from an upper-layer
protocol to the SCPS-SP to transmit a PDU), the SCPS-SP shall attempt to identify an SA
database entry based on the source and destination address pair contained in the request.
NOTES
1 Details on the SCPS-SP service primitives are contained in annex D.
2 The SA attributes may be manually pre-placed into a static SA database in the SP-
aware communicating end-points or negotiated through the use of a Security
Association Protocol (SA-P) or a Key Management Protocol (KM-P). The SA-P (or
KM-P) is a separate protocol, typically implemented at the application layer, used to
provide security attribute management. The SA-P is mentioned within this document
so that the relationship between it and SCPS-SP is better understood. The
specification of an SA-P or KM-P is beyond the scope of this Recommendation.
4.1.2 If an SA database entry is not found, the SCPS-SP shall either refuse the request or
invoke an SA-P or KM-P to establish an SA database entry for the communicating systems.
4.1.3 If an SA database entry is found, the SCPS-SP shall use the information contained in
it to create an S-PDU made up of a clear header, a protected header, and the user data.
4.1.4 If authentication is requested, a copy of the source and destination addresses shall be
placed in the protected header. Authentication shall only be used in conjunction with the
integrity service, the confidentiality service, or both.
4.1.5 If a security label is requested (label_req),
a) the SCPS-SP shall ensure that the label’s classification is within the range speci
...