TIA-945-2006 MAP Support of Authentication and Key Agreement (AKA)《MAP对认证和密钥协商协议(AKA)的支持》.pdf

《TIA-945-2006 MAP Support of Authentication and Key Agreement (AKA)《MAP对认证和密钥协商协议(AKA)的支持》.pdf》由会员分享，可在线阅读，更多相关《TIA-945-2006 MAP Support of Authentication and Key Agreement (AKA)《MAP对认证和密钥协商协议(AKA)的支持》.pdf（114页珍藏版）》请在麦多课文档分享上搜索。

1、 TIA-945 APPROVED: FEBRUARY 1, 2006 REAFFIRMED: JUNE 21, 2012 TIA-945 February 2006MAP Support of Authentication and Key Agreement (AKA) NOTICE TIA Engineering Standards and Publications are designed to serve the public interest through eliminating misunderstandings between manufacturers and purchas

2、ers, facilitating interchangeability and improvement of products, and assisting the purchaser in selecting and obtaining with minimum delay the proper product for their particular need. The existence of such Standards and Publications shall not in any respect preclude any member or non-member of TIA

3、 from manufacturing or selling products not conforming to such Standards and Publications. Neither shall the existence of such Standards and Publications preclude their voluntary use by Non-TIA members, either domestically or internationally. Standards and Publications are adopted by TIA in accordan

4、ce with the American National Standards Institute (ANSI) patent policy. By such action, TIA does not assume any liability to any patent owner, nor does it assume any obligation whatever to parties adopting the Standard or Publication. This Standard does not purport to address all safety problems ass

5、ociated with its use or all applicable regulatory requirements. It is the responsibility of the user of this Standard to establish appropriate safety and health practices and to determine the applicability of regulatory limitations before its use. (From Project No. 3-4393, formulated under the cogni

6、zance of the TIA TR-45 Mobile (b) there is no assurance that the Document will be approved by any Committee of TIA or any other body in its present or any other form; (c) the Document may be amended, modified or changed in the standards development or any editing process. The use or practice of cont

7、ents of this Document may involve the use of intellectual property rights (“IPR”), including pending or issued patents, or copyrights, owned by one or more parties. TIA makes no search or investigation for IPR. When IPR consisting of patents and published pending patent applications are claimed and

8、called to TIAs attention, a statement from the holder thereof is requested, all in accordance with the Manual. TIA takes no position with reference to, and disclaims any obligation to investigate or inquire into, the scope or validity of any claims of IPR. TIA will neither be a party to discussions

9、of any licensing terms or conditions, which are instead left to the parties involved, nor will TIA opine or judge whether proposed licensing terms or conditions are reasonable or non-discriminatory. TIA does not warrant or represent that procedures or practices suggested or provided in the Manual ha

10、ve been complied with as respects the Document or its contents. If the Document contains one or more Normative References to a document published by another organization (“other SSO”) engaged in the formulation, development or publication of standards (whether designated as a standard, specification

11、, recommendation or otherwise), whether such reference consists of mandatory, alternate or optional elements (as defined in the TIA Engineering Manual, 4thedition) then (i) TIA disclaims any duty or obligation to search or investigate the records of any other SSO for IPR or letters of assurance rela

12、ting to any such Normative Reference; (ii) TIAs policy of encouragement of voluntary disclosure (see Engineering Manual Section 6.5.1) of Essential Patent(s) and published pending patent applications shall apply; and (iii) Information as to claims of IPR in the records or publications of the other S

13、SO shall not constitute identification to TIA of a claim of Essential Patent(s) or published pending patent applications. TIA does not enforce or monitor compliance with the contents of the Document. TIA does not certify, inspect, test or otherwise investigate products, designs or services or any cl

14、aims of compliance with the contents of the Document. ALL WARRANTIES, EXPRESS OR IMPLIED, ARE DISCLAIMED, INCLUDING WITHOUT LIMITATION, ANY AND ALL WARRANTIES CONCERNING THE ACCURACY OF THE CONTENTS, ITS FITNESS OR APPROPRIATENESS FOR A PARTICULAR PURPOSE OR USE, ITS MERCHANTABILITY AND ITS NONINFRI

15、NGEMENT OF ANY THIRD PARTYS INTELLECTUAL PROPERTY RIGHTS. TIA EXPRESSLY DISCLAIMS ANY AND ALL RESPONSIBILITIES FOR THE ACCURACY OF THE CONTENTS AND MAKES NO REPRESENTATIONS OR WARRANTIES REGARDING THE CONTENTS COMPLIANCE WITH ANY APPLICABLE STATUTE, RULE OR REGULATION, OR THE SAFETY OR HEALTH EFFECT

16、S OF THE CONTENTS OR ANY PRODUCT OR SERVICE REFERRED TO IN THE DOCUMENT OR PRODUCED OR RENDERED TO COMPLY WITH THE CONTENTS. TIA SHALL NOT BE LIABLE FOR ANY AND ALL DAMAGES, DIRECT OR INDIRECT, ARISING FROM OR RELATING TO ANY USE OF THE CONTENTS CONTAINED HEREIN, INCLUDING WITHOUT LIMITATION ANY AND

17、 ALL INDIRECT, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES (INCLUDING DAMAGES FOR LOSS OF BUSINESS, LOSS OF PROFITS, LITIGATION, OR THE LIKE), WHETHER BASED UPON BREACH OF CONTRACT, BREACH OF WARRANTY, TORT (INCLUDING NEGLIGENCE), PRODUCT LIABILITY OR OTHERWISE, EVEN IF ADVISED OF THE POSSIBILITY O

18、F SUCH DAMAGES. THE FOREGOING NEGATION OF DAMAGES IS A FUNDAMENTAL ELEMENT OF THE USE OF THE CONTENTS HEREOF, AND THESE CONTENTS WOULD NOT BE PUBLISHED BY TIA WITHOUT SUCH LIMITATIONS. REVISION HISTORYCopyright Telecommunications Industry Association, 2005All rights reserved.This document is subject

19、 to change.FOREWORDThis foreword is not part of this standard.This document modifies TIA-41-E to add support for Enhanced Subscriber Authentication based on AKA.The words “shall” and “shall not” identify requirements to be followed strictly to conform to this documentand from which no deviation is p

20、ermitted. “Should” and “should not” indicate that one of several possibilitiesis recommended as particularly suitable, without mentioning or excluding others, that a certain course ofaction is preferred but not necessarily required, or that (in the negative form) a certain possibility or courseof ac

21、tion is discouraged but not prohibited. “May” and “need not” indicate a course of action permissiblewithin the limits of the document. “Can” and “cannot” are used for statements of possibility and capability,whether material, physical or causal.Revision Date RemarksTIA-945 October, 2005 Initial Publ

22、icationTIA-945iMAP Support of Authentication and Key Agreement (AKA)ContentsContents iList of Tables iv1 Introduction .11.1 Background11.2 Acronyms and Definitions.21.3 Assumptions 31.4 Normative References .52 MAP Information Flow Modifications for AKA 62.1 Basic Automatic Roaming Scenarios 62.1.1

23、Successful AKA on Initial Registration 72.1.2 AKA Failure on Initial Registration 102.1.3 AKA Synchronization Failure on Initial Registration .122.1.4 Successful AKA 142.1.5 AKA Failure Report 162.1.6 HLR Initiated AKA Procedure 182.1.7 VLR Initiated Termination of Security Association .202.1.8 MS-I

24、nitiated AKA Procedure 212.1.9 HLR Initiated Revocation of Security Association with MS 222.1.10 Successful AKA by R-UIM Equipped MS .232.1.11 Foiled Rogue Shell Attack 252.1.12 Repeated AKA Resynchronization Failure on Initial Registration .273 MAP OPERATIONS 303.1 GENERAL 303.2 OPERATION FORMATS.3

25、03.3 OPERATION SPECIFIERS304 OPERATION DEFINITIONS 314.1 AKADirective324.2 AKARequest334.3 AKAStatusReport354.4 AuthenticationRequest 374.4.1 RETURN RESULT (CAVE Variant) .414.4.2 RETURN RESULT (Denial Variant) 434.4.3 RETURN RESULT (ESA/AKA Variant) .444.5 FacilitiesDirective2454.6 InterSystemPage2

26、 464.7 InterSystemSetup.474.8 RegistrationNotification 48TIA-945123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960ii5 PARAMETER DEFINITIONS 495.1 Parameter Identifiers495.2 AKA_AuthenticationVector 505.3 AKA_AuthenticationVectorData.525.4

27、AKA_AuthenticationVectorList535.5 AKA_Keys.545.6 AKA_Report555.7 AKA_VectorCount 565.8 AuthenticationCapability.575.9 AUTS.585.10 RANDA .595.11 SystemCapabilities.60Intersystem Procedures .616 Authentication Request616.1 MSC Initiating an Authentication Request616.2 VLR Receiving AuthenticationReque

28、st INVOKE 656.3 HLR Receiving AuthenticationRequest INVOKE 747 Facilities Directive2 (Handoff Forward) 767.1 Target MSC Receiving a FacilitiesDirective2 INVOKE.768 Intersystem Page2 .788.1 MSC Receiving InterSystemPage2 INVOKE .789 Intersystem Setup 819.1 MSC Initiating an Intersystem Setup.819.2 MS

29、C Receiving InterSystemSetup INVOKE8310 Registration Notification .8510.1 MSC Initiating MS Registration85Intersystem Procedures for New Operations .8611 AKA Directive.8611.1 HLR Initiating AKA Directive 8611.2 VLR Receiving AKADirective INVOKE .8711.3 VLR Initiating AKA Directive 8711.4 VLR Sending

30、 AKADirective INVOKE to MSC.8811.5 MSC Receiving AKADirective INVOKE.8812 AKA REQUEST .9012.1 MSC Initiating an AKA Request.9012.2 VLR Receiving AKARequest INVOKE .9012.3 VLR Initiating AKA Request 9112.4 HLR Receiving AKARequest INVOKE .9212.5 HLR Initiating AKA Request 93PN-3590TIA-945123456789101

31、112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960iii12.6 AC Receiving AKARequest INVOKE . 9413 AKA Status Report .9513.1 MSC Initiating an AKA Status Report 9513.2 VLR Receiving AKAStatusReport INVOKE . 9613.3 HLR Receiving AKAStatusReport INVOKE . 9

32、8OPERATION TIMER VALUES.100ivList of TablesTable 1 Summary of MAP Operations .31Table 2 TIA/EIA-41 MAP Parameter Identifiers .49Table 3 VLR AuthenticationRequest Response73Table 4 AKADirective Error Table .89Table 5 AKARequest Error Table .94Table 6 AKAStatusReport Error Table99TIA-945Introduction12

33、345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758596011 INTRODUCTION1.1 BackgroundEnhanced Subscriber Authentication (ESA) uses 3GPP Authentication and Key Agreement (AKA)procedures for mutual authentication of the MS and the network in the ser

34、ving system. Thesuccessful execution of AKA results in the establishment of a security association (i.e., a set ofsecurity data) between the MS and the serving system. This enables a set of security services to beprovided (e.g., data integrity of a signaling message, signaling information element en

35、cryption, userdata encryption).TIA-9451234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859602 Acronyms and Definitions1.2 Acronyms and DefinitionsTerm DefinitionAKADIR AKADirective INVOKEakadir AKADirective RETURN RESULTAKAK AKA_Keys parameter

36、AKAREPORT AKAStatusReport INVOKEakareport AKAStatusReport RETURN RESULTAKAREQ AKARequest INVOKEakareq AKARequest RETURN RESULTAKARPT AKA_Report parameterAKAV AKA_AuthenticationVectorAKAVC AKA_VectorCountAKAVL AKA_AuthenticationVectorListAKDT AKADirective timerAKRQT AKARequest timerAKSRT AKAStatusRep

37、ort timerAUTN-I Authentication token for integrity checkCK Cipher KeyCOUNT-I Integrity sequence numberESA Enhanced Subscriber AuthenticationIK Integrity KeyMAC Message Authentication CodeMAC-I MAC used for integrity checkingRAND Random challengeRANDA 128-bit RAND (to avoid confusion with CAVE RAND)R

38、ES Response to random challenge calculated by MS/UIMSQN Sequence NumberSQNMSSQN known by the MS/ME/UIMUAK UIM Authentication KeyUMAC UIM-Present MACXRES Expected responseTIA-945Assumptions1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859603

39、1.3 AssumptionsThe following assumptions are applicable for this specification:a. An MS can support both ESA and the current CAVE authentication methodology.An MS can support both ESA and the second generation authentication and privacyprovided by TIA/EIA-41systems.b. Rogue Mobile Equipment ThreatAK

40、A is used to establish a security relationship between the UIM and the serving system.This is based on an authentication vector (AV) generated by the subscribers home system.These scenarios consider the MS to be configured as a removable UIM (R-UIM) insertedinto mobile equipment (ME). Local authenti

41、cation shall be used to protect against the rogueME threat, provided that the use of local authentication is entirely at the homes systemdiscretion. Additionally, support for local authentication is required in serving systems andmobile equipment if the air interface supports local authentication.Lo

42、cal authentication mitigates the threat of a rogue ME that uses subscription and securityinformation obtained from the R-UIM when the R-UIM is not present in the ME.Each authentication vector sent by the AC to the VLR may include a UIM authenticationkey (UAK) that is used to protect against the thre

43、at of rogue MEA TIA/EIA-41AV may include a local authentication key (UAK). It is used by the servingsystem and the UIM to protect against the threat of a rogue MS ME. It is an output of theAKA computation performed by the UIM and AC during the AKA procedure. The UAK isstored in the UIM and never sha

44、red with the ME. c. AKA is used for mutual authentication and key agreementThe purpose of the AKA procedure is for mutual authentication of the UIM and the servingsystem, and to establish new integrity, encryption and local authentication keys. The VLRselects the next unused AV from the ordered arra

45、y of AVs stored in the VLR and sends theAV to the Serving MSC. The MSC sends the UIM the random challenge RAND-A and theauthentication token for network authentication AUTN from the received AV.The UIM computes the expected message authentication code (XMAC). If this is not equalto the MAC received

46、in the AUTN, the UIM sends an authentication rejectback to theMSC and abandons the procedure. In this case, the MSC initiates the Authentication FailureReport procedure.Next the UIM verifies that the sequence number SQN received in the AUTN is acceptable(a test of freshness). If the UIM determines t

47、hat the received SQN is not acceptable, it sendsa synchronization failureback to the MSC and abandons the procedure. The synchroni-zation failureincludes the concealed value of the sequence number stored in the UIM(SQNMS). In this case, the MSC initiates the Authentication Failure Report procedure a

48、ndincludes the SQNMSreceived from the UIM.Next the UIM computes the response to the random challenge (RES) and includes thisparameter in the user authentication response sent back to the VLR. Finally the UIMcomputes the cipher key CK, the integrity key IK and the local authentication key (UAK).The U

49、IM stores this information until the next successful execution of AKA.Upon receipt of a user authentication response the MSC compares RES with the expectedresponse XRES from the selected AV. If XRES equals RES then the authentication of theTIA-9451234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859604 Assumptionsuser has passed, the MSC will use the cipher key (CK), integrity key (IK) and local authen-tication key (UAK) received in the AV. If XRES and RES are different, the MSC initiatesthe Authentication Failure Report procedure.