3GPP2 C.S0102-0
Version 1.0
April 2011
HRPD Air Interface Application Layer Security
(AALS) Air Interface Specification
COPYRIGHT
3GPP2 and its Organizational Partners claim copyright in this document and individual
Organizational Partners may copyright and issue documents or standards publications in
individual Organizational Partner’s name based on this document. Requests for
reproduction of this document should be directed to the 3GPP2 Secretariat at
secretariat@3gpp2.org. Requests to reproduce individual Organizational Partner’s
documents should be directed to that Organizational Partner. See www.3gpp2.org for more
information.
This page intentionally left blank.
3GPP2 C.S0102-0 v1.0
CONTENTS
1
FOREWORD ................................................................................................................... ix
2
NOTES ........................................................................................................................... xi
3
REFERENCES ................................................................................................................ xi
4
1
Overview................................................................................................................. 1-1
5
1.1 Scope of This Document ....................................................................................... 1-1
6
1.2 Requirements Language ....................................................................................... 1-1
7
1.3 Architecture Reference Model ............................................................................... 1-1
8
1.4 Protocols .............................................................................................................. 1-2
9
1.4.1
Interfaces ................................................................................................. 1-2
10
1.4.2
States ....................................................................................................... 1-2
11
1.5 Terms .................................................................................................................. 1-3
12
1.6 Notation ............................................................................................................... 1-4
13
2
Introduction ........................................................................................................... 2-1
14
2.1 Architecture Reference Model ............................................................................... 2-1
15
2.2 Key Management.................................................................................................. 2-2
16
17
3
Signaling layer protocol ........................................................................................... 3-1
3.1 Air Interface Application Signaling Encryption/Decryption functions ..................... 3-1
18
3.1.1
Signaling Encryption Key .......................................................................... 3-1
19
3.1.2
Constructing the Cryptosync ..................................................................... 3-1
20
3.1.2.1
RolloverCounter Procedures ................................................................. 3-2
21
3.1.3
Signaling Encryption Procedure ................................................................. 3-3
22
3.1.4
Signaling Decryption Procedures ............................................................... 3-4
23
3.2 Air Interface Application Signaling Integrity functions ........................................... 3-5
24
3.2.1
Signaling Protection Key ............................................................................ 3-5
25
3.2.2
Constructing the Cryptosync ..................................................................... 3-5
26
3.2.3
AUTHENTICATE_ADD_TAG procedures ..................................................... 3-5
27
3.2.4
AUTHENTICATE_CHECK_TAG procedures ................................................. 3-7
28
3.2.5
Authentication Tag .................................................................................... 3-9
29
3.3 Signaling Layer Protocol (SLP) .............................................................................. 3-9
30
3.3.1
Overview ................................................................................................... 3-9
31
3.3.2
Primitives and Public Data ........................................................................ 3-9
32
3.3.3
Protocol Data Unit .................................................................................... 3-9
i
3GPP2 C.S0102-0 v1.0
CONTENTS
3.3.4
1
Procedures ............................................................................................... 3-9
2
3.3.4.1
Reset .................................................................................................. 3-9
3
3.3.4.2
Delivery Layer Procedures ................................................................... 3-9
3.3.4.2.1
4
General Procedures .......................................................................... 3-9
5
3.3.4.2.1.1
Transmitter Requirements .......................................................... 3-9
6
3.3.4.2.1.2
Receiver Requirements ............................................................... 3-9
3.3.4.2.2
7
Best Effort Delivery Procedures ...................................................... 3-10
8
3.3.4.2.2.1
Transmitter Requirements ........................................................ 3-10
9
3.3.4.2.2.2
Receiver Requirements ............................................................. 3-10
3.3.4.2.3
10
Reliable Delivery Procedures .......................................................... 3-10
11
3.3.4.2.3.1
Overview .................................................................................. 3-10
12
3.3.4.2.3.2
Initialization ............................................................................ 3-10
13
3.3.4.2.3.3
Data Transfer........................................................................... 3-10
14
3.3.4.2.3.3.1
Transmit Procedures .......................................................... 3-10
15
3.3.4.2.3.3.2
Receive Procedures ............................................................. 3-10
16
3.3.5
Header Formats ...................................................................................... 3-10
17
3.3.6
Message Formats .................................................................................... 3-11
18
3.3.7
Interface to Other Protocols .................................................................... 3-11
3.4 Protocol Attributes ............................................................................................. 3-11
19
20
3.4.1
Simple Attributes.................................................................................... 3-11
21
3.4.2
Complex Attributes ................................................................................. 3-11
3.4.2.1
22
23
24
4
SigReducedStrengthKey Attribute ...................................................... 3-11
AALS Enhanced Multi-Flow Packet Application........................................................ 4-1
4.1 Introduction ........................................................................................................ 4-1
25
4.1.1
General Overview...................................................................................... 4-1
26
4.1.2
Public Data .............................................................................................. 4-1
27
28
29
4.2 Protocol Initialization ........................................................................................... 4-1
4.3 Procedures and Messages for the InConfiguration Instance of the Packet
Application .......................................................................................................... 4-1
30
4.3.1
Procedures ............................................................................................... 4-1
31
4.3.2
Commit Procedures .................................................................................. 4-1
32
4.3.3
Message Formats ...................................................................................... 4-1
ii
3GPP2 C.S0102-0 v1.0
CONTENTS
1
4.4 Route Selection Protocol ....................................................................................... 4-2
2
4.5 Radio Link Protocol .............................................................................................. 4-2
3
4.5.1
Overview ................................................................................................... 4-2
4
4.5.2
Primitives and Public Data ........................................................................ 4-2
5
4.5.3
Protocol Data Unit .................................................................................... 4-2
6
4.5.4
Procedures and Messages for the InUse Instance of the Protocol ................. 4-2
4.5.4.1
7
Procedures .......................................................................................... 4-2
8
4.5.4.1.1
Constructing the Encryption Key ...................................................... 4-2
9
4.5.4.1.2
Constructing the Cryptosync ............................................................ 4-3
10
4.5.4.1.3
RolloverCounter Procedures.............................................................. 4-4
11
4.5.4.2
Data Transfers .................................................................................... 4-4
12
4.5.4.3
Data Receive Procedures ...................................................................... 4-5
13
4.5.4.4
RLP Packet Header .............................................................................. 4-7
14
4.5.4.5
Message Formats ................................................................................. 4-7
15
4.5.4.6
Interface to Other Protocols ................................................................. 4-7
16
4.5.4.7
RLP Packet Priorities ........................................................................... 4-7
4.5.5
17
Protocol Numeric Constants ...................................................................... 4-7
18
4.6 Data Over Signaling Protocol ................................................................................ 4-7
19
4.7 Location Update Protocol ...................................................................................... 4-7
20
4.8 Flow Control Protocol ........................................................................................... 4-7
21
4.9 Configuration Attributes for the Enhanced Multi-Flow Packet Application .............. 4-7
22
4.9.1
Simple Attributes ...................................................................................... 4-8
23
4.9.2
Complex Attributes ................................................................................... 4-8
4.9.2.1
24
4.10
25
26
27
5
ReducedStrengthCipheringKey Attribute .............................................. 4-9
Session State Information ............................................................................... 4-9
AALS multi-link Multi-Flow Packet Application ....................................................... 5-1
5.1 Introduction ......................................................................................................... 5-1
28
5.1.1
General Overview ...................................................................................... 5-1
29
5.1.2
Public Data ............................................................................................... 5-1
30
31
32
5.2 Protocol Initialization ........................................................................................... 5-1
5.3 Procedures and Messages for the InConfiguration Instance of the Packet
Application .......................................................................................................... 5-1
iii
3GPP2 C.S0102-0 v1.0
CONTENTS
1
5.3.1
Procedures ............................................................................................... 5-1
2
5.3.2
Commit Procedures .................................................................................. 5-1
3
5.3.3
Message Formats ...................................................................................... 5-1
4
5.4 Route Selection Protocol....................................................................................... 5-2
5
5.5 Segmentation and Reassembly Protocol ................................................................ 5-2
6
5.5.1
Overview .................................................................................................. 5-2
7
5.5.2
Primitives and Public Data ........................................................................ 5-2
8
5.5.3
Protocol Data Unit .................................................................................... 5-2
9
5.5.4
Procedures and Messages for the InUse Instance of the Protocol ................ 5-2
10
5.5.4.1
Procedures .......................................................................................... 5-2
11
5.5.4.1.1
Constructing the Encryption Key ..................................................... 5-2
12
5.5.4.1.2
Constructing the Cryptosync ............................................................ 5-3
13
5.5.4.1.3
RolloverCounter Procedures ............................................................. 5-4
14
5.5.4.2
Data Transfers .................................................................................... 5-4
15
5.5.4.2.1
Data Transmit Procedure ................................................................. 5-4
16
5.5.4.2.2
Data Receive Procedures .................................................................. 5-5
17
5.5.4.3
SAR Packet Header ............................................................................. 5-7
18
5.5.4.4
Message Formats ................................................................................ 5-7
19
5.5.4.5
Interface to Other Protocols ................................................................. 5-7
20
5.5.4.6
SAR Packet Priorities........................................................................... 5-7
21
5.5.5
Protocol Numeric Constants ...................................................................... 5-7
22
5.6 Quick Nak Protocol .............................................................................................. 5-7
23
5.7 Data Over Signaling Protocol ................................................................................ 5-7
24
5.8 Location Update Protocol ..................................................................................... 5-7
25
5.9 Flow Control Protocol ........................................................................................... 5-7
26
5.10
Configuration Attributes for the Multi-link Multi-flow Packet Application ......... 5-8
27
5.10.1
Simple Attributes...................................................................................... 5-8
28
5.10.2
Complex Attributes ................................................................................... 5-9
29
30
5.10.2.1
5.11
ReducedStrengthCipheringKey Attribute .............................................. 5-9
Session State Information .............................................................................. 5-9
31
32
iv
3GPP2 C.S0102-0 v1.0
CONTENTS
1
This page intentionally left blank
v
3GPP2 C.S0102-0 v1.0
FIGURES
1
Figure 1-1. Architecture Reference Model ...................................................................... 1-1
2
Figure 2-1. Security Function at the Air Interface Application Layer. ............................. 2-1
3
Figure 3-1. Encryption Function Call ............................................................................ 3-3
4
Figure 3-2. Decryption Procedure Call .......................................................................... 3-4
5
Figure 3-3. AUTHENTICATE_ADD_TAG procedure call payloads .................................... 3-6
6
Figure 3-4. AUTHENTICATE_CHECK_TAG procedure call payloads ................................ 3-8
7
Figure 4-1. Encryption Procedure Call .......................................................................... 4-4
8
Figure 4-2. Decryption Procedure Call .......................................................................... 4-6
9
Figure 5-1. Encryption Procedure Call .......................................................................... 5-4
10
Figure 5-2. Decryption Procedure Call .......................................................................... 5-6
11
vi
3GPP2 C.S0102-0 v1.0
TABLES
1
Table 3-1. Subfield of the Cryptosync .......................................................................... 3-2
2
Table 3-2. Authentication Tag ..................................................................................... 3-9
3
Table 3-3. Configurable Values ................................................................................. 3-11
4
Table 4-1. Subfield of the Cryptosync .......................................................................... 4-3
5
Table 4-2. Configurable Values ................................................................................... 4-8
6
Table 5-1. Subfield of the Cryptosync .......................................................................... 5-3
7
Table 5-2. Configurable Values ................................................................................... 5-8
8
9
vii
3GPP2 C.S0102-0 v1.0
TABLES
1
This page intentionally left blank.
viii
3GPP2 C.S0102-0 v1.0
FOREWARD
1
(This foreword is not part of this Standard)
6
This Standard was prepared by Technical Specification Group C of the Third Generation
Partnership Project 2 (3GPP2). This Standard contains the air interface procedures for the
enhanced security functionality in the High Rate Packet Data (HRPD). This specification
applies to High Rate Packet Data access terminals and access networks which are
enhanced to support increased efficiency and flexibility of security function.
7
This is a supplementary specification to the HRPD air interface specifications.
8
This Standard consists of the following sections:
2
3
4
5
9
1.
General. This section defines the acronyms and terms used in this document.
10
2.
Introduction. This section describes general scope of the Air Interface Application
layer Security function.
3.
Signaling Layer Protocol. This section defines functions that will be invoked by the
Air Interface Application Layer Security, and additional procedures and
requirements for SLP-D specified in [2].
4.
AALS Enhanced Multi-Flow Packet Application. This section defines additional
procedures and requirements for Enhanced Multi-Flow Packet Application in [7].
This specification defines additional procedures and requirements to support Air
Interface Application Security for this new defined sub-type. Unless specified
otherwise, all the procedures defined in [7] also apply to this section..
5.
AALS Multi-Link Multi-Flow Packet Application. This section defines additional
procedures and requirements for Multi-Link Multi-Flow Packet Application in [7].
This specification defines additional procedures and requirements to support Air
Interface Application Security for this new defined sub-type. Unless specified
otherwise, all the procedures defined in [7] also apply to this section.
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
ix
3GPP2 C.S0102-0 v1.0
FOREWORD
1
This page intentionally left blank
x
3GPP2 C.S0102-0 v1.0
REFERENCES
1
2
3
4
5
The following standards contain provisions which, through reference in this text, constitute
provisions of this Standard. At the time of publication, the editions indicated were valid. All
standards are subject to revision, and parties to agreements based on this Standard are
encouraged to investigate the possibility of applying the most recent editions of the
standards indicated below.
6
7
8
9
10
11
[1] C.R1001-H, Administration of Parameter Value Assignments for cdma2000 Spread
Spectrum Standards.
Editor’s Note: The above document is a work in progress and should not be referenced
unless and until it is approved and published. Until such time as this Editor’s Note is
removed, the inclusion of the above document is for informational purposes only.
13
[2] C.S0024-500-C, Application, Stream and Session Layers for cdma2000 High Rate
Packet Data Air Interface Specification.
14
[3]
S.S0078, Common Security Algorithms.
15
[4]
IETF RFC 4493, The AES-CMAC Algorithm.
16
[5]
[CMAC-NIST-SP800-38B] NIST, Special Publication 800-38B, "Recommendation for
Block Cipher Modes of Operation: The CMAC Mode for Authentication", May 2005.
[6]
C.S0067-A v1.0, “Key Exchange Protocols for cdma2000 High Rate Packet Data Air
Interface”, Feb 2009.
20
[7]
C.S0063-B V1.0, cdma2000 High Rate Packet Data Supplemental Services.
21
[8]
S.S0145, Advanced Security Framework for (e)HRPD.
12
17
18
19
24
Editor’s Note: The above document is a work in progress and should not be referenced
unless and until it is approved and published. Until such time as this Editor’s Note is
removed, the inclusion of the above document is for informational purposes only.
25
[9]
22
23
26
27
28
C.S0024-400-C, Connection and Security Layers for cdma2000 High Rate Packet
Data Air Interface Specification.
[10] C.S0087-0, E-UTRAN – cdma2000 HRPD Connectivity and Interworking: Air
Interface Specification.
29
xi
3GPP2 C.S0102-0 v1.0
REFERENCES
1
This page intentionally left blank.
xii
Overview
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
1
1.1
3GPP2 C.S0102-0 v1.0
OVERVIEW
Scope of This Document
These technical requirements form a compatibility standard for Air Interface Application
Security services on cdma2000 high rate packet data systems. These requirements ensure
that a compliant access terminal can obtain service through any access network
conforming to this standard. These requirements do not address the quality or reliability of
that service, nor do they cover equipment performance or measurement procedures.
This specification includes procedures for access terminal and access network to provide Air
Interface Application Security capabilities. The architecture defined by this specification
permits such expansion without the loss of backward compatibility to older access
terminals.
The procedures specified in this document is assumed to be compatible with eHRPD defined
in the [10], unless it is explicitly identified in this document.
1.2
Requirements Language
Compatibility, as used in connection with this standard, is understood to mean: Any access
terminal can obtain service through any access network conforming to this standard.
Conversely, all access networks conforming to this standard can service access terminals.
“Shall” and “shall not” identify requirements to be followed strictly to conform to the
standard and from which no deviation is permitted. “Should” and “should not” indicate that
one of several possibilities is recommended as particularly suitable, without mentioning or
excluding others, that a certain course of action is preferred but not necessarily required, or
that (in the negative form) a certain possibility or course of action is discouraged but not
prohibited. “May” and “need not” indicate a course of action permissible within the limits of
the standard. “Can” and “cannot” are used for statements of possibility and capability,
whether material, physical, or causal.
1.3
Architecture Reference Model
The architecture reference model is presented in Figure 1-1. The reference model consists of
the following functional units:
Um
Sector
Access Terminal
Access Network
29
30
Figure 1-1. Architecture Reference Model
1-1
3GPP2 C.S0102-0 v1.0
1
2
3
The access terminal, the access network, and the sector are formally defined in Section 1.5.
The reference model includes the air interface between the access terminal and the access
network. The protocols used over the air interface are defined in this document.
4
1.4
Protocols
5
1.4.1
Interfaces
6
7
8
Overview
This standard defines a set of interfaces for communications between protocols in the same
entity and between a protocol executing in one entity and the same protocol executing in
the other entity.
10
In the following the generic term “entity” is used to refer to the access terminal and the
access network.
11
Protocols in this specification have four types of interfaces:
9
12

Headers and messages are used for communications between a protocol executing in
one entity and the same protocol executing in the other entity.

Commands are used by a protocol to obtain a service from another protocol within
the same access network or access terminal.

Indications are used by a protocol to convey information regarding the occurrence of
an event to another protocol within the same access network or access terminal. Any
protocol can register to receive these indications.

Public Data is used to share information in a controlled way between
protocols/applications. Public data is shared between protocols/applications in the
same layer, as well as between protocols/applications in different layers. The public
data of the InUse protocol/application is created when an InUse instance of a
protocol/application is created. All configurable attributes of the InConfiguration
instance of a protocol or application are also public data of that protocol or
application.
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
Commands and indications are written in the form of Protocol.Command
Protocol.Indication. When the context is clear, the Protocol part is dropped.
and
Commands are always written in the imperative form, since they direct an action.
Indications are always written in the past tense since they notify of events that happened.
33
Headers and messages are binding on all implementations. Commands, indications, and
public data are used as a device for a clear and precise specification. Access terminals and
access networks can be compliant with this specification while choosing a different
implementation that exhibits identical behavior.
34
1.4.2
30
31
32
35
36
37
38
States
When protocols exhibit different behavior as a function of the environment, this behavior is
captured in a set of states and the events leading to a transition between states.
Unless otherwise specifically mentioned, the state of the access network refers to the state
of a protocol engine in the access network as it applies to a particular access terminal.
1-2
Overview
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
3GPP2 C.S0102-0 v1.0
Since the access network communicates with multiple access terminals, multiple
independent instantiations of a protocol will exist in the access network, each with its own
independent state machine.
Unless otherwise specifically shown, the state transitions due to failure are not shown in
the figures.
Typical events leading to a transition from one state to another are the receipt of a message,
a command from a higher layer protocol, an indication from a lower layer protocol, or the
expiration of a timer.
When a protocol is not functional at a particular time the protocol is placed in a state called
the Inactive state. This state is common for most protocols.
Other common states are Open, indicating that the session or connection (as applicable to
the protocol) is open and Close, indicating that the session or connection is closed.
If a protocol has a single state other than the Inactive state, that state is always called the
Active state. If a protocol has more than one state other than the Inactive state, all of these
states are considered active, and are given individual names.
1.5
Terms
Access Network (AN). The network equipment providing data connectivity between a
packet switched data network (typically the Internet) and the access terminals. An access
network is equivalent to a base station in [9].
Access Terminal (AT). A device providing data connectivity to a user. An access terminal
may be connected to a computing device such as a laptop personal computer or it may be a
self-contained data device such as a personal digital assistant. An access terminal is
equivalent to a mobile station in [9].
Channel. The set of channels transmitted between the access network and the access
terminals within a given frequency assignment. A Channel consists of a Forward Link and a
Reverse Link.
Forward Channel. The portion of the Channel consisting of those Physical Layer Channels
transmitted from the access network to the access terminal.
Forward Control Channel. The channel that carries data to be received by all access
terminals monitoring the Forward Channel.
36
Forward Traffic Channel. The portion of the Forward Channel that carries information for
a specific access terminal. The Forward Traffic Channel can be used as either a Dedicated
Resource or a non-Dedicated Resource. Prior to successful access terminal authentication,
the Forward Traffic Channel serves as a non-Dedicated Resource. Only after successful
access terminal authentication can the Forward Traffic Channel be used as a Dedicated
Resource for the specific access terminal.
37
FCS. Frame Check Sequence.
38
NULL. A value which is not in the specified range of the field.
31
32
33
34
35
1-3
3GPP2 C.S0102-0 v1.0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
Overview
Reservation. Air interface resources set up by the access network to carry a higher layer
flow. A Reservation is identified by its ReservationLabel. ReservationLabels are bound to
Link Flows that carry higher layer flows. A Reservation can be either in the Open or Close
state.
Reverse Access Channel. The portion of the Reverse Channel that is used by access
terminals to communicate with the access network when they do not have a traffic channel
assigned. There is a separate Reverse Access Channel for each sector of the access network.
Reverse Channel. The portion of the Channel consisting of those Physical Layer Channels
transmitted from the access terminal to the access network.
Reverse Traffic Channel. The portion of the Reverse Channel that carries information from
a specific access terminal to the access network. The Reverse Traffic Channel can be used
as either a Dedicated Resource or a non-Dedicated Resource. Prior to successful access
terminal authentication, the Reverse Traffic Channel serves as a non-Dedicated Resource.
Only after successful access terminal authentication can the Reverse Traffic Channel be
used as a Dedicated Resource for the specific access terminal.
17
RLP. Radio Link Protocol provides reliable delivery if needed, in-order delivery if needed,
and duplicate detection for a higher layer data stream.
18
Rx. Receive.
19
Sector. The part of the access network that provides one CDMA channel.
16
20
21
22
SNP. Signaling Network Protocol provides message transmission services for signaling
messages. The protocols that control each layer use SNP to deliver their messages to their
peer protocols. SNP is defined in [2].
25
Stream Layer. The Stream Layer provides multiplexing of distinct streams. Stream 0 is
dedicated to signaling and defaults to the default signaling stream (SNP / SLP). Stream 1,
Stream 2 and Stream 3 are not used by default. The Stream Layer is defined in [2].
26
Tx. Transmit.
23
24
27
1.6
Notation
28
A[i]
The ith element of array A. The zeroeth element of the array is A[0].
29
<e1, e2, …, en>
A
structure
with
elements
‘e1’,
‘e2’,
…,
‘en’.
Two structures E = <e1, e2, …, en> and F = <f1, f2, …, fm> are equal if
and only if ‘m’ is equal to ‘n’ and ei is equal to fi for i=1, …n.
Given E = <e1, e2, …, en> and F = <f1, f2, …, fm>, the assignment “E =
F” denotes the following set of assignments: ei = fi, for i=1, …n.
34
S.e
The member of the structure ‘S’ that is identified by ‘e’.
35
M[i:j]
Bits ith through jth inclusive (i ≥ j) of the binary representation of
variable M. M[0:0] denotes the least significant bit of M.
30
31
32
33
36
1-4
Overview
3GPP2 C.S0102-0 v1.0
|
Concatenation operator. (A | B) denotes variable A concatenated with
variable B.
3

Indicates multiplication.
4
x
Indicates the largest integer less than or equal to x: 1.1 = 1, 1.0 =
1.
x
Indicates the smallest integer greater or equal to x: 1.1 = 2, 2.0 =
2.
8
|x|
Indicates the absolute value of x: |–17|=17, |17|=17.
9

Indicates exclusive OR (modulo-2 addition).
10
min (x, y)
Indicates the minimum of x and y.
11
max (x, y)
Indicates the maximum of x and y.
12
x mod y
Indicates the remainder after dividing x by y: x mod y = x – (y  x/y).
13
Unless otherwise specified, the format of field values is unsigned binary.
1
2
5
6
7
14
15
16
17
18
19
20
21
22
23
24
25
26
27
Unless indicated otherwise, this standard presents numbers in decimal form. Binary
numbers are distinguished in the text by the use of single quotation marks. Hexadecimal
numbers are distinguished by the prefix ‘0x’.
Unless specified otherwise, each field of a packet shall be transmitted in sequence such
that the most significant bit (MSB) is transmitted first and the least significant bit (LSB) is
transmitted last. The MSB is the left-most bit in the figures in this document. If there are
multiple rows in a table, the top-most row is transmitted first. If a table is used to show the
sub-fields of a particular field or variable, the top-most row consists of the MSBs of the
field. Within a row in a table, the left-most bit is transmitted first. Notations of the form
“repetition factor of N” or “repeated N times” mean that a total of N versions of the item are
used.
When a procedure, consisting of a set of steps, is normatively defined as a sequence of
bullet list items, it is assumed that the steps are performed in the indicated order unless
specified otherwise.
28
29
1-5
3GPP2 C.S0102-0 v1.0
1
Overview
This page intentionally left blank.
1-6
3GPP2 C.S0102-0 v1.0
1
2
INTRODUCTION
7
Air Interface Layer Security (AALS) function at the Air Interface Application layer coexists
with security layer functionality defined in [9]. The AALS is defined to be independent of the
Authentication Protocol and the Encryption Protocol defined by the security layer in [9]. For
backwards compatibility purposes and to simplify the key management issue, message
integrity protection functionality at Security layer defined in [9] can co-exist with the
integrity, encryption functionality specified in this document.
8
AALS Function at the Air Interface Application layer consists of the following functionalities:
9

Derivation and management of the cryptographic synchronization value (crypto-sync)
for crypto-processing of transmitted and received Air Interface Application layer data.

Air Interface Application Data and Signaling Encryption, and Signaling Integrity
Protection.
2
3
4
5
6
10
11
12
13
14
2.1
Architecture Reference Model
Placement of the AALS Function at the Air Interface Application Layer is shown on the.
Application Layer
AALS
EMFPA
AALS
MFMLPA
SLP
Stream Layer
Session Layer
Connection Layer
Security Layer
MAC Layer
Physical Layer
15
16
17
Figure 2-1. Security Function at the Air Interface Application Layer.
The security for packet application subtype is negotiated per flow.
18
19
20
21
22
The AALS function utilizes the crypto-sync for all crypto-processing to provide the replay
protection for processed data. Derivation and maintenance of crypto-sync assures that each
and every byte of processed data is crypto-processed using unique and non-repeating
cryptographic constants applicable exclusively for this byte. The crypto-sync is
2-1
3GPP2 C.S0102 v1.0
2
independently derived at the communicating peers, and is not transmitted over the air
interface.
3
Security Function at Air Interface Application layer consists of following capabilities:
4

Air Interface Application Layer Security Enhanced Multi-Flow Packet Application
5

Air Interface Application Layer Security multi-link Multi-Flow Packet Application
6

Air Interface Application Signaling Encryption Function
7

Air Interface Application Signaling Integrity Function
1
8
9
10
11
12
13
14
15
16
2.2
Key Management
Session security keys for the AALS, such as signaling protection key (SigKey) and RLP
packet data protection key (DataKey[i]), are derived from the keys provided by the Key
Exchange Protocol as specified in [8]. When the AALS function receives indication
RouteUpdate.ConnectionInitiated from the lower layer, the AALS shall derive session keys for
AALS as specified in the following.
When one set of keys is provided by the Key Exchange Protocol [6], the AALS session keys
are computed as follows:
-
SKeyTemp =
(FACAuthKey|FPCAuthKey|RACAuthKey|RPCAuthKey|FACEncKey|FPCEncKey
|RACEncKey| RPCEncKey)
-
SigKey = ehmacsha256(key=SKeyTemp, key_length=256 in units of octets,
message = “AALS Signaling Key”, message_length = length of message in units of
bits, message_offset=0, MAC_length = 16), where the ehmacsha256 function is
specified in [3]
-
SigIntegrityKey = ehmacsha256(key=SKeyTemp, key_length=256 in units of
octets, message = “AALS Signaling Integrity Key”, message_length = length of
message in units of bits, message_offset=0, MAC_length = 16), where the
ehmacsha256 function is specified in [3]
-
DataKey = ehmacsha256(key = SKeyTemp, key_length = 256 in units of octets,
message = “AALS Data Key]”, message_length = length of message in units of
bits, message_offset = 0, MAC_length=16), where the ehmacsha256 function is
specified in [3], and DataKey with index i is used for multiple copies of RLP.
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
All the variables used to create SKeyTemp are public data of Key Exchange Protocol [9], [6].
32
2-2
3GPP2 C.S0102-0 v1.0
1
2
3
4
5
6
7
8
9
10
3
SIGNALING LAYER PROTOCOL
This section defines security functions that will be invoked by the Signaling Link Protocol
(SLP) and additional procedures and requirements for SLP-D specified in [2]. Unless
specified otherwise, the procedures in the sections 1.6 of [2] also apply.
Encryption/Decryption procedure for signaling application is defined in section 3.1.
Signaling integrity protection procedure signaling application is defined in section 3.2.
3.1
Air Interface Application Signaling Encryption/Decryption functions
The Air Interface Application Signaling Encryption/Decryption Functions shall use the AES
(a.k.a. Rijndael) procedures defined in [3] in order to encrypt and decrypt the Air Interface
Application Layer signaling packets.
16
If the SignalingProtection attribute is set to 0x02, then the SLP-D messages shall be
encrypted/decrypted based on the procedure defined in this section. The signaling packet
shall be encrypted by the transmitter using the AES algorithm in a counter mode [3].
Because all required cryptographic configuration parameters are either provided by other
protocols (session encryption keys) or internally derived by the AALS function (cryptosync),
no additional headers are required for crypto-processing the signaling packet.
17
3.1.1
11
12
13
14
15
18
19
Signaling Encryption Key
The Air Interface Application Signaling Encryption/Decryption shall construct the signaling
encryption keys as follows:

22
If the value of SignalingProtection attribute is equal to 0x02, then the Air Interface
Application Signaling Encryption/Decryption Key function shall construct the
signaling protection key SigEncryptionKey as follows:
23
Call the KeyStrengthRedAlg procedure specified in [3] with its inputs set as follows:
20
21
24
 Set the KeyLength to 16.
25
 Set the OriginalKey to the value of the SigKey as specified in section 2.2.
26
 Set the SaltLength to the value of the SigSaltLength parameter.
27
 Set the Salt to the value of the SigSalt parameter.
28
 Set the KeyEntropy to the value of the SigKeyEntropy parameter.
When the KeyStrengthRedAlg procedure returns, set the SigEncryptionKey to
RedStrengthKey which is the output of the KeyStrengthRedAlg procedure.
29
30
31

32
33
If the value of SignalingProtection attribute is equal to 0x01 or 0x02, then the Air
Interface Application Signaling Integrity Key, SigIntegrityKey, shall be constructed
as in section 2.2.
34
3.1.2
Constructing the Cryptosync
35
The Function shall construct the Cryptosync as shown in Table 3-1.
3-1
3GPP2 C.S0102-0 v1.0
1
Table 3-1.
2
Subfield of the Cryptosync
Subfield
Length (bits)
FunctionCode
2
Direction
1
Reserved
5
RolloverCounter
34
ResetCounter
8
VirtualSequenceNumber
22
FunctionCode
This field shall be set to ‘01’ to indicate Signaling Encryption
function. It shall be set to ‘10’ to indicate Signaling Integrity
function.
Direction
If the payload is for Forward Link then this field shall be set to
‘0’. Otherwise, this field shall be set to ‘1’.
8
Reserved
All the bits in this field shall be set to ‘0’.
9
RolloverCounter
This field shall be constructed and maintained by the Access
Network and Access Terminal as described in 3.1.2.1.
ResetCounter
This field shall be set to the number of occurrence of SLP
reset.
VirtualSequenceNumber
This field shall be set to the SequenceNumber in the SLP-D
header. It is pre-padded with zeros if the size of
SequenceNumber is less than 22-bit.
3
4
5
6
7
10
11
12
13
14
15
16
3.1.2.1 RolloverCounter Procedures
19
The RolloverCounter shall be reset to zero when the session key changes. When the
RolloverCounter approaches its maximum value, the session key SigEncryptionKey shall be
changed.
20
The RolloverCounter is incremented when the VirtualSequenceNumber is rolled over.
17
18
21
22
23
24
25
26
27
To avoid repetition of the cryptosync at the time of connection re-establishment, the
RolloverCounter shall be incremented by the Access Network when the RTCAck message is
received from the Access Terminal, and the RolloverCounter shall be incremented by the
Access Terminal when the reception of the RTCAck message is confirmed by the Access
Network.
In a rare cases when connection fails right after the Access Network receives the RTCAck
message, the Access Terminal may not receive confirmation of its reception by the Access
3-2
3GPP2 C.S0102-0 v1.0
4
Network, mis-synchronization of the RolloverCounter may occur. To recover from this rare
error condition, the session key change and RolloverCounter reset procedure may be used.
For example. the Access Terminal and Access Network may decide to close and re-open the
session.
5
3.1.3
1
2
3
6
7
8
Signaling Encryption Procedure
The procedure shall provide service of encrypting the signaling payload. Figure 3-1
illustrates the relationship between an Input Payload and an Output Payload after
processing the signaling packet.
9
SLP-D
Header
SLP-D
Header
SNP Packet
Encrypted InputPayload
Octet-aligned
OutputPayload
10
Figure 3-1. Encryption Function Call
11
12
13
14
15
16
The function shall process the SNP signaling packet as follows:

If the SignalingProtection attribute is equal to 0x02, the function shall perform the
following:
The function shall call the ESP_AES procedure specified in [3] with its inputs set as
follows:
17

Set the key to the SigEncryptionKey as specified in 3.1.1.
18

Set fresh to the value of the Cryptosync under consideration.
Cryptosync is calculated as specified in 3.1.2.

Set the freshsize to the value of the CryptosyncLength for the packet to be
encrypted.

Set the buf to the address of the beginning of the memory space that
contains the signaling packet.
24

Set the bit_offset to zero.
25

Set the bit_count to the length of the signaling packet in bits.
19
20
21
22
23
3-3
The
3GPP2 C.S0102-0 v1.0
After the ESP_AES procedure is returned, the function shall set the signaling
packet to the output of the ESP_AES procedure which starts at the memory
space specified by buf and is of the same size as the signaling packet.
1
2
3
4

5
6
7
8
9
3.1.4
If the SignalingProtection attribute is equal to 0x00 or 0x01, the function shall set
the output packet to the signaling packet.
Signaling Decryption Procedures
The procedure shall provide service of decrypting the payload from signaling layer. Figure
3-2 illustrates the relationship between an Input Payload and the Output Payload after
processing the payload.
10
InputPayload
SLP-D
Header
Encrypted Payload
Octet-aligned
SLP-D
Header
SNP Packet
11
Figure 3-2. Decryption Procedure Call
12
13
14
15
16
17
If the signaling Layer packet is received, then the receiver shall perform the following:

If the SignalingProtection attribute is equal to 0x02, the function shall perform the
following:
The Air Interface Application Signaling Encryption Function shall call the ESP_AES
procedure specified in [3] with its inputs set as follows:
18

Set the key to the SigEncryptionKey as specified in 3.1.1.
19

Set fresh to the value of the Cryptosync. The Cryptosync is calculated as
specified in 3.1.2.
21

Set the freshsize to the value of the CryptosyncLength.
22

Set the buf to the address of the beginning of the memory space that
contains the signaling packet, .
24

Set the bit_offset to zero.
25

Set the bit_count to the length of the signaling packet in bits.
20
23
3-4
3GPP2 C.S0102-0 v1.0
After the ESP_AES procedure is returned, the procedure shall set signaling packet
to the output of the ESP_AES procedure which starts at the memory space
specified by buf and is of the same size as the signaling packet.
1
2
3

4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
3.2
If the SignalingProtection attribute is equal to 0x00 or 0x01, the Air Interface
Application Signaling Encryption Function shall set the signaling packet to the
input packet.
Air Interface Application Signaling Integrity functions
If the SignalingProtection attribute is set to 0x01 or 0x02, then the AT and AN shall follow
the signaling integrity protection procedures defined in this section.
Air Interface Application Signaling Integrity Function employs the explicit Message
Authentication Code to provide a method for integrity protection of signaling messages by
applying the AES CMAC function (see [3], and [4]).
The transmitting function appends the Authentication Tag to the signaling message in SLPD and forwards it to the next procedure for processing.
When the receiving function receives packet for processing, it calculates the message
Authentication Tag and compares the computed value with the one received. If match, the
Authentication Tag will be removed and the remaining packet is delivered to SNP for
processing.
21
When the signaling packet is both Integrity and Encryption protected, the sender shall first
encrypt the packet and then integrity protect the packet. The receiver shall check the
integrity of the signaling packet and then decrypt the packet.
22
3.2.1
23
The Signaling Protection Key is constructed using procedure in 3.1.1.
24
3.2.2
25
The Cryptosync is constructed using procedure in 3.1.2.
26
3.2.3
27

19
20
28
Signaling Protection Key
Constructing the Cryptosync
AUTHENTICATE_ADD_TAG procedures
AUTHENTICATE_ADD_TAG
-
29
Inputs: Direction, RolloverCounter, SequenceNumber, InputPayloadSize,
InputPayload.
The inputs Direction, RolloverCounter, and SequenceNumber are used for
cryptosync calculation.
30
31
32
-
Outputs: OutputPayloadSize, OutputPayload
33
-
Possible values of each input and output are as follows:
34

Direction – ‘0’ (ForwardLink) or ‘1’ (ReverseLink)
35

RolloverCounter – 34-bit hexadecimal number
3-5
3GPP2 C.S0102-0 v1.0

ResetCounter – 8-bit hexadecimal number, which is the number of occurrence of
SLP reset

SequenceNumber – Hexadecimal number of n bits, where n is less than or equal
to 22
5

InputPayloadSize – Input payload size in octets
6

InputPayload – Input payload
7

OutputPayloadSize – Output payload size in octets
8

OutputPayload – Output payload
1
2
3
4
9
10
11
The function shall provide service of adding Authentication Tag through
AUTHENTICATE_ADD_TAG procedure call. Figure 3-3 illustrates the relationship between
an InputPayload and an OutputPayload of AUTHENTICATE_ADD_TAG procedure call.
Payload from SNP
Authentication
Tag
InputPayload
Octet-aligned
OutputPayload
12
Figure 3-3. AUTHENTICATE_ADD_TAG procedure call payloads
13
14
Upon reception of an signaling packet, the procedure shall perform the following steps:
15

16
If the SignalingProtection field is set to 0x00, then AUTHENTICATE_ADD_TAG
procedure shall set the outputs of the AUTHENTICATE_ADD_TAG procedure as follows:
17
-
Set OutputPayload to InputPayload.
18
-
Set OutputPayloadSize to size of InputPayload in octets.

20
Otherwise, the AUTHENTICATE_ADD_TAG procedure shall call the CMAC(K, M, Mlen,
Tlen) procedure specified in [5] with its inputs set as follows:
21
-
Set the K to the Air Interface Application Signaling protection key SigIntegrityKey
constructed as specified in Section 3.1.1.
-
24
Set the M to B0 Header|B0| OutputPayload, where B0 Header and B0 are set as
follows:
25

19
22
23
Set B0 Header to ‘10011100’.
3-6
3GPP2 C.S0102-0 v1.0

1
2
3
Set B0 to (fresh | L), where fresh is set to the value of the Cryptosync that is
constructed as specified in 3.1.2, and L is set to size of the OutputPayload in
octets expressed as 32-bit hexadecimal number.
4
-
Set the Mlen to 8 times the size of M in octets.
5
-
Set the Tlen to 32.
7
then, the AUTHENTICATE_ADD_TAG procedure
AUTHENTICATE_ADD_TAG procedure as follows:
8

Construct Authentication Tag by setting the AuthTag field to the output of the CMAC
procedure.
10

Set OutputPayload to (InputPayload | Authentication Tag).
11

Set OutputPayloadSize to (InputPayloadSize + size of the Authentication Tag in octets).
12
3.2.4
13

6
9
14
shall
set
the
outputs
of
the
AUTHENTICATE_CHECK_TAG procedures
AUTHENTICATE_CHECK_TAG
-
Inputs: Direction, SequenceNumber, RolloverCounter, InputPayloadSize, InputPayload.
The inputs Direction, RolloverCounter, and SequenceNumber are used for
cryptosync calculation.
15
16
17
-
Outputs: TagMatched, OutputPayloadSize, OutputPayload
18
-
Possible values of each input and output are as follows:
19

Direction – ‘0’ (ForwardLink) or ‘1’ (ReverseLink)
20

RolloverCounter – 34-bit hexadecimal number
21

ResetCounter – 8-bit hexadecimal number, which is the number of occurrence of
SLP reset

SequenceNumber – Hexadecimal number of n bits, where n is less than or equal
to 22.
25

InputPayloadSize – Input payload size in octets
26

InputPayload – Input payload
27

TagMatched – ‘1’ (TRUE), ‘0’ (FALSE)
28

OutputPayloadSize – Output payload size in octets
29

OutputPayload – Output payload
22
23
24
30
31
32
33
34
35
If the AUTHENTICATE_CHECK_TAG returns TagMatched with FALSE, the signaling
message should be silently discarded.
The function shall provide service of checking Authentication Tag through
AUTHENTICATE_CHECK_TAG procedure call. Figure 3-4 illustrates the relationship
between an InputPayload and an OutputPayload of AUTHENTICATE_CHECK_TAG
procedure call.
3-7
3GPP2 C.S0102-0 v1.0
InputPayload
OutputPayload
Authentication
Tag
Octet-aligned
Output Payload
1
Figure 3-4. AUTHENTICATE_CHECK_TAG procedure call payloads
2
3
The AUTHENTICATE_CHECK_TAG procedure shall perform the following:
4

5
If the SignalingProtection is set to 0x00, then AUTHENTICATE_CHECK_TAG procedure
shall set the outputs of the AUTHENTICATE_CHECK_TAG procedure as follows:
6
-
Set TagMatched to TRUE.
7
-
Set OutputPayloadSize to size of OutputPayload in octets.
8

9
10
Otherwise, the AUTHENTICATE_CHECK_TAG procedure shall call the CMAC(K, M,
Mlen, Tlen) procedure specified in [5] with its inputs set as follows:
-
Set the K to the Air Interface Application Signaling Protection key SigIntegrityKey
constructed as specified in Section 3.1.1.
-
Set the M to B0Tag|B0| OutputPayload, where B0Tag and B0 are set as follows:
11
12
13

Set B0Tag to ‘10011100’.
14

Set B0 to (fresh | L), where fresh is set to the value of the Cryptosync
constructed as specified in 3.1.2, and L is set to size of the OutputPayload in
octets expressed as 32-bit hexadecimal number.
15
16
17
-
Set the Mlen to 8 times size of M in octets.
18
-
Set theTlen to 32.
19

The InputPayload consists of (OutputPayload | Authentication Tag).
20

The AUTHENTICATE_CHECK_TAG procedure shall remove Authentication Tag from
InputPayload to produce OutputPayload.

23
After the CMAC procedure is returned, the AUTHENTICATE_CHECK_TAG procedure
shall set the outputs of the AUTHENTICATE_CHECK_TAG procedure as follows:
24
-
If output of the CMAC procedure matches the Authentication Tag, then set
TagMatched to TRUE. Otherwise, set TagMatched to FALSE.
-
Set OutputPayloadSize to size of OutputPayload in octets.
21
22
25
26
3-8
3GPP2 C.S0102-0 v1.0
1
2
3
3.2.5
Authentication Tag
The Authentication Tag field, which is appended to the payload, has the following format, as
shown in Table 3-2.
Table 3-2.
4
Authentication Tag
Field
Length (bits)
AuthTag
5
AuthTag
6
7
8
0 or 32
If the SignalingProtection is set to 0x01 or 0x02, the function
shall include this field and set it to the outputs of 32 MSB of
CMAC procedure call. Otherwise, if the SignalingProtection is
set to 0x00, this field shall be omitted.
9
10
3.3
11
3.3.1
12
Procedures specified in [2] apply here.
13
3.3.2
14
Procedures specified in [2] apply here.
15
3.3.3
16
Procedures specified in [2] apply here.
17
3.3.4
18
19
20
Signaling Layer Protocol (SLP)
Overview
Primitives and Public Data
Protocol Data Unit
Procedures
3.3.4.1 Reset
Procedures specified in [2] apply here.
3.3.4.2 Delivery Layer Procedures
21
Procedures specified in [2] apply here.
22
3.3.4.2.1 General Procedures
23
Procedures specified in [2] apply here.
24
3.3.4.2.1.1 Transmitter Requirements
25
Procedures specified in [2] apply here.
26
3.3.4.2.1.2 Receiver Requirements
27
Procedures specified in [2] apply here.
3-9
3GPP2 C.S0102-0 v1.0
1
3.3.4.2.2 Best Effort Delivery Procedures
2
Procedures specified in [2] apply here.
3
3.3.4.2.2.1 Transmitter Requirements
4
Procedures specified in [2] apply here.
5
3.3.4.2.2.2 Receiver Requirements
6
Procedures specified in [2] apply here.
7
3.3.4.2.3 Reliable Delivery Procedures
8
3.3.4.2.3.1 Overview
9
Procedures specified in [2] apply here.
10
3.3.4.2.3.2 Initialization
13
In addition to procedures specified in [2]. The access terminal and the access network shall
perform the session key construction procedure specified in section 3.1.1, if the protocol
receives a RouteUpdate.ConnectionInitiated indication.
14
3.3.4.2.3.3 Data Transfer
15
3.3.4.2.3.3.1 Transmit Procedures
11
12
16
17
18
In addition to the procedure specified in [2], the following procedures here shall be also
applied in sequence if the SignalingProtection set to 0x01or 0x02:

Invoke the AALS Signaling Integrity Protection AUTHENTICATE_ADD_TAG
procedures specified in the section 3.2.3 if SignalingProtection attribute set to 0x01
or 0x02;

Invoke the AALS Signaling Encryption Procedure specified in the section 3.1.3 if
SignalingProtection attribute set to 0x02;
19
20
21
22
23
24
25
26
27
3.3.4.2.3.3.2 Receive Procedures
In addition to the procedure specified in the section 1.6.4.2.3.3.2 of [2], the following
procedures here shall be also applied in sequence if the SignalingProtection attribute set to
0x01 or 0x02:

Invoke the AALS Signaling Decryption Procedure specified in the section 3.1.4 if
SignalingProtection attribute set to 0x02;

Invoke the AALS Signaling Integrity Protection AUTHENTICATE_CHECK_TAG
procedures specified in the section 3.2.4 if SignalingProtection attribute set to 0x01
or 0x02;
28
29
30
31
32
3.3.5
Header Formats
33
Procedures specified in [2] apply here.
3-10
3GPP2 C.S0102-0 v1.0
1
3.3.6
2
Procedures specified in [2] apply here.
3
3.3.7
4
Procedures specified in [2] apply here.
5
3.4
Message Formats
Interface to Other Protocols
Protocol Attributes
6
This is a new section in addition to [2]
7
3.4.1
8
The Table 3-3 defines new simple configuration attributes associated with this application:
9
10

Simple Attributes
SignalingProtection
The default value for the attribute is typed in bold italics.
Table 3-3.
11
Attribute
ID
0xffff
12
13
14
15
3.4.2
Attribute
SignalingProte
ction
Configurable Values
Values
Meaning
0x00
The SLP-D signaling packets shall
be not integrity and encryption
protected by the sender.
0x01
The SLP-D signaling packets shall
be integrity protected by the sender
and shall be validated by the
receiver.
0x02
The SLP-D signaling packets shall
be both integrity and encryption
protected by the sender and shall be
decrypted and validated by the
receiver.
0x03-0xff
Reserved
Complex Attributes
The following complex attributes are defined for reduction of the Signaling Protection key
strength.
3.4.2.1 SigReducedStrengthKey Attribute
16
3-11
3GPP2 C.S0102-0 v1.0
Field
Length (bits)
Length
Default Value
8
N/A
16
N/A
ValueID
8
N/A
SigSaltLength
8
0
AttributeID
SigSalt
SigSaltLength × 8
SigKeyEntropy
8
N/A
16
Length
Length of the complex attribute in octets. The sender shall set this
field to the length of the complex attribute excluding the Length field.
3
AttributeID
The sender shall set this field to the value of 0x0000.
4
ValueID
The sender shall set this field to an identifier assigned to this complex
value.
SigSaltLength
The sender shall set this field to the length of the SigSalt field in
octets.
SigSalt
The sender shall set this field to the value of the SigSalt input
parameter that is to be used in the KeyStrengthRedAlg procedure
specified in [3] for the signaling integrity key.
SigKeyEntropy
The sender shall set this field to the value of the SigKeyEntropy input
parameter that is to be used in the KeyStrengthRedAlg procedure
specified in [3] for the Signaling Encryption key SigEncryptionKey.
The valid values for this field are 0 through 16, inclusive.
1
2
5
6
7
8
9
10
11
12
13
14
3-12
3GPP2 C.S0102-0 v1.0
1
4
AALS ENHANCED MULTI-FLOW PACKET APPLICATION
2
4.1
3
4.1.1
4
5
6
7
8
9
10
11
Introduction
General Overview
The following text serves as introduction to the expanded functionality of EMFPA specified
in [7].
This section defines additional procedures and requirements for Enhanced Multi-Flow
Packet Application in [7]. This specification defines additional procedures and requirements
to support Air Interface Application Security for this new defined sub-type. Unless specified
otherwise, all the procedures defined in [7] also apply to this section.
The Air Interface Application Data Encryption uses the AES (a.k.a. Rijndael) procedures
defined in [3] in order to encrypt and decrypt the EMFPA packets.
18
Air Interface Application Data encryption can be applied selectively to individual link flows.
That is, depending on session configuration, some link flows may be encrypted, while others
are not. Encryption mode is individually configured for each link flow during the negotiation
of link flow. Each RLP block is encrypted by the transmitter using the AES algorithm in a
counter mode. Because all required cryptographic configuration parameters are either
provided by other protocols (session encryption keys) or internally derived (cryptosync), no
additional headers are required for crypto-processing the data.
19
4.1.2
20

21
This new subtype value is defined in [1].
12
13
14
15
16
17
22
23
24
Public Data
Subtype for this application.
4.2
Protocol Initialization
Procedures specified in [7] apply here.
4.3
25
Procedures and Messages for the InConfiguration Instance of the Packet
Application
26
4.3.1
Procedures
27
The procedures specified in [7] apply here.
28
4.3.2
29
Procedures specified in [7] apply here.
30
4.3.3
31
Procedures specified in [7] apply here.
Commit Procedures
Message Formats
4-1
3GPP2 C.S0102-0 v1.0
1
2
3
4.4
Route Selection Protocol
Procedures specified in [7] apply here.
4.5
Radio Link Protocol
4
Procedures specified in [7] apply here.
5
4.5.1
Overview
6
4.5.2
Primitives and Public Data
7
4.5.3
Protocol Data Unit
8
4.5.4
Procedures and Messages for the InUse Instance of the Protocol
9
10
11
12
13
14
15
16
17
18
19
20
21
22
4.5.4.1 Procedures
In addition to the procedures specified in [7], the following procedure apply.
When forward Link Flow NN is activated, the access network and the access terminal shall
not update the following attributes:

FlowNNFwdEncryptionProtection
When reverse Link Flow NN is activated, the access network and the access terminal shall
not update the following attributes:

FlowNNRevEncryptionProtection
4.5.4.1.1 Constructing the Encryption Key
In addition to procedures specified in [7] the access terminal and the access network shall
perform the following session key construction procedure, if the protocol receives a
RouteUpdate.ConnectionInitiated indication.
The Air Interface Application Data Encryption Protocol shall construct the encryption keys
as follows:

26
If
the
value
of
any
FlowNNFwdEncryptionProtection
or
FlowNNRevEncryptionProtection attribute is equal to 0x01, then the Air Interface
Application Data Encryption Function shall construct the encryption key for the
forward flow NN DataEncryptionKey as follows:
27
Call the KeyStrengthRedAlg procedure specified in [3] with its inputs set as follows:
23
24
25
28
 Set the KeyLength to 16.
29
 Set the OriginalKey to the value of the DataKey as specified in 2.2.
30
 Set the SaltLength to the value of the SaltLength parameter.
31
 Set the Salt to the value of the Salt parameter.
32
 Set the KeyEntropy to the value of the KeyEntropy parameter.
4-2
3GPP2 C.S0102-0 v1.0
When the KeyStrengthRedAlg procedure returns, set the DataEncryptionKey to
RedStrengthKey which is the output of the KeyStrengthRedAlg procedure if
FlowNNFwdEncryptionProtection or FlowNNRevEncryptionProtection is set to
0x01.
1
2
3
4
5
4.5.4.1.2 Constructing the Cryptosync
6
The RLP shall construct the Cryptosync as shown in Table 4-1.
Table 4-1.
7
Subfield of the Cryptosync
Subfield
Flow
Length (bits)
FunctionCode
2
Direction
1
Reserved
5
FlowID
8
StreamID
8
RolloverCounter
34
VirtualSequenceNumber
22
8
FunctionCode
This field shall be set to ‘00’ to indicate Ciphering function.
9
Direction
If the payload being encrypted or decrypted is for Forward
Link then this field shall be set to ‘0’. Otherwise, this field
shall be set to ‘1’. Direction is received as Direction input to
ENCRYPT and DECRYPT procedure calls.
13
Reserved
All the bits in this field shall be set to ‘0’.
14
FlowID
This field shall be set to the LinkFlowNumber corresponding
to the payload being encrypted or decrypted. FlowID is
received as FlowID input to ENCRYPT and DECRYPT
procedure calls.
StreamID
The two LSBs of this field shall be set to the stream ID to
which the application subtype is associated with. The
remaining bits are set to ‘0’..
RolloverCounter
This field shall be constructed and maintained by the Access
Network and Access Terminal as described in 3.1.2.1.
VirtualSequenceNumber
For the octet stream, this field shall be set as follows: For the
first block, this field shall be set to the value of a Sequence
Number of the RLP packet (SEQ) included in the RLP header,
10
11
12
15
16
17
18
19
20
21
22
23
24
25
4-3
3GPP2 C.S0102-0 v1.0
divided by 16. For each subsequent block, this value shall be
incremented by 1. For packet stream, this field shall be set to
the packet sequence number in the packet header.
1
2
3
4
4.5.4.1.3 RolloverCounter Procedures
5
The RolloverCounter is as specified as 3.1.2.1.
6
4.5.4.2
7
8
9
10
Data Transfers
The Data Transfer function shall provide service of encrypting the payload from the Air
Interface Application Layer. Figure 4-1 illustrates the relationship between an Input
Payload and an Output Payload after processing with the Air Interface Application Data
Encryption capability.
11
RLP
Header
RLP
Header
Payload from
Application Layer
Encrypted InputPayload
Octet-aligned
OutputPayload
12
Figure 4-1. Encryption Procedure Call
13
14
15
16
17
18
19
20
21
22
23
The Air Interface Application Data Encryption Function shall perform the following
procedure for each of the flows:

If the Encryption attribute for the flow under consideration (e.g.,
FlowNNFwdEncryptionProtection) is equal to 0x01, the function shall perform the
following:
For the octet stream, the RLP packet shall be divided into 16 byte blocks and the
cryptosync calculated for each block using the procedure defined in 4.5.4.1.2. If
the sequence number from the packet header is not at the 16 byte boundary, the
first AES block shall be selected to make the second AES block starting from 16
byte boundary.
4-4
3GPP2 C.S0102-0 v1.0
The function shall call the ESP_AES procedure specified in [3] with its inputs set as
follows:
1
2
3

Set the key to the Encryption Key for the flow under consideration(e.g.,
DataEncryptionKey) as specified in 4.5.4.1.1.

Set fresh to the value of the Cryptosync for the flow under consideration.
The Cryptosync is calculated as specified in 4.5.4.1.2.

Set the freshsize to the value of the CryptosyncLength for the flow under
consideration.

Set the buf to the address of the beginning of the memory space that
contains the Air Interface Application Layer packet.

Set the bit_offset to zero if the sequence number from the packet header is at
the 16 byte boundary. If the sequence number from the packet header is not
at the 16 byte boundary, the bit_offset shall be set to the value that points to
the first bit of the payload in the first AES block. For packet stream, the
bit_offset shall be set to zero.

Set the bit_count to the length of the Air Interface Application Layer Packet in
bits.
4
5
6
7
8
9
10
11
12
13
14
15
16
17
After the ESP_AES procedure is returned, the function shall set the Stream Layer
packet to the output of the ESP_AES procedure which starts at the memory
space specified by buf and is of the same size as the Air Interface Application
Layer packet.
18
19
20
21
22

23
24
If the Encryption attribute for the flow under consideration (e.g.,
FlowNNFwdEncryptionProtection) is equal to 0x00, the function shall set the Stream
Layer packet to the Air Interface Application Layer packet.
25
4.5.4.3
26
This is a new procedures that is not specified in the section 2.5 of [7].
27
28
29
Data Receive Procedures
The data receive procedure shall provide service of decrypting the payload from Streaming
Layer. Figure 4-2 illustrates the relationship between an Input Payload and the Output
Payload after processing the payload at Air Interface Application Encryption function.
30
4-5
3GPP2 C.S0102-0 v1.0
InputPayload
RLP
Header
Encrypted Payload
Octet-aligned
RLP
Header
Decrypted Payload
1
Figure 4-2. Decryption Procedure Call
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
If the Stream Layer packet is received, then the receiver shall construct the Air Interface
Application Layer packet from the Stream Layer packet by performing the following
procedure for each of the flows:

If the Encryption attribute for the flow under consideration (e.g.,
FlowNNFwdEncryptionProtection) is equal to 0x01, the Air Interface Application
Data Encryption Function shall perform the following:
For the octet stream, the RLP packet shall be divided into 16 byte blocks and the
cryptosync calculated for each block using the procedure defined in 4.5.4.1.2. If
the sequence number from the packet header is not at the 16 byte boundary, the
first AES block shall be selected to make the second AES block starting from 16
byte boundary.
The Air Interface Application Data Encryption Function shall call the ESP_AES
procedure specified in [3] with its inputs set as follows:

Set the key to the DataEncryptionKey for the flow under consideration as
specified in section 4.5.4.1.1.

Set fresh to the value of the Cryptosync for the flow under consideration. The
Cryptosync is calculated as specified in 4.5.4.1.2.

Set the freshsize to the value of the CryptosyncLength for the flow under
consideration.

Set the buf to the address of the beginning of the memory space that
contains the Stream Layer packet.
17
18
19
20
21
22
23
4-6
3GPP2 C.S0102-0 v1.0
1

Set the bit_offset to zero if the sequence number from the RLP header is at
the 16 byte boundary. If the sequence number from the RLP header is not at
the 16 byte boundary, the bit_offset shall be set to the value that points to
the first bit of the payload in the first AES block. For packet stream, the
bit_offset shall be set to zero.

Set the bit_count to the length of the Stream Layer Packet in bits.
2
3
4
5
6
After the ESP_AES procedure is returned, the function shall set the Air Interface
Application Layer packet to the output of the ESP_AES procedure which starts at
the memory space specified by buf and is of the same size as the Stream Layer
packet.
7
8
9
10
11

12
13
14
15
16
17
18
19
20
21
If the Encryption attribute for the flow under consideration (e.g.,
FlowNNFwdEncryptionProtection) is equal to 0x00, the Air Interface Application
Data Encryption Function shall set the Air Interface Application Layer packet to the
Stream Layer packet.
4.5.4.4 RLP Packet Header
No changes from [7].
4.5.4.5 Message Formats
No changes from [7].
4.5.4.6 Interface to Other Protocols
No changes from [7].
4.5.4.7 RLP Packet Priorities
22
No changes from [7].
23
4.5.5
24
4.6
25
26
27
28
29
30
31
32
33
Protocol Numeric Constants
Data Over Signaling Protocol
Data Over Signaling uses best effort messages. So signaling protection can not be applied.
4.7
Location Update Protocol
Procedures specified in [7] apply here.
4.8
Flow Control Protocol
Procedures specified in [7] apply here.
4.9
Configuration Attributes for the Enhanced Multi-Flow Packet Application
In addition to procedures specified in [7], the access terminal and the access network shall
support the use of the Generic Attribute Update Protocol to update values of the following
configurable attributes belonging to the Enhanced Multi-Flow Packet Application:
4-7
3GPP2 C.S0102-0 v1.0
1

FlowNNFwdEncryptionProtection
2

FlowNNRevEncryptionProtection
3
4.9.1
Simple Attributes
5
The Table 4-2 defines simple configuration attributes for each flow. The flow is identified by
0xNN.
6
The default value for each attribute is typed in bold italics.
4
Table 4-2.
7
Attribute
ID
Attribute
0xcfNN
NN is the
two-digit
flow number
of the
forward flow
in the range
0x00 to
MaxNumRL
PFlowsFwd 1 inclusive.
FlowNNFwdEn
cryptionProtect
ion
0xceNN
NN is the
two-digit
flow number
of the
reverse flow
in the range
0x00 to
MaxNumRL
PFlowsRev 1 inclusive.
FlowNNRevEnc
ryptionProtecti
on
Configurable Values
Values
Meaning
0x00
The packets carried on the Forward
Link flow NN shall not be encrypted.
0x01
The packets destined for the flow
shall be encrypted by the sender
and shall be decrypted by the
receiver.
0x02-0xff
Reserved
0x00
The packets carried on the Reverse
Link flow NN shall not be encrypted.
0x01
The packets destined for the flow
shall be encrypted by the sender
and shall be decrypted by the
receiver.
0x02-0xff
Reserved
8
9
10
11
4.9.2
Complex Attributes
The following complex attributes are defined for reduction of the Ciphering key strength for
each channel.
4-8
3GPP2 C.S0102-0 v1.0
1
4.9.2.1 ReducedStrengthCipheringKey Attribute
2
Field
Length (bits)
Length
Default Value
8
N/A
16
N/A
ValueID
8
N/A
SaltLength
8
0
AttributeID
Salt
SaltLength × 8
KeyEntropy
8
N/A
16
Length
Length of the complex attribute in octets. The sender shall set this
field to the length of the complex attribute excluding the Length field.
5
AttributeID
The sender shall set this field to the value of 0x3001.
6
ValueID
The sender shall set this field to an identifier assigned to this complex
value.
8
SaltLength
The sender shall set this field to the length of the Salt field in octets.
9
Salt
The sender shall set this field to the value of the Salt input parameter
that is to be used in the KeyStrengthRedAlg procedure specified in [3]
for the Ciphering key.
KeyEntropy
The sender shall set this field to the value of the KeyEntropy input
parameter that is to be used in the KeyStrengthRedAlg procedure
specified in [3] for the Ciphering key. The valid values for this field
are 0 through 16, inclusive.
3
4
7
10
11
12
13
14
15
16
17
18
4.10 Session State Information
The Session State Information specified in [7] applies here.
4-9
3GPP2 C.S0102-0 v1.0
1
5
AALS MULTI-LINK MULTI-FLOW PACKET APPLICATION
2
5.1
3
5.1.1
4
5
6
7
8
9
10
11
Introduction
General Overview
In addition to section 3.1 of [7], the following text serves as introduction to the expanded
functionality of MLMFPA specified in [7].
This section defines additional procedures and requirements for Multi-Link Multi-Flow
Packet Application in [7]. This specification defines additional procedures and requirements
to support Air Interface Application Security for this new defined sub-type. Unless specified
otherwise, all the procedures defined in [7] also apply to this section.
The Air Interface Application Data Encryption uses the AES (a.k.a. Rijndael) procedures
defined in [3] in order to encrypt and decrypt the MLMFPA packets.
18
Air Interface Application Data encryption can be applied selectively to individual link flows.
That is, depending on session configuration, some link flows may be encrypted, while others
are not. Encryption mode is individually configured for each link flow during the negotiation
of link flow. Each SAR block is encrypted by the transmitter using the AES algorithm in a
counter mode. Because all required cryptographic configuration parameters are either
provided by other protocols (session encryption keys) or internally derived (cryptosync), no
additional headers are required for crypto-processing the data.
19
5.1.2
20

21
This new subtype value is defined in [1].
12
13
14
15
16
17
22
23
24
Public Data
Subtype for this application.
5.2
Protocol Initialization
Procedures specified in [7] apply here.
5.3
25
Procedures and Messages for the InConfiguration Instance of the Packet
Application
26
5.3.1
Procedures
27
The procedures specified in [7] apply here.
28
5.3.2
29
Procedures specified in [7] apply here.
30
5.3.3
31
Procedures specified in [7] apply here.
Commit Procedures
Message Formats
5-1
3GPP2 C.S0102-0 v1.0
1
2
3
5.4
Route Selection Protocol
Procedures specified in [7] apply here.
5.5
Segmentation and Reassembly Protocol
4
Procedures specified in [7] apply here.
5
5.5.1
Overview
6
5.5.2
Primitives and Public Data
7
5.5.3
Protocol Data Unit
8
5.5.4
Procedures and Messages for the InUse Instance of the Protocol
9
10
11
12
13
14
15
16
17
18
19
20
21
22
5.5.4.1 Procedures
In addition to the procedures specified in [7], the following procedure apply.
When forward Link Flow NN is activated, the access network and the access terminal shall
not update the following attributes:

FlowNNFwdEncryptionProtection
When reverse Link Flow NN is activated, the access network and the access terminal shall
not update the following attributes:

FlowNNRevEncryptionProtection
5.5.4.1.1 Constructing the Encryption Key
In addition to procedures specified in [7], the access terminal and the access network shall
perform the following session key construction procedure, if the protocol receives a
RouteUpdate.ConnectionInitiated indication.
The Air Interface Application Data Encryption Protocol shall construct the encryption keys
as follows:

26
If
the
value
of
any
FlowNNFwdEncryptionProtection
or
FlowNNRevEncryptionProtection attribute is equal to 0x01, then the Air Interface
Application Data Encryption Function shall construct the encryption key for the
forward flow NN DataEncryptionKey as follows:
27
Call the KeyStrengthRedAlg procedure specified in [3] with its inputs set as follows:
23
24
25
28
 Set the KeyLength to 16.
29
 Set the OriginalKey to the value of the DataKey as specified in 2.2.
30
 Set the SaltLength to the value of the SaltLength parameter.
31
 Set the Salt to the value of the Salt parameter.
32
 Set the KeyEntropy to the value of the KeyEntropy parameter.
5-2
3GPP2 C.S0102-0 v1.0
When the KeyStrengthRedAlg procedure returns, set the DataEncryptionKey to
RedStrengthKey which is the output of the KeyStrengthRedAlg procedure if
FlowNNFwdEncryptionProtection or FlowNNRevEncryptionProtection is set to
0x01.
1
2
3
4
5
5.5.4.1.2 Constructing the Cryptosync
6
The SAR shall construct the Cryptosync as shown in Table 5-1.
Table 5-1.
7
Subfield of the Cryptosync
Subfield
Flow
Length (bits)
FunctionCode
2
Direction
1
Reserved
5
FlowID
8
StreamID
8
RolloverCounter
34
VirtualSequenceNumber
22
8
FunctionCode
This field shall be set to ‘00’ to indicate Ciphering function.
9
Direction
If the payload being encrypted or decrypted is for Forward
Link then this field shall be set to ‘0’. Otherwise, this field
shall be set to ‘1’. Direction is received as Direction input to
ENCRYPT and DECRYPT procedure calls.
13
Reserved
All the bits in this field shall be set to ‘0’.
14
FlowID
This field shall be set to the LinkFlowNumber corresponding
to the payload being encrypted or decrypted. FlowID is
received as FlowID input to ENCRYPT and DECRYPT
procedure calls.
StreamID
The two LSBs of this field shall be set to the stream ID to
which the application subtype is associated with. The
remaining bits are set to ‘0’.
RolloverCounter
This field shall be constructed and maintained by the Access
Network and Access Terminal as described in 5.1.2.1.
VirtualSequenceNumber
For the octet stream, this field shall be set as follows: For the
first block, this field shall be set to the value of a Sequence
Number of the SAR packet (SEQ) included in the SAR header,
10
11
12
15
16
17
18
19
20
21
22
23
24
25
5-3
3GPP2 C.S0102-0 v1.0
divided by 16. For each subsequent block, this value shall be
incremented by 1. For packet stream, this field shall be set to
the packet sequence number in the packet header.
1
2
3
4
5.5.4.1.3 RolloverCounter Procedures
5
The RolloverCounter is as specified as 3.1.2.1.
6
5.5.4.2
7
5.5.4.2.1 Data Transmit Procedure
8
9
10
11
Data Transfers
The Data Transfer function shall provide service of encrypting the payload from the Air
Interface Application Layer. Figure 5-1 illustrates the relationship between an Input
Payload and an Output Payload after processing with the Air Interface Application Data
Encryption capability.
12
SAR
Header
SAR
Header
Payload from
Application Layer
Encrypted InputPayload
Octet-aligned
OutputPayload
13
Figure 5-1. Encryption Procedure Call
14
15
16
17
18
19
20
21
22
23
24
The Air Interface Application Data Encryption Function shall perform the following
procedure for each of the flows:

If the Encryption attribute for the flow under consideration (e.g.,
FlowNNFwdEncryptionProtection) is equal to 0x01, the function shall perform the
following:
For the octet stream, the SAR packet shall be divided into 16 byte blocks and the
cryptosync calculated for each block using the procedure defined in 5.5.4.1.2. If
the sequence number from the packet header is not at the 16 byte boundary, the
first AES block shall be selected to make the second AES block starting from 16
byte boundary.
5-4
3GPP2 C.S0102-0 v1.0
The function shall call the ESP_AES procedure specified in [3] with its inputs set as
follows:
1
2
3

Set the key to the Encryption Key for the flow under consideration(e.g.,
DataEncryptionKey) as specified in 5.5.4.1.1.

Set fresh to the value of the Cryptosync for the flow under consideration.
The Cryptosync is calculated as specified in 5.5.4.1.2.

Set the freshsize to the value of the CryptosyncLength for the flow under
consideration.

Set the buf to the address of the beginning of the memory space that
contains the Air Interface Application Layer packet.

Set the bit_offset to zero if the sequence number from the packet header is at
the 16 byte boundary. If the sequence number from the packet header is not
at the 16 byte boundary, the bit_offset shall be set to the value that points to
the first bit of the payload in the first AES block. For packet stream, the
bit_offset shall be set to zero.

Set the bit_count to the length of the Air Interface Application Layer Packet in
bits.
4
5
6
7
8
9
10
11
12
13
14
15
16
17
After the ESP_AES procedure is returned, the function shall set the Stream Layer
packet to the output of the ESP_AES procedure which starts at the memory
space specified by buf and is of the same size as the Air Interface Application
Layer packet.
18
19
20
21
22
23
24

If the Encryption attribute for the flow under consideration (e.g.,
FlowNNFwdEncryptionProtection) is equal to 0x00, the function shall set the Stream
Layer packet to the Air Interface Application Layer packet .
25
5.5.4.2.2 Data Receive Procedures
26
This is a new procedures that is not specified in the section 3.5 of [7].
27
28
29
The data receive procedure shall provide service of decrypting the payload from Streaming
Layer. Figure 5-2 illustrates the relationship between an Input Payload and the Output
Payload after processing the payload at Air Interface Application Encryption function.
30
5-5
3GPP2 C.S0102-0 v1.0
InputPayload
SAR
Header
Encrypted Payload
Octet-aligned
SAR
Header
Decrypted Payload
1
Figure 5-2. Decryption Procedure Call
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
If the Stream Layer packet is received, then the receiver shall construct the Air Interface
Application Layer packet from the Stream Layer packet by performing the following
procedure for each of the flows:

If the Encryption attribute for the flow under consideration (e.g.,
FlowNNFwdEncryptionProtection) is equal to 0x01, the Air Interface Application
Data Encryption Function shall perform the following:
For the octet stream, the SAR packet shall be divided into 16 byte blocks and the
cryptosync calculated for each block using the procedure defined in 5.5.4.1.2. If
the sequence number from the packet header is not at the 16 byte boundary, the
first AES block shall be selected to make the second AES block starting from 16
byte boundary.
The Air Interface Application Data Encryption Function shall call the ESP_AES
procedure specified in [3] with its inputs set as follows:

Set the key to the DataEncryptionKey for the flow under consideration as
specified in section 5.5.4.1.1.

Set fresh to the value of the Cryptosync for the flow under consideration. The
Cryptosync is calculated as specified in 5.5.4.1.2.

Set the freshsize to the value of the CryptosyncLength for the flow under
consideration.

Set the buf to the address of the beginning of the memory space that
contains the Stream Layer packet.
17
18
19
20
21
22
23
5-6
3GPP2 C.S0102-0 v1.0
1

Set the bit_offset to zero if the sequence number from the SAR header is at
the 16 byte boundary. If the sequence number from the SAR header is not at
the 16 byte boundary, the bit_offset shall be set to the value that points to
the first bit of the payload in the first AES block. For packet stream, the
bit_offset shall be set to zero.

Set the bit_count to the length of the Stream Layer Packet in bits.
2
3
4
5
6
After the ESP_AES procedure is returned, the function shall set the Air Interface
Application Layer packet to the output of the ESP_AES procedure which starts at
the memory space specified by buf and is of the same size as the Stream Layer
packet.
7
8
9
10
11

12
13
14
15
16
17
18
19
20
21
If the Encryption attribute for the flow under consideration (e.g.,
FlowNNFwdEncryptionProtection) is equal to 0x00, the Air Interface Application
Data Encryption Function shall set the Air Interface Application Layer packet to the
Stream Layer packet.
5.5.4.3 SAR Packet Header
No change from [7].
5.5.4.4 Message Formats
No change from [7].
5.5.4.5 Interface to Other Protocols
No change from [7].
5.5.4.6 SAR Packet Priorities
22
No change from [7].
23
5.5.5
24
No change from [7].
25
26
27
28
29
30
31
32
5.6
Protocol Numeric Constants
Quick Nak Protocol
Procedures specified in [7] apply here.
5.7
Data Over Signaling Protocol
Data Over Signaling uses best effort messages. So signaling protection can not be applied.
5.8
Location Update Protocol
Procedures specified in [7] apply here.
5.9
Flow Control Protocol
Procedures specified in [7] apply here.
5-7
3GPP2 C.S0102-0 v1.0
1
2
3
4
5.10 Configuration Attributes for the Multi-link Multi-flow Packet Application
In addition to procedures specified in [7], the access terminal and the access network shall
support the use of the Generic Attribute Update Protocol to update values of the following
configurable attributes belonging to the Multi-link Multi-flow Packet Application:
5

FlowNNFwdEncryptionProtection
6

FlowNNRevEncryptionProtection
7
8
9
10
5.10.1 Simple Attributes
The Table 5-2 defines simple configuration attributes for each flow. The flow is identified by
0xNN.
The default value for each attribute is typed in bold italics.
Table 5-2.
11
Attribute
ID
Attribute
0xcfNN
NN is the
two-digit
flow number
of the
forward flow
in the range
0x00 to
MaxNumSA
RFlowsFwd
-1 inclusive.
FlowNNFwdEn
cryptionProtect
ion
0xceNN
NN is the
two-digit
flow number
of the
reverse flow
in the range
0x00 to
MaxNumSA
RFlowsRev 1 inclusive.
FlowNNRevEnc
ryptionProtecti
on
Configurable Values
Values
Meaning
0x00
The packets carried on the Forward
Link flow NN shall not be encrypted.
0x01
The packets destined for the flow
shall be encrypted by the sender
and shall be decrypted by the
receiver.
0x02-0xff
Reserved
0x00
The packets carried on the Reverse
Link flow NN shall not be encrypted.
0x01
The packets destined for the flow
shall be encrypted by the sender
and shall be decrypted by the
receiver.
0x02-0xff
Reserved
12
5-8
3GPP2 C.S0102-0 v1.0
1
2
3
4
5.10.2 Complex Attributes
The following complex attributes are defined for reduction of the Ciphering key strength for
each channel.
5.10.2.1 ReducedStrengthCipheringKey Attribute
5
Field
Length (bits)
Length
Default Value
8
N/A
16
N/A
ValueID
8
N/A
SaltLength
8
0
AttributeID
Salt
SaltLength × 8
KeyEntropy
8
N/A
16
Length
Length of the complex attribute in octets. The sender shall set this
field to the length of the complex attribute excluding the Length field.
8
AttributeID
The sender shall set this field to the value of 0x3001.
9
ValueID
The sender shall set this field to an identifier assigned to this complex
value.
11
SaltLength
The sender shall set this field to the length of the Salt field in octets.
12
Salt
The sender shall set this field to the value of the Salt input parameter
that is to be used in the KeyStrengthRedAlg procedure specified in [3]
for the Ciphering key.
KeyEntropy
The sender shall set this field to the value of the KeyEntropy input
parameter that is to be used in the KeyStrengthRedAlg procedure
specified in [3] for the Ciphering key. The valid values for this field
are 0 through 16, inclusive.
6
7
10
13
14
15
16
17
18
19
20
21
5.11 Session State Information
The Session State Information specified in [7] applies here.
22
5-9
3GPP2 C.S0102-0 v1.0
1
This page intentionally left blank.
5-10