3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; 3G Security; V11.0.

0 (2012-09) Network Domain Security NDS!; Technical Specification Transaction "apa#ilities Application Part T"AP! user security $elease %%!

3GPP TS 33.204

The present document has been developed within the 3rd Generation Partnership Project (3GPP TM) and may be further elaborated for the purposes of 3GPP. The present document has not been subject to any approval process by the 3GPP Or ani!ational Partners and shall not be implemented. This "pecification is provided for future development wor# within 3GPP only. The Or ani!ational Partners accept no liability for any use of this "pecification. "pecifications and reports for implementation of the 3GPP TM system should be obtained via the 3GPP Or ani!ational Partners$ Publications Offices.

$elease %%

'

3GPP TS 33&'() *%%&(&( '(%'+(,!

%eywords
UMTS, Security, Network, MAP, T AP, M!"!#e$e"t

3GPP Postal address 3GPP support office address

%&0 'oute (e) *ucio+e) - So,-i! A"ti,o+i) V!+.o""e - /'AN 0 Te+.1 233 4 92 94 42 00 /!31 233 4 93 %& 44 1%

&nternet
-tt,155www.3#,,.or#

Copyright Notification 'o part may be reproduced e(cept as authori!ed by written permission. The copyri ht and the fore oin restriction e(tend to reproduction in all media.
) *+,*- 3GPP Or ani!ational Partners (./&0- .T&"- 11".- 2T"&- TT.- TT1). .ll ri hts reserved. 3MT"4 is a Trade Mar# of 2T"& re istered for the benefit of its members 3GPP4 is a Trade Mar# of 2T"& re istered for the benefit of its Members and of the 3GPP Or ani!ational Partners 5T24 is a Trade Mar# of 2T"& currently bein re istered for the benefit of its Members and of the 3GPP Or ani!ational Partners G"M6 and the G"M lo o are re istered and owned by the G"M .ssociation

3GPP

$elease %%

3GPP TS 33&'() *%%&(&( '(%'+(,!

o"te"t)
1ontents....................................................................................................................................................3 7oreword...................................................................................................................................................8 &ntroduction...............................................................................................................................................8 , "cope......................................................................................................................................................9 * /eferences..............................................................................................................................................9 3 :efinitions- symbols and abbreviations..................................................................................................9
3., :efinitions..............................................................................................................................................................9 3.* "ymbols..................................................................................................................................................................; 3.3 .bbreviations.........................................................................................................................................................; 3.8 1onventions............................................................................................................................................................<

8 Principles of T1.P user security...........................................................................................................<

8., Overview................................................................................................................................................................< 8.* 'etwor# architecture..............................................................................................................................................<

9 T1.P user security (T1.Psec).............................................................................................................=

9., "ecurity services provided by T1.Psec................................................................................................................= 9.* Properties and tas#s of an ""<>"2G......................................................................................................................= 9.3 Policy re?uirements for the T1.Psec "ecurity Policy :atabase ("P:).............................................................,+ 9.8 T1.Psec security association attribute definition...............................................................................................,+ 9.9 T1.Psec structure of protected messa es...........................................................................................................,, 9.; T1.Psec al orithms............................................................................................................................................,3

.., &nter>domain "ecurity .ssociation and %ey Mana ement Procedures.............................................,9 ..* 5ocal "ecurity .ssociation :istribution...........................................................................................,9 1., Transition phase from unprotected to protected messa e transfer...................................................,@ 1.* Transition phase from protected messa e transfer to unprotected messa e transfer........................,= 1.3 Transition phase from protected mode to another protected mode..................................................,= :., Mobile Terminated "M"..................................................................................................................*+ :.* Mobile Ori inated "M"...................................................................................................................*,

3GPP

$elease %%

3GPP TS 33&'() *%%&(&( '(%'+(,!

/orewor(
This Technical "pecification has been produced by the 3rd Generation Partnership Project (3GPP). The contents of the present document are subject to continuin wor# within the T"G and may chan e followin formal T"G approval. "hould the T"G modify the contents of the present document- it will be re>released by the T"G with an identifyin chan e of release date and an increase in version number as followsA Bersion (.y.! whereA ( the first di itA , presented to T"G for informationC * presented to T"G for approvalC 3 or reater indicates T"G approved document under chan e control. y the second di it is incremented for all chan es of substance- i.e. technical enhancements- correctionsupdates- etc. ! the third di it is incremented when editorial only chan es have been incorporated in the document.

6"tro(uctio"
The absence of security in "i nallin "ystem 'o. < (""<) networ#s is an identified security wea#ness in *G systems. This was formerly perceived not to be a problem- since the ""< networ#s were the provinces of a small number of lar e institutions. This is no lon er the case- and so there is now a need for security precautions. 7or 3G systems it is a clear oal to be able to protect the core networ# si nallin protocols- and by implication this means that security solutions shall be found for both ""< and &P based protocols. Barious protocols and interfaces are used for control plane si nallin within and between core networ#s. The security services that have been identified as necessary are confidentiality- inte rity- authentication and anti>replay protection. These will be ensured by standard procedures- based on crypto raphic techni?ues.

3GPP

$elease %%

3GPP TS 33&'() *%%&(&( '(%'+(,!

Sco,e

This technical specification covers the security mechanisms and procedures necessary to protect all T1.P user messa es which are sent between different security domains. The complete set of enhancements and e(tensions to facilitate security protection for the T1.P protocol is termed T1.Psec and it covers transport security in the T1.P protocol itself and the security mana ement procedures. This technical specification contains the sta e * specification for security protection of the T1.P protocol. The actual implementation (sta e 3) specification can be found in T" *=.*+8 D=E.

'e7ere"ce)
/eferences are either specific (identified by date of publication- edition number- version number- etc.) or non>specific. 7or a specific reference- subse?uent revisions do not apply. 7or a non>specific reference- the latest version applies. &n the case of a reference to a 3GPP document (includin a G"M document)- a non>specific reference implicitly refers to the latest version of that document in the same Release as the present document. D,E D*E D3E D8E 3GPP T/ *,.=+9A FBocabulary for 3GPP "pecificationsF. 3GPP T" *=.++*A FMobile .pplication Part (M.P) specificationF. '&"T "pecial Publication @++>3@. F/ecommendation for 0loc# 1ipher Modes of OperationF :ecember *++,. &"OG&21 =<=<A F&nformation technolo y >- Security techniques -- Message
Authentication Codes (MACs) -- Part 1: Mechanisms using a block cipher F- 2d.,-

The followin documents contain provisions which- throu h reference in this te(t- constitute provisions of the present document.

,===>,*>,;. D9E D;E D<E 7&P" Publication ,=<A F"pecification for the .dvanced 2ncryption "tandard (.2")F'ovember *;- *++,. 3GPP T" 33.*,+A F3G securityC 'etwor# :omain "ecurity (':")C &P networ# layer securityF. H31 :T7 profile of &"O @;+,A *+++ > :ata 2lements and &nterchan e 7ormats > &nformation &nterchan e > /epresentation of :ates and Times. &nternational Or ani!ation for "tandardi!ation. httpAGGwww.w3.or GT/G,==@G'OT2>datetime>,==@+@*<. 3GPP T" *3.++3A F'umberin - addressin and identificationF. 3GPP T" *=.*+8A F"i nallin "ystem 'o. < (""<) security atewayC .rchitecture- functional description and protocol details F

D@E D=E

8e7i"itio"), )y$.o+) !"( !..re9i!tio")

3.1 8e7i"itio")
&n addition to the definitions included in T/ *,.=+9 D,E- for the purposes of the present document- the followin definitions applyA

3GPP

$elease %%

3GPP TS 33&'() *%%&(&( '(%'+(,!

Anti-replay protection: .nti>replay protection is a special case of inte rity protection. &ts main service is to protect a ainst replay of self>contained pac#ets that already have a crypto raphic inte rity mechanism in place. Confidentiality: The property that information is not made available or disclosed to unauthorised individuals- entities or processes. Data integrity: The property that data has not been altered in an unauthorised manner. Data origin authentication: The corroboration that the source of data received is as claimed. Entity authentication: The provision of assurance of the claimed identity of an entity. Key freshness: . #ey is fresh if it can be uaranteed to be new- as opposed to an old #ey bein reused throu h actions of either an adversary or authorised party. Security Association: . lo ical connection created for security purposes. .ll traffic traversin a security association is provided the same security protection. The security association specifies protection levels- al orithms to be usedlifetimes of the connection etc. SS7 Carrier: .n ""< networ# that is not a P5M'. SS7 Security Gateway: . 'etwor# 'ode that terminates and initiates T1.Psec. "imilar to a "2G (see T" 33.*,+ D;E)the ""< security Gateway is used for communication between two ""< security domains. TCAPsec: The complete collection of protocols and procedures needed to protect T1.P user messa es.

3.2 Sy$.o+)
7or the purposes of the present document- the followin symbols applyA f; f< If T1.Psec encryption al orithm. T1.Psec inte rity al orithm. T1.Psec reference point between ""<>"2Gs en a ed in security protected si nallin .

3.3 A..re9i!tio")
&n addition to the abbreviations included in T/ *,.=+9 D,E- for the purposes of the present document- the followin abbreviations applyA .2" 7.550.1% &P &B M.1 M.1>M M.P ':" '2 P/OP ". ".: "2. "2% "&. "&% "P: "P& ""<>"2G T1.Psec T1.P user TBP .dvanced 2ncryption "tandard 7allbac# to unprotected mode indicator &nternet Protocol &nitialisation Bector Messa e .uthentication 1ode M.1 used for T1.P user Mobile .pplication Part 'etwor# :omain "ecurity 'etwor# 2ntity Proprietary field "ecurity .ssociation "ecurity .ssociation :atabase ""< security ateway 2ncryption .l orithm identifier ""< security ateway 2ncryption %ey ""< security ateway &nte rity .l orithm identifier ""< security ateway &nte rity %ey "ecurity Policy :atabase "ecurity Parameters &nde( ""< security ateway T1.P user security J the ""< security ateway security protocol suite .pplication Part identified by the "11P "ubsystem 'umbers of T" *3.++3 D@E Time Bariant Parameter

3GPP

$elease %%

3GPP TS 33&'() *%%&(&( '(%'+(,!

3.4

o"9e"tio")

.ll data variables in this specification are presented with the most si nificant substrin on the left hand side and the least si nificant substrin on the ri ht hand side. . substrin may be a bit- byte or other arbitrary len th bitstrin . Hhere a variable is bro#en down into a number of substrin s- the leftmost (most si nificant) substrin is numbered +the ne(t most si nificant is numbered ,- and so on throu h to the least si nificant.

Pri"ci,+e) o7 T AP u)er )ecurity

4.1 :9er9iew
This technical specification defines mechanisms for protectin all T1.P user messa es called T1.Psec. .nother approach which could partially achieve the same oal as T1.Psec is the use of ':"G&P D;E at the networ# layer when &P is used as the transport protocol. Kowever- whenever inter>wor#in with networ#s usin ""<>based transport is necessary- protection with T1.Psec shall be used. The benefit for an operator applyin T1.Psec will radually increase when more interconnected operators also apply T1.Psec. T1.Psec can be used to ether with T1.P handsha#e solutions- however when usin T1.Psec for M.P "M" transfers between two P5M's- runnin T1.P handsha#e in addition does not add more security. 'OT2 ,A . limited level of M.P messa e authenticity can be achieved without the use of ""<>"2Gs by usin a T1.P handsha#e prior to the M.P payload e(chan e. .nne( : describes the use of the T1.P handsha#e for M.P "M" transfers. 'OT2 *A T1.Psec does not validate the T1.P user payload content (e. . "M" payload address correlation as described for T1.P handsha#e in .nne( :). Messa e screenin functions for particular messa e types may be needed on top of T1.Psec. 'OT2 3A &n order to prevent all active attac#s all interconnected operators shall route all ""< traffic via ""<>"2Gs. 0efore protection can be applied- "ecurity .ssociations (".) need to be established between the respective ""<>"2G. "ecurity associations define- amon other thin s- which #eys and al orithms to use at the ""<>"2G. The necessary ".s between networ#s are ne otiated between the respective networ# operators. The ne otiated ". will be effective P5M'> wide and distributed to all ""<>"2Gs. 2ach ""<>"2G contains policy information containin the protection mode that shall be applied. Protected T1.P user si nallin traffic will- for routin purposes- be indistin uishable from unprotected traffic to all parties e(cept for the sendin and receivin entities. .nne( 0 includes detailed procedures on how secure T1.P user si nallin is performed between two ""<>"2Gs.

4.2 Network !rc-itecture

4.2.1 Ge"er!+
T1.Psec can be applied between different types of ""< networ#sA a) between two P5M'Ls. b) between a P5M' and an ""<>carrier. c) between two ""<>carriers. The first case is considered in the end>to>end architecture (cf. clause 8.*.*). This architecture is applied in case the communicatin P5M's do not wish to trust intermediate ""<>networ#s. &n a hub>and>spo#e architecture- a concatenation of multiple second and third cases may happen (cf. clause 8.*.3). 3sin this architecture is re?uired if certain payload related services are performed by an ""<>carrier for whom the ""<>carrier is trusted by the P5M'.

3GPP

$elease %%

3GPP TS 33&'() *%%&(&( '(%'+(,!

4.2.2 0"(-to-e"( !rc-itecture

&n a P5M' that employs ""<>"2Gs all T1.P user si nallin messa es enterin or leavin the P5M' have to transit an ""<>"2G which belon s to the P5M' and which performs the protection of out oin messa es and the protection chec#in and de>protection or bloc#in of incomin messa es. ""<>"2G shall do Global Title Translation. 7or all unprotected messa es from networ# elements inside one P5M' that are destined for another P5M'- the destination point is a ""<>"2G of the ori inatin P5M'. .fter the messa es are protected by a ""<>"2G of the ori inatin P5M'this ""<>"2G shall direct the messa e towards the destination '2 (cf. fi ure 8.*>,). One or several ""<>"2Gs may be employed within a P5M'. .n ""<>"2G may be co>located with any T1.P user '2 or it may stand alone. Kowever- for the purpose of this specification and without imposin any restrictions- it is assumed that the ""<>"2G is stand alone. &t is further assumed that the ""<>"2Gs are located at the border of the P5M' i.e. incomin messa es transit an ""<> "2G before they reach any other node within the P5M'- and out oin messa es transit an ""<>"2G immediately before reachin a node outside the P5M'.

P*MN A
SS4 S0G

Protecte( Me))!#e

P*MN ;
SS4-S0G

N0 ! u",rotecte( $e))!#e
SS4-S0G

N0 .

u",rotecte( $e))!#e

0i1ure )&'+%2 3nd+to+end SS/+Security Gateway Architecture

4.2.3 <u.-!"(-S,oke !rc-itecture

3sin a hub>and>spo#e architecture for ""<"2Gs is re?uired in followin cases a) The intermediate ""<>carrier has to perform T1.P user payload modification .n e(ample of such a service is steerin of roamin . .nother e(ample is an "M" hubbin architecture where the K30 (i.e. the ""< carrier) has to insert a virtual "M"1>address in the M.P messa e. b) The intermediate ""<>carrier needs to perfom protocol interwor#in . 2(amples are inter>standard "M" for roamin into 1:M.- and a 1.M25 Gateway. 3sin a hub>and>spo#e architecture for ""<"2Gs may be used for followin cases but can also be performed in the end> to>end architecture. a) The intermediate ""<>carrier performs messa e screenin (e. . "P.M control) and may have to drop messa es. &f the communicatin P5M's have a reed to use protection mode , then usin the end>to>end architecture is preferred from a security point of view. &f the communicatin P5M's have a reed to use protection mode * and both P5M's find it acceptable to share the confidentiality #ey with the ""< carrier then the end>to>end architecture can be used and is preferred from a security point of view. &f confidentiality #ey sharin is not acceptable then the hub>and>spo#e architecture is the only possible solution.

3GPP

$elease %%

3GPP TS 33&'() *%%&(&( '(%'+(,!

b) The intermediate ""<>carrier performs advanced reportin . The same considerations as for case c apply. 7i ure 8.*>* is one e(ample of such a hub>and>spo#e architecture. 'OT2A 7rom a security point of view the number of intermediate hubs should be limited.

P*MN A
SS4 S0G

Protecte( Me))!#e SS4 S0G Protecte( Me))!#e

Protecte( Me))!#e

P*MN ;
SS4S0G

N0 ! u",rotecte( $e))!#e

N0 .
SS4S0G

SS4 c!rrier

Protecte( Me))!#e

u",rotecte( $e))!#e

0i1ure )&'+'2 35ample of 6u#+and+Spoke SS/+Security Gateway Architecture

&

T AP u)er )ecurity (T AP)ec)

&.1 Security )er9ice) ,ro9i(e( .y T AP)ec

The security services provided by T1.Psec areA > > > > data inte rityC data ori in authenticationC anti>replay protectionC confidentiality (optional).

&.2 Pro,ertie) !"( t!)k) o7 !" SS4-S0G

.n ""<>"2G shall maintain the followin databasesA > > "P:>"2GA . database containin T1.Psec policy information (see clause 9.3)C ".:>"2GA . database containin T1.Psec ". information. ""<>"2G shall monitor the ". hard e(piry time and e(pired ".s shall be deleted from the database (see clause 9.8).

""<>"2G shall be able to perform the followin operationsA > "ecure T1.P user si nallin (i.e. sendGreceive protected or unprotected messa es) accordin to information in "P:>"2G and ".:>"2G. The structure of protected messa es is defined in clause 9.9 and the protection al orithms are defined in clause 9.;.

3GPP

$elease %%

%(

3GPP TS 33&'() *%%&(&( '(%'+(,!

&.3

Po+icy re=uire$e"t) 7or t-e T AP)ec Security Po+icy 8!t!.!)e (SP8)

The security policies for T1.Psec #ey mana ement are specified in the ""<>"2GLs "P:. "P: entries define per peer networ# whether protection shall be applied- and if protection shall be applied then which protection mode shall be used. "P: entries of different ""<>"2Gs within the same networ# shall be consistent. all!ac" to unprotected #ode: > The Ffallbac# to unprotected modeF (enabledGdisabled) is a parameter for the receivin direction per networ#- if enabled it allows the receivin networ# to accept unprotected traffic as well as protected traffic. &f disabled- only protected traffic is to be accepted The use of the fallbac# indicator is specified in .nne( 0C The security measures specified in this T" are only fully useful for a particular networ# if it disallows fallbac# to unprotected mode for T1.P user messa es received from any other networ#. The benefit ained for a sendin operator . that applies T1.Psec for all or a subset of messa es towards a peer networ# 0 is that spoofin of the "11P callin party address for all or a subset of messa es can be detected. The receivin networ# 0 is now able to reject unprotected messa es for all or a subset of messa es that need protection- with "11P callin party addresses from networ# ..

> >

'OT2A

E$plicit policy configuration: > The "P: shall contain an entry for each networ# the ""<>"2G is allowed to communicate with.

Protection granularity: > "P: administration shall be allowed on T1.P user application part level for each networ# the ""<>"2G is allowed to communicate with.

%igration support !etween protection #odes: > .n "P: entry may contain two protection modes for the same networ#. &f this is the case then both protection modes shall be acceptable for incomin messa es- but only one (preferred) protection mode shall be used for out oin messa es.

&.4 T AP)ec )ecurity !))oci!tio" !ttri.ute (e7i"itio"

The T1.Psec security association shall contain the followin data elements which can be classified in two roups .) ". &dentification attributes i.e. 'etwor# &ds and "P&A &n sendin direction the ". identification is based on :estination 'etwor# &d. Per :estination 'etwor# &d more than one ". may e(ist. &n the case where more than one valid ". is available at the ".:- the sendin ""<>"2G shall choose the ". with the earliest soft e(piry time. &n receivin direction the used "P& from within the T1.Psec security header can be used to retrieve the Ori in 'etwor# &d. 0) .ssi ned crypto raphic parameters per "P&A %ey and al orithm identifiers and ". lifetime. ". &dentification attributesA Destination &etwor" 'd: The :estination 'etwor# &d is a concatenation of the 1ountry 1ode (11) and 'ational :estination 1ode (':1) of the receivin networ#. The :estination 'etwor#>&d is used to identify which ".:>entry shall be used when traffic protection is needed. Security Para#eters 'nde$ (SP'):

3GPP

$elease %%

%%

3GPP TS 33&'() *%%&(&( '(%'+(,!

"P& is a 3*>bit value that is used in combination with :estination 'etwor# &d to uni?uely identify a T1.Psec ".. The "P& is used to identify which ".: entry shall be used when de>protectin traffic. Therefore the "P& needs to be assi ned by the destination networ#. *rigin &etwor" 'd: The Ori in 'etwor# &d is a concatenation of the 1ountry 1ode (11) and 'ational :estination 1ode (':1) of the sendin networ#. 1rypto raphic parameters per "P&A SS7 Security Gateway Encryption Algorith# identifier (SEA): &dentifies the encryption al orithm. Mode of operation of al orithm is implicitly defined by the al orithm identifier. Mappin of al orithm identifiers is defined in clause 9.;. SS7 Security Gateway Encryption Key (SEK): 1ontains the encryption #ey. The len th of "2% is defined accordin to the al orithm identifier. SS7 Security Gateway 'ntegrity Algorith# identifier (S'A): &dentifies the inte rity al orithm. Mode of operation of al orithm is implicitly defined by the al orithm identifier. Mappin of al orithm identifiers is defined in clause 9.;. SS7 Security Gateway 'ntegrity Key (S'K): 1ontains the inte rity #ey. The len th of "&% is defined accordin to the al orithm identifier. SA +ard E$piry Ti#e: :efines the actual e(piry time of the ".. The Kard 2(piry Time shall be iven in 3T1 time with format MMMM> MM>::ThhAmmAssTI: as described by H31 :T7 D<E. SA Soft E$piry Ti#e: :efines "oft 2(piry Time of the ". for outbound traffic. The format of the "oft 2(piry Time is the same as the Kard 2(piry Time. The ". "oft 2(piry Time is determined by the Ori inatin 'etwor# and shall e(pire before the ". Kard 2(piry Time. .fter the Kard 2(piry Time has been reached- the ". shall no lon er be used for inbound or outbound traffic. Hhen the "oft 2(piry Time is reached- the ". shall not be used any lon er for the outbound traffic unless no other valid ". e(ists.

&.& T AP)ec )tructure o7 ,rotecte( $e))!#e)

T1.Psec provides followin protection modes and these are defined as followsA Protection Mode ,A &nte rity- .uthenticity Protection Mode *A 1onfidentiality- &nte rity- and .uthenticity &n case a T1.P messa e does not re?uire protection (as indicated by the "P:) then the messa e shall be routed unchan ed by the ""<>"2G. T1.P messa es protected by means of T1.Psec include a "ecurity Keader and a Protected Payload. "ecured T1.P user messa es have the followin structureA
Security <e!(er Protecte( P!y+o!(

7or detailed messa e structure see T" *=.*+8 D=E&n all protection modes- the security header is transmitted in clearte(t.

3GPP

$elease %%

%'

3GPP TS 33&'() *%%&(&( '(%'+(,!

The intermediate unprotected T1.P messa e representation is the clearte(t concatenation of :ialo uePortion and 1omponentPortion of the ori inal T1.P messa e (after messa e reassembly if this applies). 7or protection mode ,- the protected payload is the concatenation of the intermediate unprotected T1.P messa e representation and the messa e authentication code. 7or protection mode *- the protected payload is the concatenation of the result of applyin the encryption function to the intermediate unprotected T1.P messa e representation- and the messa e authentication code. 7or inte rity and authenticity in protection mode ,- the messa e authentication code is calculated on the concatenation of the security header and the intermediate unprotected T1.P messa e representation. The messa e authentication code in protection mode * is calculated on concatenation of the security header and the result of applyin the encryption function to the intermediate unprotected T1.P messa e representation.

&.&.1 T AP)ec )ecurity -e!(er

7or Protection Mode ,- the security header is a se?uence of the followin elementsA

Security header = SPI || TVP

7or Protection Mode *- the security header is a se?uence of the followin elementsA

Security header = SPI || TVP || SS7-SEG Id || Prop

where > Security Para#eters 'nde$ (SP'): "ee 1lause 9.8 T,P: The TBP- used for replay protection of secured T1.P user messa e- is a 3* bit time>stamp. The receivin networ# entity will accept an operation only if the time>stamp is within a certain time>window. The resolution of the cloc# from which the time>stamp is derived is +., seconds. The si!e of the time>window at the receivin networ# entity is not standardised. SS7-SEG 'd: , octet used to create different &B values for different ""<>"2Gs within the same TBP period. &t is necessary and sufficient that SS7-SEG Id is uni?ue per networ#. (This is sufficient because sendin #eys are uni?ue per networ#) The ""<>"2G &d shall be a uni?ue number within the networ#. Proprietary field (P-*P): , octet used to create different &B values for different protected T1.P user messa es within the same TBP period for one networ# entity. The usa e of the proprietary field is not standardised.

&.&.2 Protecte( ,!y+o!(

&.&.2.1 Protectio" Mo(e 1

The protected payload of secured T1.P user messa es in protection mode , ta#es the followin formA
+e!rte3t>> 74(Security <e!(er>> +e!rte3t)

where F1learte(tF is the concatenation of :ialo uePortion and 1omponentPortion of the ori inal T1.P messa e (after messa e reassembly if this applies). Therefore- in Protection Mode , the protected payload is a concatenation of the followin information elementsA > 1learte(t

3GPP

$elease %%

%3

3GPP TS 33&'() *%%&(&( '(%'+(,!

>

Messa e authentication code (M.1>M) calculated by the function f<

.uthentication of ori in and messa e inte rity are achieved by applyin the messa e authentication code (M.1>M) function f< with the inte rity #ey defined by the security association to the concatenation of "ecurity Keader and 1learte(t. The M.1>M len th shall be 3* bits.

&.&.2.2

Protectio" Mo(e 2

The protected payload of secured T1.P user Messa es in protection mode * ta#es the followin formA
7%( +e!rte3t) >> 74(Security <e!(er>> 7%( +e!rte3t))

where F1learte(tF is the concatenation of :ialo uePortion and 1omponentPortion of the ori inal T1.P messa e (after messa e reassembly if this applies). 1onfidentiality is achieved by encryptin 1learte(t usin the encryption function f; with the confidentiality #ey defined by the security association and the initialisation vector (&B). .uthentication of ori in and inte rity are achieved by applyin the messa e authentication code (M.1>M) function f< with the inte rity #ey defined by the security association to the concatenation of "ecurity Keader and cipherte(t. The M.1>M len th shall be 3* bits. The len th of the cipherte(t is the same as the len th of the clearte(t.

&.% T AP)ec !+#orit-$)

&.%.1 M!,,i"# o7 T AP)ec SA e"cry,tio" !+#orit-$ i(e"ti7ier)
The "2. al orithm indication fields in the T1.Psec ". are used to identify the encryption al orithm and al orithm mode to be used. The mappin of al orithm identifiers is defined below. Ta#le %2 SS/ Security Gateway encryption al1orithm identifiers
3ncryption Al1orithm identifier 0 1 1 1& Description A0S i" cou"ter $o(e wit- 12?-.it key +e"#t- (MAN8AT:'@) -"ot yet !))i#"e(-"ot yet !))i#"e(-"ot yet !))i#"e(-

&.%.1.1

8e)cri,tio" o7 S0A-0

The "2.>+ al orithm is .2" D9E used in counter mode with a ,*@>bit #ey and ,*@>bit counter bloc#s as described in clause ;.9 of 7&P" @++>3@. /ecommendation for 0loc# 1ipher Modes of Operation D3E. The initial counter bloc# T, is initiali!ed with &B. "uccessive counter bloc#s Tj (NO,) are derived by applyin an incrementin function over the entire bloc# Tj>, (NOP*) (see .ppendi( 0.,A The standard incrementin function of D3E).

&.%.2 M!,,i"# o7 T AP)ec SA i"te#rity !+#orit-$ i(e"ti7ier)

The "&. al orithm indication fields in the T1.Psec ". are used to identify the inte rity al orithm and al orithm mode to be used. The mappin of al orithm identifiers is defined below. Ta#le '2 SS/ Security Gateway inte1rity al1orithm identifiers
7nte1rity Al1orithm identifier 0 1 1 1& Description A0S i" ! ; MA $o(e wit- ! 12?-.it key (MAN8AT:'@) -"ot yet !))i#"e(-"ot yet !))i#"e(-"ot yet !))i#"e(-

3GPP

$elease %%

%)

3GPP TS 33&'() *%%&(&( '(%'+(,!

&.%.2.1

8e)cri,tio" o7 S6A-0

The "&.>+ al orithm is the &"OG&21 =<=< Part ,A paddin method *- M.1 al orithm , (initial transformationP,- output transformationP,). 'o &B used. The M.1>len th m is 3*>bits (see clause 9.;.,). "ee &"OG&21 =<=< D8E for more information.

&.%.3

o")tructio" o7 6V
IV = TVP || SS7-SEG Id || Prop || Pad

The &B used in the encryption shall be constructed as followsA

The paddin field is used to e(pand TVP || SS7-SEG Id || Prop to the IV len th re?uired by the crypto raphic scheme in use. The &B len th shall be ,; octets. The paddin (Pad) shall be ,+ octets with all bits set to !ero.

3GPP

$elease %%

%-

3GPP TS 33&'() *%%&(&( '(%'+(,!

A""e3 A (i"7or$!ti9e)1 Gui(e+i"e) 7or $!"u!+ key $!"!#e$e"t A.1 6"ter-(o$!i" Security A))oci!tio" !"( Aey M!"!#e$e"t Proce(ure)

Manual &nter>domain "ecurity .ssociation and %ey Mana ement procedures is subject to roamin a reements. "ome important parts of an inter>domain "ecurity .ssociation and %ey Mana ement a reement areA > > > > > to define how to carry out the initial e(chan e of T1.Psec ".sC to define how to renew the T1.Psec ".sC to define how to withdraw T1.Psec ".s (includin re?uirements on how fast to e(ecute the withdrawal)C to decide if fallbac# to unprotected mode is to be allowedC to decide on #ey len ths- al orithms- protection mode- and ". e(piry times- etc (T1.Psec ".s are e(pected to be fairly lon lived).

.n ". bein used by an ""<>"2G for incomin traffic e(pires when it reaches its hard e(piry time. Hhen this occursthe ""<>"2G can no lon er use that ". to process incomin T1.Psec traffic. &f a new additional valid ". is installed into the ""<>"2G- the FoldF one shall still be #ept until it reaches its hard e(piry time- so as to be able to accept incomin traffic still received under the FoldF ".. .n ". bein used by an ""<>"2G for out oin traffic e(pires when it reaches its soft e(piry time. Hhen this occursthe ""<>"2G shall start usin another valid ".. &f no such valid ". e(ists- the ""<>"2G continues to use the FoldF ". until it reaches its hard e(piry time or another valid ". effectively becomes available. &n case the current ". ets compromised- a new valid ". should be made immediately available to all ""<>"2G- which should then stop usin the compromised ". and delete it. To ease ". renewal- both networ#s may decide to set up several T1.Psec ".s in advance so that ""<>"2Gs can automatically switch from one ". to another ".. &n such a situation- the T1.Psec ".s would have different soft and hard e(piry times. Hhen more than one valid ". is available- the ""<>"2G chooses the one with the earliest soft e(piry time.

A.2

*oc!+ Security A))oci!tio" 8i)tri.utio"

Manual 5ocal "ecurity .ssociation :istribution is e(ecuted entirely within one networ# and is conse?uently at the discretion of the administrative authority. The re?uirement on the manual distribution procedures can be summari!ed as followsA > Procedures for transportin the relevant T1.Psec ". to the ""<>"2G shall be defined. &n order to ensure that the T1.Psec ". are present when needed- all valid T1.Psec ". should be distributed to all ""<>"2G as soon as they are available. Procedures for revocation of T1.Psec ".s shall be defined.

>

3GPP

$elease %%

%.

3GPP TS 33&'() *%%&(&( '(%'+(,!

A""e3 ; ("or$!ti9e)1 T AP)ec $e))!#e 7+ow)

&ma ine a networ# scenario with two ""<>"2G at different P5M's (""<>"2Ga in the sendin P5M' . and a ""<> "2Gb in the receivin P5M' 0) willin to communicate usin T1.Psec. 7i ure , presents the messa e flow.

P.%& A
5 SS7-SEGa
N0! - N0! SP8 SA8

P.%& / 678 9

0f

SS7-SEG!
N0. - N0. SP8 SA8

0i1ure 8+%& T"APsec 9essa1e 0low 'OT2A The same mi rations can be applied within the Kub>and>spo#e .rchitecture where one or both of the P5M's ta#e the role of an ""< carrier.

.ccordin to 7i ure ,- when ""<>"2Ga from P5M' . on behalf of '2a needs to send a messa e towards '2b within P5M' 0 usin T1.Psec- the process is the followin A The "endin 2ntity ""<>"2Ga performs the followin actions durin the outbound processin of every T1.P user messa eA ,. ""<>"2Ga chec#s its "ecurity Policy :atabase ("P:) to chec# if T1.Psec mechanisms shall be applied towards P5M' 0A a) &f the "P: does not mandate the use of T1.Psec for the T1.P user application part towards P5M' 0- then normal T1.P communication procedures will be used and the process continues in step 8. b) &f the "P: mandates the use of T1.Psec for the T1.P user application part towards P5M' 0- then the process continues at step *. c) &f no valid entry in the "P: is found for P5M' 0- then the communication is aborted and the messa e is discarded. *. ""<>"2Ga chec#s its "ecurity .ssociation :atabase (".:) for a valid "ecurity .ssociation (".) to be used towards P5M' 0. &n the case where more than one valid ". is available at the ".:- ""<>"2Ga shall choose the one- the soft e(piry time of which will be reached ne(t. a) &n case protection of T1.Psec messa es towards P5M' 0 is not possible (e. . no ". available- invalid ".Q)- then the messa e is discarded. b) &f a valid ". e(ists then the process continues at step 3. 3. ""<>"2Ga constructs the T1.Psec messa e towards '2b usin the parameters (#eys- al orithms) found in the ". and the protection mode from the "P:. 8. ""<>"2Ga eitherA

3GPP

$elease %%

%/

3GPP TS 33&'() *%%&(&( '(%'+(,!

a) sends a T1.Psec messa e towards P5M' 0 (from step 3). b) forwards an unprotected T1.P messa e in the event that the "P: towards P5M' 0 allowed it (step ,.a). .t the /eceivin P5M'- an ""<>"2G (e. . ""<>"2Gb) performs the followin actions durin the inbound processin of every T1.P user messa e it receivedA 9. &f a T1.P messa e is received for which no valid "P: entry e(ists (i.e. "11P callin party address is un#nown) then the messa e is discarded (Process oes to 2':). ;. &f an unprotected T1.P messa e is received- the process continues with step <. Otherwise- ""<>"2Gb decomposes the received T1.Psec messa e and retrieves "P& from the security header. <. The ""<>"2Gb chec#s the "P:A .n unprotected T1.P messa e is receivedA a) &f an unprotected T1.P messa e is received and fallbac# to unprotected mode is allowed for the specified "11P callin party address and T1.P user application part- then the unprotected T1.P messa e is simply processed (Process oes to 2':) b) &f an unprotected T1.P messa e is received- but the "P: mandates the use of T1.Psec and fallbac# to unprotected mode is 'OT allowed for the specified "11P callin party address and T1.P user application part- then the messa e is discarded. . T1.Psec messa e is receivedA c) &f a T1.Psec messa e is received- but the "P: indicates that T1.Psec is 'OT to be used- then the messa e is discarded. d) &f a T1.Psec messa e is received and the "P: indicates that T1.Psec is re?uired- then the process continues at step @. @. The receivin ""<>"2G chec#s its ".: to retrieve the relevant ". information for processin of the T1.Psec messa eA a) &f the received "P& does not point to a valid ".- then the messa e is discarded. b) &f the received "P& points to a valid ".- and if the "ource and :estination 'etwor# &d- which are retrieved via the "P&- ali n with those from "11P layer- then the ""<>"2G retrieves the protection mode from the "P: and the crypto raphic information (#eys- al orithms) from the ".: and the process continues at step =otherwise the messa e is discarded. =. 7reshness of the protected messa e is chec#ed by ensurin the Time Bariant Parameter (TBP) is in an acceptable window. &nte rity and encryption mechanisms are applied to the messa e accordin to the identified protection level- by usin the information in the ". (#eys- al orithms). a) &f the result after applyin such mechanisms is 'OT successful then the messa e is discarded. b) &f the result after applyin such procedures is successful- then ""<>"2G has the clearte(t T1.P messa e '2a ori inally wanted to send to '2b. The clearte(t T1.P messa e can now be forwarded by the receivin ""<>"2G to '2b (Process oes to 2':) 2':A . clearte(t T1.P user messa e is available at the receivin ""<>"2G. &n the event the received messa e at '2b re?uires an answer to '2a (/eturn /esultG2rror)- an ""< "2G in P5M' 0 will- on behalf of '2b perform the process in steps , to 8 actin as the "ender and an ""< "2G in P5M' . will perform the process in steps 9 to @ actin as the /eceiver and forward a successfully received messa e to '2a.

3GPP

$elease %%

%4

3GPP TS 33&'() *%%&(&( '(%'+(,!

A""e3 (i"7or$!ti9e)1 <i#- +e9e+ $i#r!tio" )tr!te#y

This .nne( describes three types of protection mode chan es- which each may be performed per T1.P user application part between a pair of networ#s. 'OT2A The same mi rations can be applied within the Kub>and>spo#e .rchitecture where one or both of the P5M's ta#e the role of an ""< carrier.

.1

Tr!")itio" ,-!)e 7ro$ u",rotecte( to ,rotecte( $e))!#e tr!")7er

0y applyin a mi ration strate y which is coordinated between the two P5M' operators (. and 0) it can be assured that protected messa es are not sent from P5M' . to P5M' 0 (and vice versa) before operator 0 confirms completion of ""<>"2G introduction in his networ#. &n order to avoid traffic interruption durin the transition phase from unprotected to protected messa e transfer between twL operators$ P5M's the followin course of action is recommendedA PreconditionA &t is assumed that neither operator .- nor operator 0 have activated T1.Psec for the T1.P user application part(s) that needs protection and now are oin to set up use of T1.P user security for traffic to and from each other. ,. Operator . ne otiates "ecurity .ssociations with operator 0 and stores the ".s in the ".:. 0oth operators also a ree on the policy that shall be applied for the different T1.P user application parts of the messa es that needs to be e(chan es between the P5M's. *. Operator . modifies the "ecurity Policy in his ateways as followsA Messa es received from operator 0Ls P5M' should be protected accordin to the indicated protection mode by the "P:C however fallbac# to unprotected mode is allowed- i.e. unprotected messa es received fromLoperator 0$s P5M' are not bloc#ed. This means that incomin messa es with an "11P callin party address pointin to operator 0 are accepted by P5M' .. Operator . does not send protected messa es yet. 'OT2 ,A Hhen fallbac# to unprotected mode is allowed then other security measures may be used that assist in identifyin the ori in of the messa e to a certain trust level- e. . T1.P handsha#e for MTforward"M (see .nne( :). 'OT2 *A .s the fallbac# indicator can be specified per T1.P user application part between a pair of P5M'- this allows a radual security up rade. 3. Hhen Operator . has completed step * in all his ""<>"2Gs- he informs Operator 0. 8. Hhen Operator . receives confirmation that operator 0 also has performed step *- Operator . modifies the "ecurity Policy in his ateways as followsA Out oin messa es sent to operator 0Ls P5M' shall be protected as indicated by the "P:. 9. Hhen Operator . has completed step 8 in all his ""<>"2Gs- he informs Operator 0 which can then perform step 8 and ; towards Operator .. ;. Hhen Operator . receives confirmation from Operator 0 that he has performed step 8- Operator . modifies the "ecurity Policy in his ateways as followsA 7allbac# to unprotected mode is not allowed- i.e. unprotected messa es received fromLoperator 0$s P5M' will be bloc#ed. 'OT2 3A .fter disablin fallbac# to unprotected mode then other security measures that are in use and that assist in identifyin the ori in of the messa e to a certain trust level- e. . T1.P handsha#e for MTforward"M (see .nne( :)- can be disabled.

3GPP

$elease %%

%,

3GPP TS 33&'() *%%&(&( '(%'+(,!

.2

Tr!")itio" ,-!)e 7ro$ ,rotecte( $e))!#e tr!")7er to u",rotecte( $e))!#e tr!")7er.

&n order to avoid traffic interruption durin the transition phase from protected to unprotected messa e transfer between two operators$ P5M's- the followin course of action is recommendedA PreconditionA &t is assumed that operator . has already successfully set up the use of T1.P user security for traffic to and from operator 0 and is now oin to remove use of T1.P user security for traffic to and from operator 0. ,) Operator . modifies the "ecurity Policy in his ateways as followsA Messa es received from operator 0$s P5M' may still be protected accordin to the stored ".- however fallbac# to unprotected mode is allowed. 'OT2A 0efore settin fallbac# to unprotected mode to allowed- other security measures may be activated that assist in identifyin the ori in of the messa e to a certain trust level- e. . T1.P handsha#e for MTforward"M (see .nne( :).

*) Hhen Operator . has completed step , in all his ""<>"2Gs- he informs Operator 0. 3) Hhen Operator . receives confirmation from Operator 0 that all ""<>"2Gs in Operator 0$s P5M' have been set up to allow fallbac# to unprotected mode- Operator . chan es the "P: entries to send unprotected out oin messa es via his ""<>"2Gs- but allow the reception of protected messa es from networ# 0. 8) Hhen Operator . has completed step 3 in all his ""<>"2Gs- he informs Operator 0. 9) Hhen Operator . receives confirmation from Operator 0 that the "P: entries were chan ed to unprotected in all ""<>"2Gs of Operator 0$s networ#- Operator . performs the similar chan e in his ""<>"2Gs.

.3

Tr!")itio" ,-!)e 7ro$ ,rotecte( $o(e to !"ot-er ,rotecte( $o(e

&n order to avoid traffic interruption durin the phase where the used protection mode is modified in the ""<>"2Gs$ "P:s- the followin course of action is recommendedA PreconditionA &t is assumed that operator .$s policy is to protect all messa es e(chan ed with operator 0$s P5M' with protection mode Finte rityRauthenticityFC now both Operators are oin to modify the policy to protect messa es sent to the other P5M' with protection mode Finte rityRauthenticityRconfidentialityF. 'OT2A The transition from protection mode Finte rityRauthenticityRconfidentialityF to protected mode Finte rityRauthenticityF is similar as described below but with the protection modes reversed.

,) Operator . and 0 both modify the "P: by addin Finte rityRauthenticityRconfidentialityF to the acceptable protection modes- i.e. they will now allow both Finte rityRauthenticityRconfidentialityF and Finte rityRauthenticityF as acceptable protection modes- but out oin messa es are still sent with Finte rityRauthenticityF. *) Hhen step , is completed in all ""<>"2Gs of Operator 0$s P5M'- Operator . is informed. "imilarly Operator . will inform Operator 0 after performin the actions of "tep ,. 3) Hhen Operator . (or Operator 0) receives confirmation from Operator 0 (or Operator .) that the "P:s in all ""<>"2Gs have been updated to accept the new protection mode in addition to the old one- Operator . (or operator 0) modifies the "P: such that out oin messa es in his ""<>"2Gs towards Operator 0 (or operator .) are send with only with protection mode Finte rityRauthenticityRconfidentialityF. 8) Hhen step 3 is completed in all ""<>"2Gs of Operator .$s (or Operator 0Ls) P5M'- he informs Operator 0 (or Operator .). 9) Hhen receivin confirmation that the "P:s have been updated in all ""<>"2Gs of Operator . (or Operators 0$s) P5M'- Operator 0 (or Operator .) modifies the "P: by removin Finte rityRauthenticityF from the acceptable protection modes.

3GPP

$elease %%

'(

3GPP TS 33&'() *%%&(&( '(%'+(,!

A""e3 8 ("or$!ti9e)1 U)i"# T AP -!"()-!ke 7or SMS tr!")7er

The "M" GatewayG&nterwor#in M"1 operator and the servin node (M"1 or "G"') operator may a ree to use the T1.P handsha#e as a countermeasure a ainst "M" fraud for messa es e(chan ed between their networ#s (for detailed messa e flows see T" *=.++* D*E). . limited level of authenticity is provided by the followin mechanisms.

8.1

Mo.i+e Ter$i"!te( SMS

SMS G!tew!y B
T1S0e in (.1- no payload) T1S1ontinue (.1- no payload) T1S1ontinue (mt>forward"M with payload) T1S2nd (mt>forward"M ac#)

:,er!tor @

0i1ure D&%2 9AP mt+0orward+S9 messa1es usin1 a T"AP 6andshakes &f the servin networ# receives an mt>forward>"M M.P messa e which uses the T1S1ontinue to transfer the M.P payload then it is uaranteed that the "11P callin party address of the (empty) T1S0e in messa e is authenticotherwise the first T1>continue messa e would be sent to the falsified address. The correct messa e flow is uaranteed by the T1.P transaction capabilities (use of Transaction &:). 3nfortunately there are some ways in which a fraudulent "M" Gateway operator (called the ori inator in bullets (a) and (b)) may try to circumvent the implicit "11P address authentication provided by the T1.P handsha#e. (a) The ori inator includes a falsified "M">GM"1 address as "M>/P>O. in the mt>forward>"M payload carried by the T1>continue (third messa e in fi ure :.,) (b) The ori inator tries to predict the T1.P transaction &: assi ned by the servin node- which is to be used within the third messa e- and spoofs the third messa e without waitin for the second messa e. This attac# has to be carried out within the ri ht time window. &f T1.P handsha#e is to be used- the followin measure shall be ta#en within the networ# of the servin node in order to counteract the spoofin possibilities of a malicious mt>7orward>"M ori inator. M2.">,A The receivin networ# shall verify if the received "M">GM"1 address (as "M>/P>O. in the third messa e) may be used from the "11P 1allin Party .ddress. "ome operators use a sin le "M"> GM"1 address for a ran e of "11P 1allin Party .ddresses and this will need to be ta#en into consideration.

&f T1.P handsha#e is to be used- at least one of the followin measures shall be ta#en within the networ# of the servin node in order to counteract the spoofin possibilities of a malicious mt>7orward>"M ori inator. M2.">*aA The receivin node shall use mechanisms to ensure that the destination T1.P transaction &: which needs to be used within the third messa e is predictable with a probability of less than , G *,+ for a third party #nowin all previous T1.P transaction &: values.

3GPP

$elease %%

'%

3GPP TS 33&'() *%%&(&( '(%'+(,!

M2.">*bA

The receivin networ# shall wait n seconds before it processes the third messa e (T1>continue(mt> forward"M with payload)). This should ensure that the T1Sabort from the spoofed networ# is processed at the destination node earlier than a T1Scontinue includin a successfully uessed T1.P Transaction &: value.

The followin roupin method may be used for an operator to radually introduce the T1.P handsha#e for mt> 7orward>"M messa es. :efine an Toperator roup>,L as a trusted operator roup and Toperator roup>*L as an un>trusted operator roup. . ree that roup>, uses the T1.P handsha#e- while roup>* does not use the T1.P handsha#e. .s specified by T" *=.++* D*E this re?uires that the "M" Gateway operators belon in to roup>, shall either use application conte(t* or 3 for mt>7orward>"M. The mana ement of the two roups re?uires that the servin networ# shall implement a policy table of "11P 1allin Party .ddresses for which a T1.P handsha#e is re?uired. &f the above described roupin method is used then the followin measure shall be ta#en at the servin networ# in order to counteract the spoofin possibilities of a malicious mt>7orward>"M ori inator that tries to circumvent the policy table chec#s. M2.">3A The servin networ# shall verify that the "11P 1allin Party .ddress of a first messa e with a payload (i.e. not usin the T1.P handsha#e) is not from an "M">GM"1>address as "M>/P>O. that shall use the T1.P handsha#e.

The benefit ained for operators that belon to roup>, is that spoofin of their "M">GM"1>addresses is practically difficult if the policy table has been administrated accurately.

8.2

Mo.i+e :ri#i"!te( SMS

Ser9i"# :,er!tor @ SMS 6"terworki"# MS :,er!tor B
T1S0e in (.1- no payload) T1S1ontinue (.1- no payload) T1S1ontinue (mo>forward"M with payload) T1S2nd (mo>forward"M ac#)

0i1ure D&'2 9AP mo+0orward+S9 messa1es usin1 a T"AP 6andshakes &f the servin networ# sends an mo>forward>"M M.P messa e which uses the T1S1ontinue to transfer the M.P payload then it is uaranteed that the "11P callin party address of the (empty) T1S0e in messa e is authenticotherwise the first T1>continue messa e would be sent to the falsified address. The correct messa e flow is uaranteed by the T1.P transaction capabilities (use of Transaction &:). 3nfortunately there are some ways in which a fraudulent servin (M"1 or "G"') operator (called the ori inator in bullets (a) and (b)) may try to circumvent the implicit "11P address authentication provided by the T1.P handsha#e. (a) The ori inator includes a falsified M"&":' as "M>/P>O. within the mo>forward>"M payload carried by the T1>continue (third messa e in fi ure :.*) (b) The ori inator tries to predict the T1.P transaction &: assi ned by the servin node- which is to be used within the third messa e- and spoofs the third messa e without waitin for the second messa e. This attac# has to be carried out within the ri ht time window. &f T1.P handsha#e is to be used- the followin measure may be ta#en within the networ# of the "M" &nterwor#in M"1 in order to counteract the spoofin possibilities of a malicious mo>7orward>"M ori inator.

3GPP

$elease %%

''

3GPP TS 33&'() *%%&(&( '(%'+(,!

M2.">,A

The receivin node (i.e. "M" interwor#in M"1) may ?uery the K5/ to verify if the received "11P 1allin Party .ddress of the mo>forward>"M is from the same networ# which is currently servin the subscriber (M"&":' contained in "M>/P>O. in the third messa e).

&f the T1.P handsha#e is to be used- then at least one of M2.">*a and M2.">*b of clause :., shall also be applied. The followin roupin method may be used for an operator to radually introduce the T1.P handsha#e for mo> 7orward>"M messa es. :efine an $operator roup>,$ as a trusted operator roup and $operator roup>*$ as an un>trusted operator roup. . ree that roup>, uses the T1.P handsha#e- while roup>* does not use the T1.P handsha#e. .s specified by T" *=.++* D*E this re?uires that the M"1 operators belon in to roup>, shall either use application conte(t* or 3 for mo>7orward>"M. The mana ement of the two roups re?uires that the networ# of the "M" &nterwor#in M"1 shall implement a policy table of ori inatin "11P>addresses for which a T1.P handsha#e is re?uired. &f the above described roupin method is used then the followin measure shall be ta#en at the networ# of the "M" &nterwor#in M"1 in order to counteract the spoofin possibilities of a malicious mo>7orward>"M ori inator that tries to circumvent the policy table chec#s. M2.">3A The "M" &nterwor#in M"1 shall verify that the "11P 1allin Party address of a first messa e with a payload (i.e. not usin the T1.P handsha#e) is not from an address that shall use the T1.P handsha#e.

The benefit ained for operators that belon to roup>, is that mo>7orward>"M spoofin for their subscribers- while roamin within roup>,- becomes practically difficult if the policy table has been administrated accurately.

3GPP

$elease %%

'3

3GPP TS 33&'() *%%&(&( '(%'+(,!

A""e3 0 (i"7or$!ti9e)1 -!"#e -i)tory

Date 0%-200& 09-200& 11-200& 02-200% 02-200% 200%-03 200%-0% 200%-0% 200%-0% 200%-09 200?-12 2009-12 2011-03 2012-09 TSG : TSG Doc& SA3-39 SA3-40 SA3-41 SA3-42 Po)t SA3C42 SP-31 SP-0%0210 SP-32 SP-0%03?& SP-32 SP-32 SP-33 --SP-0%03?& SP-0%03?& SP-0%0%%1 ---"$ "han1e history $ev "at Su#ject;"omment /ir)t 9er)io" o7 T AP u)er )ecurity .!)e( o" TS33.200 V%.1.0 8ocu$e"t) S3-0&0&&1,&%1,&%2,&%3,&%4 8ocu$e"t) S3-0&0%99,400,401 8ocu$e"t) S3-0&00&2,&3,&4,&&,&%,&4 0(itori!+ correctio") / / / ; ---A,,ro9e( !t SA C31 'e$o9e (et!i+e( SSN "u$.eri"# U,(!ti"# re7ere"ce) to St!#e 3 (re$o9i"# 0(itorD) Note) +!ri7ic!tio" o7 $e))!#e routi"# .etwee" P*MN) U)i"# T AP)ec wit-i" ! -u.-!"(-),oke !rc-itecture U,#r!(e to 'e+e!)e ? U,#r!(e to 'e+e!)e 9 U,#r!(e to 'e+e!)e 10 <ld New 0.0.0 0.1.0 0.1.0 0.2.0 1.0.0 2.0.0 0.2.0 1.0.0 2.0.0 2.0.1 =7

0001 0002 0003 0004 1 -------

2.0.1 4.0.0 4.0.0 4.1.0

S0 4N8ST AP)ec 4.0.0 4.1.0 S0 4N8ST AP)ec 4.0.0 4.1.0 S0 4N8ST AP)ec 4.1.0 4.2.0 S0 4N8ST AP)ec 4.2.0 ?.0.0 -?.0.0 9.0.0 -9.0.0 10.0.0 -U,(!t 10.0.0 %%&(&( e to 'e+11 9er)io " (M )

3GPP