Doc# 106741547
Input Contribution
INPUT CONTRIBUTION
Group Name:*
WG4 (SEC) at TP#9
Title:*
Attachment Flow Diagrams for Security TS
Source:*
Phil Hawkes, Qualcomm , phawkes@qti.qualcomm.com
Wolfgang Granzow, Qualcomm, wgranzow@qti.qualcomm.com
Josef Blanz, Qualcomm, jblanz@qti.qualcomm.com
Contact:
As above
Date:*
2014-02-10
Abstract:*
This contribution present a set of flows for “Attachment” – the
authentication and (where applicable) registration of CSE or AE to another
CE. It is hoped that these flows clarify the how security procedures relate
to registration.
Agenda Item:*
Contributions impacting ARC TS-0001
Work item(s):
ARC WI-0002, SEC WI-0007
Document(s)
Impacted*
Security TS (TS-0003)
Intended purpose of
document:*
Decision requested or
recommendation:*
Decision
Discussion
Information
Other <specify>
Incorporate text into an appropriate section of the Security TS-0003.
oneM2M Notice
The document to which this cover statement is attached is submitted to oneM2M.
Participation in, or attendance at, any activity of oneM2M, constitutes acceptance of and
agreement to be bound by terms of the Working Procedures and the Partnership
Agreement, including the Intellectual Property Rights (IPR) Principles Governing oneM2M
Work found in Annex 1 of the Partnership Agreement.
© 2013 oneM2M Partners
Page 1 (of 13)
Doc# 106741547
Input Contribution
The terms of Registree and Registrar and have been proposed as the originator and
Receiving entities in a registration procedure. The Registree should also be the entity
initiating security sessions, so this terminology is also useful from the security perspective.
Note that the Registree may be an AE or a CSE, but the Registrar must be a CSE.
In the following text we often use the abbreviation of “Ree” to refer to the Registree and
the abbreviation “Rar” to refer to the Registrar.
This terminology is still under discussion, and it is unclear at this stage where such
terminology will be defined – so we have not proposed definitions here.
==================< Start of New Definitions >====================
Attachment:
the procedures involved in authentication and (where appropriate) registration of a Registree
to a Registrar.
Kca:
a master key shared between an AE and the local CSE. Kcc is used for securing
communication between the AE and CSE (that is, for securing Mca).
Kca_ID:
Used to identify Kca in security context establishment.
Kcc:
a master key shared between two CSEs. Kcc used for securing communication between those
CSE (that is, for securing Mcc).
Kca_ID:
Used to identify Kca in security context establishment.
Security Context Establishment A process for establishing session secrets between a Regsitree and Registrar,
for the purpose of protecting messages exchanged between those entities. In some cases, only
the Registrar is authenticated. In other cases, both the Registree and Registrar are
authenticated as part of Security Context establishment,
==================< Start of New Definitions >====================
==================<Start of Change 1 (New Text) >=================
x.y Attachment Flows
The figures in this clause use font colours to help differentiate the general topic that the text relates to.

Black text contains authentication-mechanism-independent details

Blue text highlights details specific to a particular authentication mechanism.

Purple text highlights technical actions that are not specified in oneM2M.

Green text highlights business actions that are not specified in oneM2M.

Red text highlights security-related properties.
© 2013 oneM2M Partners
Page 2 (of 13)
Doc# 106741547
Input Contribution
x.y.1
Generic Sequence of Events for Attachment Flows
The sequence of events in the Attachment flows follows a common pattern:
0.
Information is preconfigured in the Registree, Registrar and other entities involved in the Attachment
process
1.
The M2M Subscriber interacts with the M2M Service Provider and other stakeholders to exchange the
information appropriate for the particular authentication mechanism.
Note: A step 1 in any of the initial attachment call flows, the M2M Subscriber could arrange with the
M2M SP to assign the Registree with an existing CSE_ID/AE_ID if the CSE/AE (that previously was
assigned the CSE_ID/AE_ID) is being replaced by the Registree. This could be a useful way of
replacing CSE/AE that had ceased to be functional, without affecting the rest of the system.
2.
The Registree obtains the target Registrar details: the target Registrar’s CSE_ID and any credentials
needed for mutual authentication with the Registrar. The Registree can obtain this information in the
following ways

Retrieving a <briefing> resource (with the target Registrar’s details) from a trusted CSE (the
“Briefing” Registrar), as specified in Architecture Technical Specification [TS-0001]. In some
cases, the Briefing Registrar does not intend to provide any M2M Services to the Registree
other than to provide the details of the target Registrar from which the Registree should obtain
M2M Services. In other cases, the Briefing Registrar might already be providing M2M
Services to the Registree, but the Briefing Registrar wants the Registree to migrate to a
different Registrar.

Other un-specified out of band mechanisms (e.g. manual input).
3.
The Registree performs some preliminary interaction with external entities to facilitate authentication.
Note: This step is currently used only in the GBA-based attachment.
4.
The Registree and Registrar establish a security context (establishing session secrets for a secure
communication session) using TLS or DTLS handshake. The Registrar is always authenticated as part
of establishing a security context. In all cases except “PKI and Token Authentication”, the Registree is
also authenticated as part of this process. Note: in the “PKI and Token Authentication” process, the
Registree is authenticated as part of the next part of the process).
5.
The Registree and Registrar perform registration. In the “PKI and Token Authentication” process, the
Registree is authenticated as part of this process.
The Registree and Registrar are now registered and can begin performing other
resource access operations.
6.
In some scenarios, the Registree and Registrar may be configured to perform “key generation” to create
fresh Kcc or Kca (see clause x.y.8). This is achieved by the Registree creating a <keyGeneration>
resource. The structure and message exchange for the <keyGeneration> resource and associated
procedures are specified in oneM2M Architecture Technical Specification [TS-0001], with
cryptographic details provided in the present specification.
The following sections describe attachment for a number of scenarios. This set of flows is not exhaustive.
© 2013 oneM2M Partners
Page 3 (of 13)
Doc# 106741547
Input Contribution
x.y.2 CSE/AE-to-CSE Initial Attachment using preconfigured Kcc/Kca
Registree
Registrar
0. Kcc/Kca, Kcc_ID/Kca_ID, Rar CSE ID
preconfigured in Ree. Sessions secured using
Kcc/Kca is associated w/ Registrar CSE_ID
Registree is deployed
2.Not required for this flow
0. Kcc/Kca, Kcc/Kca ID, other info about Ree is stored in Rar. At this
point in time, communication secured using Kcc_ID/Kca_ID is
associated with Kcc_ID/Kca_ID identifier
1. M2M Subscriber tells the M2M SP which CSE/AE context (how it is
used) to associate with Registree’s Kcc_ID /Kca_ID. Sessions secured
using Kcc_ID/Kca_ID are also associated with this CSE/AE context
3. External Interactions: None required for this flow
4. Security Context Establishment
(D)TLS Handshake Establishes session secrets
PSK authentication using
PSK:= Kcc/Kca, psk_identity := Kcc_ID/Kca_ID
Messages exchanged in thi security context have
confidentiality protection, integrity protection
and replay protection
5.a. Registration Request
(CREATE <remoteCse>/<ae> resource)
This security context is associated with Kcc_ID/
Kca_ID identifier
5.b Assigns Registree CSE_ID/AE_ID)
Maps Kcc_ID/Kca_ID to Registree CSE_ID/AE_ID.
This security context, and further security contexts
secured w/ Kcc/Kca are associated w/ Registree’s
CSE_ID/AE_ID
5.c.Registration Response
(includes Registree CSE_ID/AE_ID)
Resource Access Operation Request
(create, retrieve, update, delete, notify)
Resource Access Operation Response
Figure x.y.2-1
CSE/AE-to-CSE Initial Attachment using preconfigured Kcc/Kca.
© 2013 oneM2M Partners
Page 4 (of 13)
Doc# 106741547
Input Contribution
x.y.3 CSE/AE-to-CSE Re-Attachment using Kcc/Kca
Registree (Ree)



Registrar (Rar)
Ree has previously authenticated & registered to Rar
Kcc/Kca, Kcc_ID/Kca_ID, Rar CSE ID associated w/ Rar
Ree’s CSE_ID/AE_ID has been assigned by Rar.
Security contexts secured using Kcc/Kca is associated
w/ Rar CSE_ID


Ree previously authenticated & registered to Rar.
Kcc/Kca, Kcc_ID/Kca_ID, Registree CSE_ID/AE_ID
associated w/ Registree. Security contexts secured
using Kcc/Kca is associated w/ Ree CSE_ID
Steps 0-3 were applied in a previous attachment and are not needed in this attachment
4. Security Context Establishment
Communication secured
using this security
context is associated
with Rar’s CSE ID
(D)TLS Handshake Establishes session secrets
PSK authentication using

PSK:= Kcc/Kca,

psk_identity := Kcc_ID/Kca_ID
Secured messages have confidentiality protection,
integrity protection and replay protection
Communication secured
using this security
context is associated
with Ree’s CSE ID
Steps 5 (Registration) were applied in previous
attachment
Resource Access Operation Request
(create, retrieve, update, delete, notify)
Resource Access Operation Response
Resource Access Operation Request
(create, retrieve, update, delete, notify)
Resource Access Operation Response
Figure x.y.3-1 CSE/AE-to-CSE Re-Attachment using Kcc/Kca. This assumes that the Registree and
Registrar have previously authenticated and registered, and that the Registree and Registrar share a Kcc/Kca
(whether that was pre-configured, or determined during the authentication as when using GBA (Section x.y.5),
or generated following authentication as described in Section x.y.8.
© 2013 oneM2M Partners
Page 5 (of 13)
Doc# 106741547
Input Contribution
x.y.4 CSE/AE-to-CSE Re-Attachment using TLS Session Resumption
Registree (Ree)



Registrar (Rar)
Ree has previously authenticated & registered to Rar
Kcc/Kca, Kcc_ID/Kca_ID, Rar CSE ID associated w/ Rar
Ree’s CSE_ID/AE_ID has been assigned by Rar.
Security contexts established w/ TLS session
resumption will be associated w/ Rar CSE_ID


Ree previously authenticated & registered to Rar.
Kcc/Kca, Kcc_ID/Kca_ID, Registree CSE_ID/AE_ID
associated w/ Registree. Security contexts
established w/ TLS session resumption will be
associated w/ Ree CSE_ID
Steps 0-3 were applied in a previous attachment and are not needed in this attachment
4. Security Context Re-Establishment
(D) TLS Handshake using Session Resumption
Communication secured
using this security
context is associated
with Rar’s CSE ID
Secured messages have confidentiality protection,
integrity protection and replay protection
Communication secured
using this security
context is associated
with Ree’s CSE ID
Step 5 (Registration) was applied in previous
attachment, and is not needed in this attachment
Resource Access Operation Request
(create, retrieve, update, delete, notify)
Resource Access Operation Response
Resource Access Operation Request
(create, retrieve, update, delete, notify)
Resource Access Operation Response
Figure x.y.4-1 CSE/AE-to-CSE Re-Attachment using TLS Session Resumption. This assumes that the
Registree and Registrar were mutually authenticated in a previous security context establishment, and that both
the REgsitree and Registrar permitted TLS session resumption.
© 2013 oneM2M Partners
Page 6 (of 13)
Doc# 106741547
Input Contribution
x.y.5 CSE/AE-to-CSE Initial Attachment using GBA
The following acronyms are specified in the Generic Bootstrap Architecture (GBA) and are provided here for
information.

BSF := Bootstrap Server Function:
“BSF is hosted in a network element under the control of an MNO. BSF, HSS, and UEs
participate in GBA in which a shared secret is established between the network and a UE by
running the bootstrapping procedure. The shared secret can be used between NAFs and UEs,
for example, for authentication purposes. ” [3GPP TS 33.220

HSS/HLR/AAA: these are authentication servers in 3GPP and 3GPP2 systems. The details are not
relevant to oneM2M.

NAF = Network Application Function.
“NAF is hosted in a network element. GBA may be used between NAFs and UEs for
authentication purposes, and for securing the communication path between the UE and the
NAF.” [3GPP TS 33.220].
In this case, the Registrar is also a GBA NAF.

USS = User Security Settings.
“A USS is an application and subscriber specific parameter set that defines two parts, an
authentication part, which contains the list of identities of the user needed for the application
(e.g. IMPUs, MSISDN, pseudonyms), and an authorisation part, which contains the user
permission flags (e.g. access to application allowed, type of certificates which may be issued).
In addition, a USS may contain a key selection indication, which is used in the GBA_U case
to mandate the usage of either the ME-based key (Ks_(ext)_NAF) or the UICC-based key
(Ks_int_NAF) or both. Sometimes also called application-specific user security setting. The
USS is delivered to the BSF as a part of GUSS from the HSS, and from the BSF to the NAF if
requested by the NAF.” [3GPP TS 33.220].
© 2013 oneM2M Partners
Page 7 (of 13)
Doc# 106741547
Input Contribution
Registrar
(includes GBA NAF)
Registree
(includes GBA UE)
HSS/HLR/AAA
+GBA BSF
0. UN credential preconfigured in HSS/AAA
0. UN credential pre-configured in Ree
1.b. M2M Subscriber authorizes
Operator to issue keys to M2M SP
and provides identifying
information for USS. Operator will
provide USS to M2M SP in Step 3.
1.a. M2M Subscriber provides the M2M SP with
identifying information & CSE/AE context (how
it is to be used). M2M SP can cross reference to
associate the Ree w/ the specific CSE/AE.
2. Registree obtains Rar CSE_ID. This can be through “Briefing
Procedure” or other un-specified mechanisms
3. External Interactions: GBA Bootstrap


Establishes Ks and B-TID at Ree and GBA-BSF. Ks_NAF can be generated from Ks and NAF FQDN
GBA-BSF holds USS for passing to Rar
4. Security Context Establishment: (D)TLS Handshake
Ks_NAF, USS
Kcc/Kca is set to Ks_NAF,
Kcc_ID/Kca_ID are generated
from Kcc/Kca and mapped to
Rar CSE_ID. This security
context & further security
contexts that are established
using Kcc are associated w/
Rar’s CSE ID
Secure communication channel
PSK authentication using:

PSK := Ks_NAF as PSK,

psk_identity := GBA B-TID
Messages exchanged w/in this
security context have
confidentiality protection, integrity
protection and replay protection
5.a. Registration Request
(CREATE <remoteCse>/
<application> resource)
5.c.Registration Response
(includes Registree CSE_ID/AE_ID)


At this time, Ks_NAF is associated
with GBA B-TID & identifying
information in USS (see Step1.b)
Rar cross reference identifying
information in USS to the CSE/AE
context (see Step 1.a)
5.b Assigns Ree CSE_ID/AE_ID
Kcc/Kca is set to Ks_NAF. Kcc_ID/Kca_ID
are generated from Kcc/Kca and &
mapped to Ree CSE_ID/AE_ID. This
security context & further security
contexts that are established using Kcc
are associated with Ree’s CSE_ID/AE_ID
Figure x.y.5-1 Initial authentication and initial registration when using GBA-ME for initial authentication.
The GBA Ks-NAF is stored directly as Kcc. Kcc is then used for mutual authentication of later TLS sessions, as
described in “CSE/AE Re-attachment using Kcc/Kca” Figure x.y.3-1 .
© 2013 oneM2M Partners
Page 8 (of 13)
Doc# 106741547
Input Contribution
x.y.6 CSE/AE-to-CSE Initial Attachment using Client Certificate & PKI
Authentication
Registree
Registrar
0.a Ree is pre-configured w/ its Private Key, Public Key,
Public Key ID, self-signed certificate, (opt) Certification
Verification Server URI
1.a M2M Subscriber obtains public key ID (or selfsigned certificate) ,e.g. vai QR code
(Opt) Certificate
Verification
Server
0.b Rar issued a Certificate w/ chain to a M2M
SP’s root certificate
1.b M2M Subscriber provides public key ID (or
self-signed certificate) and CSE/AE context to
M2M SP. Obtains M2M SP root certificate
2. Briefing: Registree obtains Rar CSE ID & a root cert for M2M SP . This
can be through “Briefing Procedure” or other un-specified mechanisms
3. Initial External Interactions: Not required in this flow
4. Security Context Established
This security
context &
further security
contexts that
are established
using Rar
certificate are
associated w/
Rar’s CSE ID
(Opt) Certificate
Verification
(CRL, OCSP)
(D)TLS Handshake establishes session secrets

Authentication using server and client certs.

Server Cert includes Registrar’s CSE ID

Client Cert includes Ree Public Key ID
Secured messages have confidentiality protection,
integrity protection and replay protection
5.a Registration Request
(CREATE <remoteCse>/<ae> resource)
5.c.Registration Response
(includes Registree CSE_ID/AE_ID)
5.b Assigns Ree CSE_ID/AE_ID
This security context & further
security contexts that are
established using Ree public key
are associated with Ree’s CSE_ID/
AE_ID
Figure x.y.6-1 Initial authentication and initial registration when using server and client certificates for initial
authentication. If Kcc/Kca is not generated, then any further secure sessions must continue to use the server and
client certificates for authentication (that is, repeat the exchange in this Figure). Figure x.y.8.3-1 shows the
attachment flow including generation of Kcc/Kca.
© 2013 oneM2M Partners
Page 9 (of 13)
Doc# 106741547
Input Contribution
x.y.7 CSE/AE-to-CSE Initial Attachment using PKI & Token
Registree
Registrar
0.a Ree is pre-configured w/ (opt) Certification
Verification Server URI
(Opt) Certificate
Verification
Server
0.b Rar issued a Certificate w/ chain to a M2M
SP’s root certificate
1.b M2M Subscriber provides CSE/AE context to M2M SP. M2M SP provides an
Identity Token for this CSE/AE & M2M SP root certificate. If Identity Token is
provided in a security context, then Rar associates that security context with
this CSE/AE context
2. Briefing: Registree obtains Rar CSE ID, a root cert for M2M SP
& Identity Token. How this happens is for later discussion
3. Initial External Interactions: None required in this flow
4. Security Context Established
This security
context &
further security
contexts that
are established
using Rar
certificate are
associated w/
Rar’s CSE ID
(Opt) Certificate
Verification
(CRL, OCSP)
(D)TLS Handshake establishes session secrets
Authentication using server cert only.
Server Cert includes Registrar’s CSE ID
Client is not authenticated by (D)TLS
Handshake
Secured messages have confidentiality protection,
integrity protection and replay protection



5. Registration Request
(CREATE <remoteCse>/<ae> resource)
Includes Identity Token
Assigns Registree CSE_ID/AE_ID
This security context is associated
with Ree’s CSE_ID/AE_ID
6.Registration Response
(includes Registree CSE_ID/AE_ID)
Figure x.y.7-1 Initial authentication and initial registration when using server certificates and tokens or
passwords for authentication. In this case, Kcc is not generated because the token/password is only intended to
provide short-to-medium term authentication/authorization. The session may be resumed (see Figure 7) within
the lifetime of the token/password if required. Note that the tokens/passwords may also be provided in multiple
sequential TLS sessions.
© 2013 oneM2M Partners
Page 10 (of 13)
Doc# 106741547
Input Contribution
x.y.8 CSE/AE-to-CSE Kcc/Kca Generation
x.y.8.1
Motivation for Kca/Kca Generation
Once the Registree and Registrar obtain a mutually authenticated session, the Registree and Registrar can
choose to generate a fresh Kcc/Kca using the exchange below. There are a variety of reasons that the M2M
Subscriber and M2M SP desire to generate a fresh Kcc/Kca:

After the initial PKI & Client Certificate Authentication as in “CSE/AE-to-CSE Initial Attachment
using PKI & Client Certificate Authentication” (Figure x.y.6-1) it is inefficient to continue using PKI
& Client Certificate PKI Authentication for every re-attachment. It is more efficient to generate a Kcc
or Kca after the initial attachment using PKI & Client Certificate Authentication, and then perform
“CSE/AE-to-CSE Re-Attachment using Kcc/Kca” (Figure x.y.3-1).

Similarly, after the initial PKI & Token Authentication as in “CSE/AE-to-CSE Initial Attachment using
PKI & Token Authentication” (Figure x.y.6-1) it is inefficient to continue using PKI & Token
Authentication for every re-attachment. It is more efficient to generate a Kcc or Kca after the initial
attachment using PKI & Token Authentication, and then perform “CSE/AE-to-CSE Re-Attachment
using Kcc/Kca” (Figure x.y.3-1).

Where Kcc/Kca has already exists, M2M subscribers and M2M SP may desire the Registree and
Registrar to use the existing Kcc/Kca to establish new Kcc/Kca that is a secret known only to the
Registree and Registrar. . In the cryptographic world, this property is known as Perfect Forward
Secrecy (PFS).
o
GBA-based authentication as shown in Figure x.4 results in a Kcc/Kca that is known to the
UN SP. Some M2M subscribers and M2M SP may prefer that the UNSP does not know
Kcc/Kca. For this reason, the M2M subscribers and M2M SP may desire the Registree and
Registrar to use the existing Kcc/Kca to establish new Kcc/Kca that is a secret known only to
the Registree and Registrar; that is, which the UN SP cannot determine.
o
Even where Kcc/Kca is not known to other entities, the M2M subscribers and M2M SP may
prefer to periodically generate new Kcc/Kca such that if the old Kcc/Kca are leaked, then the
new Kcc/Kca still remain a secret known only to the Registree and Registrar.
PFS can be achieved can be achieved by generating new Kcc/Kca using Ephemeral Diffie-Hellman key
exchange authenticated using the existing Kca/Kcc. If using TLS or DTLS, then the cipher suites incorporating
Ephemeral Diffie-Hellman start with and “TLS_ECDHE_”, and include

“TLS_DHE” ciphersuites and in TLS 1.2 specification [RFC 5246] and TLS PSK specification [RFC
4279].

TLS_ECDHE ciphersuites, such as in in [RFC 5430 (NSA Suite B), RFC 5489 (ECDHE_PSK
Ciphersuites)].
© 2013 oneM2M Partners
Page 11 (of 13)
Doc# 106741547
Input Contribution
x.y.8.2
Generic Flow for Kca/Kca Generation
Registrar
Registree
This security
context is
associated w/
Rar’s CSE ID
Steps 0-5. The Registree and Registrar are mutually authenticated
and registrered.
If the new Kcc/Kca are to have Perfect Forward Secrecy, th the

Security Context Establishment should include the Ephemeral
Diffie-Hellman exchange (denoted DHE in TLS ciphersuites)
This security
context is
associated w/ Ree’s
CSE_ID/AE_ID
6. Key Generation Request/Response
(CREATE <keyGen> resource)
Further sessions
that are secured
using Kcc/Kca are
associated with
Rar CSE_ID/
AE_ID
Regsitree & Registrar generate Kcc/Kca and
Kcc_ID/Kca_ID from session secrets
Further sessions
that are secured
using Kcc/Kca are
associated with
Registree CSE_ID/
AE_ID
Security Context closed
Can now perform “CSE/AE-to-CSE Re-Attachment using
Kcc/Kca” (Figure X.2) to re-attach.
Figure x.7.8.2-1 Kcc/Kca Generating during an existing mutually authenticated secure session.
© 2013 oneM2M Partners
Page 12 (of 13)
Doc# 106741547
Input Contribution
x.y.8.3
Kca/Kca Generation after Initial PKI & Client Certificate
Authentication
Registrar
Registree
(Opt) Certificate
Verification
Server
Steps 0-3. see Figure x.y.6-1
(Opt) Certificate
Verification
(CRL, OCSP)
4. Security Context Established
This security
context is
associated w/
Rar’s CSE ID
(D)TLS Handshake establishes session secrets
(see Figure x.y.6-1)
5. Registration Request/Response
(CREATE <remoteCse>/<aapplication> resource)
see Figure x.y.6-1
Assigns Registree CSE_ID/AE_ID
This security context is associated with
Ree’s CSE_ID/AE_ID
6. Key Generation Request/Response
(CREATE <keyGen> resource)
Further sessions
secured using Kcc/
Kca are associated
with Rar CSE_ID/
AE_ID
Regsitree & Registrar generate Kcc/Kca and
Kcc_ID/Kca_ID from session secrets
Further sessions that are secured using
Kcc/Kca are associated with Registree
CSE_ID/AE_ID
Security Context closed
Can now perform “CSE/AE-to-CSE Re-Attachment using Kcc/Kca”
(Figure x.y.3-1) to re-attach.
Figure x.y.8.3-1
Initial authentication and initial registration when using server and client certificates
for initial authentication, with additional Kcc/Kca generation. Further secure session can be established using
Kcc/Kca as in Figure x.y.3-1 “CSE/AE-to-CSE Re-Attachment using Kcc/Kca”.
==================<End of Change 1 (New Text) >=================
==================<Start of Change 2 (New Text) >=================
a.b Algorithms
a.b.1 Kcc_ID Generation.
Kcc_ID is generated from the value of Kcc as follows:
Kcc_ID = SHA-256(“Kcc” | Kcc) truncated to 128-bits.
a.b.1 Kcc_ID Generation.
Kcc_ID is generated from the value of Kcc as follows:
Kca_ID = SHA-256(“Kca” | Kca) truncated to 128-bits.
==================<Endof Change 2 (New Text) >=================
© 2013 oneM2M Partners
Page 13 (of 13)