TIA IS-778-1999 Wireless Authentication Enhancements Descriptions《无线认证增强描述》.pdf

《TIA IS-778-1999 Wireless Authentication Enhancements Descriptions《无线认证增强描述》.pdf》由会员分享，可在线阅读，更多相关《TIA IS-778-1999 Wireless Authentication Enhancements Descriptions《无线认证增强描述》.pdf（111页珍藏版）》请在麦多课文档分享上搜索。

1、 STD-EIA TIA/IS-778-ENGL 1999 m 323Lib00 Ob12773 771 m O0 CI CI TIA/EIA INTERIM STANDARD Wireless Authentication Enhancements Descriptions TI Al EI Al IS-778 MARCH 1999 TELECOMMUNICATIONS INDUSTRY ASSOCIATION Eirdronic Industries Aiiiancc STDmEIA TIA/IS-778-ENGL 1997 H 3234b00 Ob12974 828 H NOTICE T

2、IA/EIA Engineering Standards and Publications are designed to serve the public interest through eliminating misunderstandings between manufacturers and purchasers, facilimting interchangeability and improvement of products, and assisting the purchaser in selecting and obtaining with minimum delay th

3、e proper product for his particular need. Existence of such Standards and Publications shall not in any respect preclude any member or nonmember of TIA/EIA from manufacturing or selling products not conforming to such Standards and Publications, nor shall the existence of.such Standards and hblicati

4、ons preclude their voluntary use by those other than TIAEIA members, whether the standard is to be used either domesticaIly or internatiodly. Standards and Publications are adopted by TIA/EIA in accordance with the American National Standards Institute (ANSI) patent policy. By such action, TIAEIA do

5、es not assume any liability to any patent . owner, nor does it assume any obligation whatever to parties adopting the Standard or Publication. ?IA/EIA INTERIh4 STANDARDS TIAEIA Interim Standards contain information deemed to be of technical value to the industry, and are published at the request of

6、the originating Committee without necessarily following the rigorous public review and resolution of comments which is a procedh part of the development of a TIAEiA Standard. TIA/EIA Interim Standards should be reviewed on an annual basis by the formulating Committee and a decision made on whether t

7、o proceed to develop a TIA/EIA Standard on this subject. TIA/EIA Interim Standards must be cancelled by the Committee and removed from the TIA/EIA Standards Catalog before the end of their third year of existence. Publication of this TIA/EIA Interim Standard for mal use and comment has been approved

8、 by the Telecommunications Industry Association. Dismbution of this TIA/EIA interim Standard for comment shall not continue beyond 36 months from the date of publication. It is expected that following this 36 month period, dus TIA/EIA Interim Standard, revised as necessary, will be submitted to the

9、American National Standards Institute for approval an American National Standard, Suggestions for revision should be directed to: Eric Schimmel, Standards R for the Lnique Challenge, i I 1 1 RANDU I 1 AUTHU R b. The Tandem MSC adjusts the InterMSCCircuitID to identify the circuit between it and the

10、Serving MSC. and forwards the AUTHDIRFWD to the Serving MSC. Parameters are as in Step-a. The Serving MSC sends a Unique Challenge Order to the MS using the RANDU value received. The Serving MSC receives the MS response to the Unique Challenge. c. d. TIfEiA41.3-D Modifications 5 AuthenticationDirect

11、iveForward STD*EIA TIAIIS-778-ENGL 1999 3234b00 Ob12785 b03 e. The Serving MSC reports the outcome of the Unique Challenge by initiating an authdirfwd to the Tandem MSC. Parameters 1 Usage I Type 1 i ueChallen Repom the outcome of R I /Y- 5 1 %e unique I f. The Tandem MSC forwards the authdirfwd to

12、the Anchor MSC. Parameters are as in SteD-e t 2 3 4 5 6 7 8 9 10 11 2 , 13 14 15 16 17 18 19 x) 21 22 23 24 25 6 27 28 29 30 31 32 33 Y 35 36 37 38 39 u) 41 u u U 45 ui 47 40 49 54 51 u 53 u 56 56 n 59 59 60 AuthenticationDirectiveForwad 6 TINEIA-41.3-D Modifications 1 2 3 4 5 6 7 8 9 10 11 12 13 14

13、 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 3 35 36 37 38 39 40 41 42 43 44 45 4s 47 48 49 50 51 Y u 54 55 56 57 58 59 60 l I AUTHDIRFWD MIN, IMSCCID, UPDCOUNI 4.2.X Successful AuthenticationDirectiveForward (COUNT Update) (new for TINEIA-41.3-0 Section 4) This scenario describes the s

14、uccessful use of the AuthenticationDirectiveforw3rd operation to perform a COUNT Update. I .a Anchor System Tandem System Serving System . . . SSCCID. UPDCOUNT . I b . . . .d i. .i _._ _ _ _ s .c E, j .,q-_-_ _ -_-_-_-*. .1 ii C parameter update order parameter update confirmation AD= ADM i authdirf

15、wd COUNTRPI .-. . , -e -f t authdirwd COUNTRPT a. b. C. d. C. f. Figure 4.2.X Successful AuthenticationDirectiveForward (COUNT Update) Following an intersystem handoff, the Anchor MSC receives a request to perform a CallHistoryCount (COUNT) update for the indicated MS. The MSC sends an AUTHDIRFWD to

16、 the Tandem MSC. 1 Parameters I Usage I Type I i MIS ; MS MIN. /RI 1 IMSCCID i 4 IR/ . Specifies the trunk in a dedicated trunk goup 1 between the two MSCs for the call involved. UPDCOUNT Indicates that the CallHistoryCouni update I procedure shall be initiated. The Tandem MSC adjusu the InterMSCCir

17、cuitD to identi the circuit between it and the Serving MSC. and forwards the AUTHDIRFWD to the Serving MSC. Parameten are as in Step-a. The Serving MSC wnds a Parameter Update order to the MS. The MS increments its value of the CallHistoryCount and sends confirmation to the Serving MSC. The Serving

18、MSC reports the outcome of the COUNT Update by initiating an au:hdirfwd u) the Tandem MSC. , Parameters usage I Type : COUhTRPT Reports the outcome of the COUNT Update. 1 R The Tandem MSC forwards the authdirfwd to the Anchor MSC. TIAIEIA-41 .SD Modifications 7 AuthenticationDirectiveFoward STD*EIA

19、TIAIIS-778-ENGL 1779 323i.lb00 Ob12987 q8b . / i TINEINIS-778 3.2 AUTHENTICATION ON SUSPICIOUS CALL . :. I ! ORIGINATION The following TIAEiA-41.3-D Section 4.4 modifications enhance authentication when SSD is not shared, a call origination occurs and the dialed digits are determined to be suspiciou

20、s. A new optional parameter (SuspiciousAccess) indicates that the serving system has determined-that the dialed digits are suspicious. indicating to the AC that a unique challenge may be necessary. 4.4.X Authentication on Suspicious Call Origination (SSD not shared) (New for TIA/EIA-41.3-D, Section

21、4.4) This operation scenario describes the use of the AuthenticationRequest operation to authenticate an MS which is attempting a suspicious call origination on a serving system that is not sharing SSD with the AC. The MS is aware that authentication is required on all system accesses. The result of

22、 the operation is to allow origination and to initiate a Unique Challenge. Sewing System /i-1 r-;l r-I ;ci I! AUTHREQ AkhReqParametersl , RAND, AUTHR. COUNT, DGTSDIAL. AUTHDATP . :. . :. I JT .I L 1 authreq Encryptionlnformation, AihReqParameters2, ,. RANDU, ATHU, NO! . -:. * I. / Figure 4.4.X Authe

23、ntication on Suspicious Call Origination (SSD not shared) AuthenticationRequest 8 TIAEIA-41.3-D Modifications 1 2 3 4 5 6 7 8 9 io ti .12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 a 30 31 32 33 30 35 36 37 38 39 40 41 42 U U Is 46 47 48 49 50 51 a 53 51 55 56 !17 se 9 60 TlPzEllllS-778 AuthReq

24、Parameters 1 -SYSACCTYPE SUSACC 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 31 32 33 34 35 26 37 38 39 40 41 42 43 M 45 46 47 4a 49 50 51 u u 54 55 56 57 SB 59 60 ! l a Set of parameters in AUTHREQ: ! SystemAccessType. Type of system access = I R j ! SuspiciousAc

25、cess. Type of suspicious access. i R ! call origination. (e. qualreq . I AUTHREQ o/ generated by the AC. 1 SipaiingMessageEncrptionKey. Include if j O generated by the AC. I. VoicePrivacyMask. include if generated by the 1 O ! .I 1 AC. 1 1 1 2 3 4 5 6 7 a 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23

26、24 25 26 27 28 29 30 31 32 33 Y 35 36 37 38 39 40 41 42 43 44 45 46 47 49 49 50 51 52 53 54 55 55 57 58 59 60 Note: The authreq may also include SSD and directives to issue a Unique Challenge. to update the MS SSD, or to update the MS COUNT according to AC local administrative practices. These updat

27、e scenarios ware described in Sections 5.4.6. 5.4.7, and 5.4.9. Alternatively. the authreq may include DenyAccess. The HLR forwards the authreq to VLR-2. Q. Encryptioninfomation: (CDMAPLCM SMEKEY VPM ASK CDMAPrivateLongCodeMask. Include if available and MS IS subscribed to Voice privacy. availabic.

28、IS subscnbed to Voice Privacy. SignalingMcssageEncryptionKey . Include if VoicePnvacyMask. Include if available and MS p. VLR-2 returns an authreq to MSC-2. Following successful authentication of the MS. MSC-2 assigns the MS to an analog voice channel or a digital traffic channel or retains the exis

29、ting assignment. TIPJEIAJ1.3-D Modifications 13 Authentication STD-EIA TIA/IS-?-ENGL 1779 m 323i.lb00 Ob12993 7T m TINEINIS-778 1 2 3 5.4.4 Authentication on Voice Channel Only (TIAiElA-41.3-D, page 3-1 81) 4 This scenario describes the intersystem message flow required for systems that support auth

30、entication only on the voice or traffic channel. . . . . . ._._. . . . . . . . . . challenge response Figure 96 Authentication on Voice Channel Only 5 6 7 8 9 10 11 12 13 14 15 16 17 le 19 20 21 21! 23 24 25 26 27 2a 29 P 31 32 33 34 35 36 37 38 39 10 41 42 a 44 45 46 47 48 49 50 51 Y 53 54 55 56 n

31、58 56) 60 Authentication 14 TINEIA-41.3-0 Modifications 1 2 3 4 5 6 7 a 9 10 11 12 13 ia 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 ao ai 42 43 a4 45 46 47 4.9 49 50 51 52 u 54 55 m n 58 59 60 TIKE IN1 S-776 a. The MS determines from the Overhead Message Train (OMT) t

32、hat authentication is not required on system accesses (AUTH=O). b. The MS sends a system access message (registration. origination or page response) to the Serving MSC. providing its MIN and ESN only. 8 If requ ired e.0. if the CU ment system access IS an on cination or DaOe resmnse. and c. the MSs

33、Drofile is not available). the MSC sends a OUATJREO to VLR in order to determine if the MS shou Id be authenticated and to retrieve the MS D rofile. ; d. The the ervino the S. e. The HLR retrieves the MS D rofile and includes it in the uualreo that it sends to - VLR. The W.R fo wards the malrea to t

34、he MSC. In this scenario. the MS Drofile indicates that the MS sh ould be authenticated. the Serving MSC sends an AUTHREO to the Servinv VLR and includes the SvstemAccessTvpe Darameter set to indicate the tvDe of MS access. f. c. f. If SSD is shared with the current serving system, then the VLR shal

35、l generate the RANDU locally. calculate AUTHU by executing CAVE. and proceed to Step 1; otherwise, the VLR forwards the AUTHREQ to the HLR associated with the MIN. The HLR forwards the AUTHREQ to its AC. The AC verifies the MIN and ESN reported by the MS. The AC chooses a RandomVariableUniqueChallen

36、oe (RANDU) and executes CAVE using the SSD-A currently stored. ESN, MIN1 and MIN2 associated with the MS to produce an .4uthenticationResDonseUniaueChallene -trttliqot i( AUTHU). The AC sends an authreq to the IUR including RANDU and the expected AUTHU result. The HLR forwards the authreq to the Ser

37、ving VLR. The Serving VLR sends an authreq to the Serving MSC, containing the values of AUTHU and RANDU received in the authreq from the HLR (if SSD is not shared). or the values calculated locally (if SSD is shared). The Serving MSC assigns the MS to an analog voice channel or a digital traffic cha

38、nnel. Optionally (especially if the system access is a registration), the Unique Challenge messages may be exchanged over the control channel. before assignment of a voice or traffic channel. as described in the following steps. The Serving MSC sends a Lnique Challenge order to the MS using the RAND

39、U provided in the ac:=nreq. The MS executes CAVE using RANDU and the SSD-A currently stored. ESN, MIN1 and MIN2 to produce an AUTHU p which is then sent to the Serving MSC. The Serving hlSC compares the value of AUTHU provided in the authreq with that received from the MS. TINEIA-41.3-D Modification

40、s 15 Authentication STD*EIA TIAIIS-77A-ENGL 1777 323LIbOO Ob12775 552 = The Serving MSC sends an ACREPORT to the Serving VLR indicating success or If SSD is not shared. the VLR shall forward the ASREPORT to the HLR. If SSD is shared and the Unique Challenge was successful. the VLR proceeds to Step-l

41、. If to the HLR. For this scenario, we assume that SSD is not shared. The HLR forw;irds the ASREPORT to its AC. failure of the unique challenge. SSD is shared and the Unique Challenge failed. the VLR shall send an AFR- =PORT The AC responds with an acreport that may include SSD and directives to den

42、y access, to update SSD, or update COUNT according to the AC local administrative practices (see Sections 5.4.6 and 5.4.7). 9. I. 1 2 3 0 5 6 8 9 10 11 12 13 The HLR forwards the asreport to the Serving VLR. The Serving VLR sends an asreport to the Serving MSC. 14 15 16 11 ie 19 20 21 22 23 24 25 26

43、 27 26 29 30 31 P 33 3 35 36 31 38 39 OD 41 u 43 u 45 4 47 4a 49 50 51 !12 53 51 56 56 57 58 59 Bo Authentication 16 TIAIEIA-41.3-D Modifications I TINEIAIS-778 1 2 3.4 MISCELLANEOUS AUTHENTICATION 3 ENHANCEMENTS 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 31 32 33 34 3s

44、 36 37 38 39 00 41 u 43 U 45 46 47 u) 43 50 51 Y 53 54 55 56 57 58 59 60 The following TIAIEIA-41.3-0 Section 5.4 changes correct editorial errors and clarify authentication information flows. TiNEIA-41.3-D Modifications 17 Authentication TIAEINIS-778 5.4.9 SSD Update When SSD is Shared (TIAEIA-41.3

45、-D. page 3-1 93) Serving System .a AUTHDIR RANDSSD, SSD -.- C -d :-.-”- Am ADT . . authdir _._-_- -e f *-*g .*h _. authdir i . :. i authdir f ASRRT . .-.- - . . . . . . . r,* I _ update ”,. SSD (RANDSSD) . . . . . . . . .:. . . , . . - . . - . .J . - - . . - - - . . . . . : _ _. I *.- _._ Figure 101

46、 SSD Update When SSD is Shared 11 a-t. These steps at retained unchanoed. II 1 2 3 4 5 6 7 8 9 10 11 2 I 13 14 15 16 I? 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 n 38 39 40 41 42 U U 45 48 47 48 49 50 51 9 u 54 55 56 57 58 54 do Authentication 18 TIAEIA-41.3-O Mddicatins STD-EIA TIA/I

47、S-778-ENGL 1997 3239b00 b12998 2b1 . 1 2 3 4 5 6 7 8 9 10 11 12 13 14 1s 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 3.5 36 37 38 39 bo 41 4 43 44 45 46 47 48 49 50 51 Y u 56 55 56 57 58 59 60 TINEIAIS-77E 5.4.11 VLR Initiated Unique Challenge When SSD is Shared (TIA/EIA-41.3-D, page 3-

48、198) This scenario describes the intersystem message flow required to support a Unique Challenge when SSD is shared. Serving System FJ 1 authdir unique challenge ,“.“.“ (RANDUj 1 ASREPORTI I. CHYPT 14 d- asreport! AFREPORT RPTTYP . I ! ._I a b . .i. . Id . /.l. 9 iT RPTTYP . .I+. . .j a. b. C. d. e.

49、 Figure 103 VLR Initiated Unique Challenge When SSD is Shared. The Serving VLR chooses a -dom VariableUniqueChalle nge kr+abl+(RANDU) and executes CAVE using the SSD-A currently stored. ESN. MINI and MIN2 associated with the MS to produce an Whenti catiowonseUniaueC hallengg Wkg4AUIHL) The VLR sends an ASTFDIR to the current Serving MSC. The ax:=hdiz from the Serving MSC to the VLR serves only to inform the