TIA-102 AACA-2-2003 Project 25 Digital Radio Over-The-Air Reketing (OTAR) Protocol Addendum 2 - Data Link Independent OTAR Addendum 2《项目25-数字广播电台空中下载 (OTAR) 协议 附录2 数据链路独立OTAR》.pdf

《TIA-102 AACA-2-2003 Project 25 Digital Radio Over-The-Air Reketing (OTAR) Protocol Addendum 2 - Data Link Independent OTAR Addendum 2《项目25-数字广播电台空中下载 (OTAR) 协议 附录2 数据链路独立OTAR》.pdf》由会员分享，可在线阅读，更多相关《TIA-102 AACA-2-2003 Project 25 Digital Radio Over-The-Air Reketing (OTAR) Protocol Addendum 2 - Data Link Independent OTAR Addendum 2《项目25-数字广播电台空中下载 (OTAR) 协议 附录2 数据链路独立OTAR》.pdf（46页珍藏版）》请在麦多课文档分享上搜索。

1、 TIA STANDARD ANSI/TIA-102.AACA-2-2003 Approved: March 13, 2003 Project 25 Digital Radio Over-the-Air Rekeying (OTAR) Protocol Addendum 2 Data Link Independent OTAR TIA-102.AACA-2 (Addendum No. 2 to TIA/EIA-102.AACA) MARCH 2003 TELECOMMUNICATIONS INDUSTRY ASSOCIATION Representing the telecommunicati

2、ons industry in association with the Electronic Industries Alliance Copyright Telecommunications Industry Association Provided by IHS under license with EIANot for ResaleNo reproduction or networking permitted without license from IHS-,-,-NOTICE TIA Engineering Standards and Publications are designe

3、d to serve the public interest through eliminating misunderstandings between manufacturers and purchasers, 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 existenc

4、e of such Standards and Publications shall not in any respect preclude any member or non-member of TIA 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 memb

5、ers, either domestically or internationally. Standards and Publications are adopted by TIA in accordance 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 a

6、dopting the Standard or Publication. Further details of the development process are available in the TIA Engineering Manual, located at http:/www.tiaonline.org/standards/sfg/engineering_manual.cfm This Standard does not purport to address all safety problems associated with its use or all applicable

7、 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 Standards Proposal No. 3-4824-AD2, formulated under the cognizance of the TIA TR-8.3

8、 Subcommittee on Encryption.) Published by TELECOMMUNICATIONS INDUSTRY ASSOCIATION 2003 Standards and Technology Department 2500 Wilson Boulevard Arlington, VA 22201 U.S.A. PRICE: Please refer to current Catalog of TIA TELECOMMUNICATIONS INDUSTRY ASSOCIATION STANDARDS AND ENGINEERING PUBLICATIONS or

9、 call Global Engineering Documents, USA and Canada (1-800-854-7179) International (303-397-7956) or search online at http:/www.tiaonline.org/standards/search_n_order.cfm All rights reserved Printed in U.S.A. Copyright Telecommunications Industry Association Provided by IHS under license with EIANot

10、for ResaleNo reproduction or networking permitted without license from IHS-,-,-NOTICE OF DISCLAIMER AND LIMITATION OF LIABILITY The document to which this Notice is affixed (the “Document”) has been prepared by one or more Engineering Committees or Formulating Groups of the Telecommunications Indust

11、ry Association (“TIA”). TIA is not the author of the Document contents, but publishes and claims copyright to the Document pursuant to licenses and permission granted by the authors of the contents. TIA Engineering Committees and Formulating Groups are expected to conduct their affairs in accordance

12、 with the TIA Engineering Manual (“Manual”), the current and predecessor versions of which are available at http:/www.tiaonline.org/standards/sfg/engineering_manual.cfm. TIAs function is to administer the process, but not the content, of document preparation in accordance with the Manual and, when a

13、ppropriate, the policies and procedures of the American National Standards Institute (“ANSI”). TIA does not evaluate, test, verify or investigate the information, accuracy, soundness, or credibility of the contents of the Document. In publishing the Document, TIA disclaims any undertaking to perform

14、 any duty owed to or for anyone. The use or practice of contents 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 patent

15、s and published pending patent applications are claimed and 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 an

16、y claims of IPR. 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 claims of compliance with the contents of the Document. ALL WARRANTIES, EXPRESS OR IMPLIED, ARE DISCLAIMED,

17、 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 NON-INFRINGEMENT OF ANY THIRD PARTYS INTELLECTUAL PROPERTY RIGHTS. TIA EXPRESSLY DISCLAIMS ANY AND ALL RESPONSIBI

18、LITIES 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 EFFECTS OF THE CONTENTS OR ANY PRODUCT OR SERVICE REFERRED TO IN THE DOCUMENT OR PRODUCED OR RENDERED TO COMPL

19、Y 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 ALL INDIRECT, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES (INCLUDING DAMAGES FOR LOSS OF BUSINESS, LOS

20、S 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 OF SUCH DAMAGES. THE FOREGOING NEGATION OF DAMAGES IS A FUNDAMENTAL ELEMENT OF THE USE OF THE CONTENTS HE

21、REOF, AND THESE CONTENTS WOULD NOT BE PUBLISHED BY TIA WITHOUT SUCH LIMITATIONS. Copyright Telecommunications Industry Association Provided by IHS under license with EIANot for ResaleNo reproduction or networking permitted without license from IHS-,-,-PLEASE! DONT VIOLATE THE LAW! This document is c

22、opyrighted by the TIA and may not be reproduced without prior permission of the Telecommunications Industry Association. For information consult our website at http:/www.tiaonline.org/about/faqDetail.cfm?id=18 Organizations may obtain permission to reproduce a limited number of copies through enteri

23、ng into a license agreement. For information, contact: Global Engineering Documents 15 Inverness Way East Englewood, CO 80112-5704 U.S.A. or call U.S.A. and Canada 1-800-854-7179, International (303) 397-7956 Copyright Telecommunications Industry Association Provided by IHS under license with EIANot

24、 for ResaleNo reproduction or networking permitted without license from IHS-,-,-TIA-102.AACA - 2 1 ADDENDUM 2 DATA LINK INDEPENDENT OTAR 1 Scope This addendum specifies a method to transport Over The Air Rekeying (OTAR) Key Management Messages (KMMs) between a Key Management Facility (KMF) and an Mo

25、bile Radio (MR) that is independent of the physical and data transport layers. It defines optional key management procedures for Registration and Deregistration of the MR with the KMF. An Unable-To-Decrypt message has also been defined to respond to a message that was received and could not be decry

26、pted. The addendum supplements the information contained in the TIA/EIA 102.AACA APCO Project 25 Over-The-Air-Rekeying (OTAR) Protocol document (reference 1) and in TIA/EIA 102.AACA-1 Key Management Security Requirements For Type 3 Block Encryption Algorithms (reference 2). To allow for data link in

27、dependent transport of KMMs, the encryption synchronization (ESYNC) has been appended to the beginning of the KMM and is included as part of the data packet. The method defined in the addendum may be used with any KMM that is defined in the OTAR Protocol standard (reference 1). 2 Revision History Ve

28、rsion 1.0, August 2, 2002, first draft. Version 1.1, September 30, 2002, second draft. SP-3-4824-AD2, Version 1.2, October 30, 2002, ballot version. TIA/EIA 102.AACA-2, February 14, 2003, modified for editorial comments from ballot resolution. 3 References The following standards contain provisions

29、which, through reference in this text, constitute provisions of this Standard. At the time of publication, the editions indicated were valid. All standards are subject to revision, and parties to agreements based on this Standard are encouraged to investigate the possibility of applying the most rec

30、ent editions of the standards indicated below. ANSI and TIA maintain registers of currently valid national standards published by them. 1. TIA/EIA 102.AACA, Project 25 Digital Radio Over The Air Rekeying (OTAR) Protocol, April 2001 Copyright Telecommunications Industry Association Provided by IHS un

31、der license with EIANot for ResaleNo reproduction or networking permitted without license from IHS-,-,-TIA-102.AACA - 2 2 2. TIA/EIA 102.AACA-1, Addendum 1 - Key Management Security Requirements for Type 3 Block Encryption Algorithms, November 2002 3. TIA/EIA 102.AACB, Over-The-Air-Rekeying (OTAR) O

32、perational Description, November 2002 4. TIA/EIA-102.BAAC, Project 25 Common Air Interface Reserved Values, May 2000 5. TIA/EIA 102.BAEB-1, Project 25 Packet Data Specification - Addendum 1 - Subnetwork Dependent Convergence Protocol (SNDCP), October 2001 6. IETF RFC 791, Internet Protocol, Septembe

33、r 1981 7. IETF RFC 768, User Datagram Protocol, August 1980 4 Abbreviations ALGID Algorithm ID CAI Common Air Interface CS CheckSum ESYNC Encryption Synchronization IETF Internet Engineering Task Force ID Identification IP Internet Protocol KEK Key Encryption Key KEYID Key Identification KMF Key Man

34、agement Facility KM Key Management KMM Key Management Message LSB Least Significant Bit MAC Message Authentication Code MFID Manufacturer ID MI Message Indicator MN Message Number MNL Last Message Number MNP Message Number Period MNR Message Number Received MR Mobile Radio MSB Most Significant Bit O

35、TAR Over-The-Air Rekeying RSI Radio Set Identifier SAP Service Access Point SNDCP SubNetwork Dependent Convergence Protocol TEK Traffic Encryption Key UDP User Data Protocol Copyright Telecommunications Industry Association Provided by IHS under license with EIANot for ResaleNo reproduction or netwo

36、rking permitted without license from IHS-,-,-TIA-102.AACA - 2 3 5 OTAR Overview Data Link independent KMM datagrams are defined as an associated KMM Preamble and KMM carried in a single data message. Data messages may be as defined in Figure 6.5 of reference 1. The format of the Data Link Independen

37、t KMM Datagram is: Figure 5.1 Data Link Independent KMM Datagram This message structure can be passed to any Data Link layer as a datagram for transport. It is not pertinent as to what transport layer is used. The KMM Preamble is used to specify encryption of the KMM. The KMM Preamble is as defined

38、in detail in this addendum. KMM Preamble is always included in all KMM datagrams. The KMM may be as defined in TIA/EIA-102.AACA (reference 1) or in this addendum. 5.1 KMM Preamble In order to better support a Data Link layer independent based structure, encryption of the KMM shall occur at the appli

39、cation layer. The physical layer or data link layer may additionally encrypt the OTAR payload but it would not be necessary for OTAR operation. The KMM Preamble shall consist of an KMM Preamble Format octet and a block of octets (KMM Preamble Message Body) as defined by the version number. The KMM P

40、reamble Format octet shall contain 3 reserved bits and a 5-bit version field. KMM datagram KMM KMM Preamble Copyright Telecommunications Industry Association Provided by IHS under license with EIANot for ResaleNo reproduction or networking permitted without license from IHS-,-,-TIA-102.AACA - 2 4 Ta

41、ble 5.1.1 KMM Preamble Structure Octet 0 Reserved Version KMM Preamble Format 1 Preamble Message Body Length of Message Body 7 6 5 4 3 2 1 0 KMM Preamble Format This octet contains 3 reserved bits and a version number that selects which definition of the Preamble Message Body is to be used. Reserved

42、 - These 3 bits are reserved for future use and shall be set to 0. Version - These 5 bits define which version of the KMM Preamble Message Body is used. Preamble Message Body This block shall be uniquely defined for each version number. The Preamble Message Body shall be defined in the following sec

43、tions for valid version numbers. 5.1.1 Preamble Message Body - Version 0 The Preamble Message Body shall contain the Manufacturer Identifier, Algorithm Identifier, Key Identifier and the Message Indicator as Shown in Table 5.1.2 when the version number is set to 0 in the KMM Preamble Format octet. T

44、able 5.1.2 Preamble Message Body Format Version 0 Octet 0 MFID 1 Algorithm ID 2 Key ID 3 4 Message Indicator 9 octets 12 7 6 5 4 3 2 1 0 MFID - The MFID is used to indicate whether the Algorithm ID is a standard value or if it is defined by the Manufacturer identified by the MFID or if any portion o

45、f the KMM Preamble and/or KMM is proprietary to the Manufacturer identified by the MFID. The format for this field is defined in reference 4. Algorithm ID - The Algorithm ID is used to indicate the Algorithm used to encrypt the KMM. The format for this field is defined in the Primitive Field Definit

46、ions section for Algorithm ID, reference 1. Key ID - The Key ID indicates the TEK used to encrypt the KMM. The format for this field is defined in the Primitive Field Definition section for Key ID, reference 1. Message Indicator - Provides the Message Indicator (encryption synchronization) for the e

47、ncryption algorithm when the message is sent encrypted. This field will contain all zeros if the Algorithm ID is set to $80 and the Key ID is set to $0000 (indicating a clear message). The format for this field is defined in the Primitive Field Definition section for Message Indicator, reference 1.

48、Copyright Telecommunications Industry Association Provided by IHS under license with EIANot for ResaleNo reproduction or networking permitted without license from IHS-,-,-TIA-102.AACA - 2 5 5.2 KMM The KMM consists of a KMM Header and KMM Body. 5.2.1 KMM Header The KMM Header format will be as defin

49、ed in the Message Definitions section of reference 1. 5.2.2 KMM Body The KMM Body format will be as defined in the Message Definitions section of reference 1 and in this addendum. Copyright Telecommunications Industry Association Provided by IHS under license with EIANot for ResaleNo reproduction or networking permitted without license from IHS-,-,-TIA-102.AACA - 2 6 6 Data Link Indep